From 90b83144627b549eb205d23af30ba8a96b70b6bc Mon Sep 17 00:00:00 2001
From: Saugat Pachhai <suagatchhetri@outlook.com>
Date: Fri, 12 Apr 2019 09:52:11 +0545
Subject: [PATCH 001/131] Get job id only if sauce environment variables are
 set

The `getWebDriverSession` is not part of the `Mink\Driver\DriverInterface`, but is provided
by the `Selenium2Driver`. So, as Sauce uses selenium grid, this will only be used
when Sauce environment variables are set (other drivers do not have this).
---
 tests/acceptance/features/bootstrap/WebUIGeneralContext.php | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/acceptance/features/bootstrap/WebUIGeneralContext.php b/tests/acceptance/features/bootstrap/WebUIGeneralContext.php
index 80fd18d0ec49..3d053d100e09 100644
--- a/tests/acceptance/features/bootstrap/WebUIGeneralContext.php
+++ b/tests/acceptance/features/bootstrap/WebUIGeneralContext.php
@@ -772,11 +772,11 @@ public function reportResult(AfterScenarioScope $afterScenarioScope) {
 			$passed = "false";
 		}
 
-		$jobId = $this->getSessionId();
 		$sauceUsername = \getenv('SAUCE_USERNAME');
 		$sauceAccessKey = \getenv('SAUCE_ACCESS_KEY');
 
 		if ($sauceUsername && $sauceAccessKey) {
+			$jobId = $this->getSessionId();
 			\error_log("SAUCELABS RESULT: ($passOrFail) https://saucelabs.com/jobs/$jobId");
 			\exec('curl -X PUT -s -d "{\"passed\": ' . $passed . '}" -u ' . $sauceUsername . ':' . $sauceAccessKey . ' https://saucelabs.com/rest/v1/$SAUCE_USERNAME/jobs/' . $jobId);
 		} else {

From 4e69f9a28c232402ded81232b21c12b4d23e1aae Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Wed, 24 Apr 2019 11:14:58 +0545
Subject: [PATCH 002/131] change method shareWithUserOrGroup from private to
 public

---
 .../acceptance/features/lib/FilesPageElement/SharingDialog.php  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/acceptance/features/lib/FilesPageElement/SharingDialog.php b/tests/acceptance/features/lib/FilesPageElement/SharingDialog.php
index f869dc600d31..3a655e1818ed 100644
--- a/tests/acceptance/features/lib/FilesPageElement/SharingDialog.php
+++ b/tests/acceptance/features/lib/FilesPageElement/SharingDialog.php
@@ -199,7 +199,7 @@ public function getAutocompleteItemsList() {
 	 * @throws ElementNotFoundException
 	 * @return void
 	 */
-	private function shareWithUserOrGroup(
+	public function shareWithUserOrGroup(
 		$nameToType, $nameToMatch, Session $session, $maxRetries = 5, $quiet = false
 	) {
 		$userFound = false;

From dff29a0900c4a0963f203930b29124e23b74922b Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Mon, 29 Apr 2019 14:46:17 +0545
Subject: [PATCH 003/131] createUser function changed from private to public

---
 tests/acceptance/features/bootstrap/Provisioning.php | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/acceptance/features/bootstrap/Provisioning.php b/tests/acceptance/features/bootstrap/Provisioning.php
index 44eb2531e39e..a685f0acb5f0 100644
--- a/tests/acceptance/features/bootstrap/Provisioning.php
+++ b/tests/acceptance/features/bootstrap/Provisioning.php
@@ -1199,7 +1199,7 @@ public function rememberThatUserIsNotExpectedToExist($user) {
 	 * @return void
 	 * @throws \Exception
 	 */
-	private function createUser(
+	public function createUser(
 		$user,
 		$password = null,
 		$displayName = null,

From 2eca355555b75428c864b7a125e997dba3027c56 Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Mon, 29 Apr 2019 14:19:23 +0545
Subject: [PATCH 004/131] restore system config after running acceptance test

---
 .../features/bootstrap/AppConfiguration.php           | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/tests/acceptance/features/bootstrap/AppConfiguration.php b/tests/acceptance/features/bootstrap/AppConfiguration.php
index 3329ecbcb23f..0c4367440d2e 100644
--- a/tests/acceptance/features/bootstrap/AppConfiguration.php
+++ b/tests/acceptance/features/bootstrap/AppConfiguration.php
@@ -400,7 +400,7 @@ public function prepareParametersBeforeScenario() {
 				$this->usingServer($server);
 				$this->resetAppConfigs();
 				$result = SetupHelper::runOcc(
-					['config:list'], $this->getAdminUsername(),
+					['config:list', '--private'], $this->getAdminUsername(),
 					$this->getAdminPassword(), $this->getBaseUrl(), $this->getOcPath()
 				);
 				$this->savedConfigList[$server] = \json_decode($result['stdOut'], true);
@@ -457,6 +457,15 @@ private function restoreParameters($server) {
 				);
 			}
 		}
+		foreach ($this->savedConfigList[$server]['system'] as $configKey => $configValue) {
+			if (!\array_key_exists($configKey, $currentConfigList["system"])
+				|| $currentConfigList["system"][$configKey] !== $this->savedConfigList[$server]['system'][$configKey]
+			) {
+				SetupHelper::runOcc(
+					['config:system:set', "--type=json", "--value=" . \json_encode($configValue), $configKey]
+				);
+			}
+		}
 		foreach ($currentConfigList['apps'] as $appName => $appSettings) {
 			foreach ($appSettings as $configKey => $configValue) {
 				//only check if the app was there in the original configuration

From d0a28ed9e94041743345e3f3fdf5d4bc646e865c Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Thu, 2 May 2019 10:34:31 +0545
Subject: [PATCH 005/131] shareAutocompletion feature updated for the user to
 be not listed in autocomplete list in webUI

---
 .../bootstrap/WebUISharingContext.php         | 15 ++++++++++
 .../shareAutocompletion.feature               | 29 +++++++++++++++++++
 2 files changed, 44 insertions(+)

diff --git a/tests/acceptance/features/bootstrap/WebUISharingContext.php b/tests/acceptance/features/bootstrap/WebUISharingContext.php
index 43d5b7b535a0..348e64fe10d1 100644
--- a/tests/acceptance/features/bootstrap/WebUISharingContext.php
+++ b/tests/acceptance/features/bootstrap/WebUISharingContext.php
@@ -930,6 +930,21 @@ public function theUsersOwnNameShouldNotBeListedInTheAutocompleteList() {
 		);
 	}
 
+	/**
+	 * @Then user :username should not be listed in the autocomplete list on the webUI
+	 *
+	 * @param string $username
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public function userShouldNotBeListedInTheAutocompleteListOnTheWebui($username) {
+		$names = $this->sharingDialog->getAutocompleteItemsList();
+		if (\in_array($username, $names)) {
+			throw new Exception("$username found in autocomplete list but not expected");
+		}
+	}
+
 	/**
 	 * @Then a tooltip with the text :text should be shown near the share-with-field on the webUI
 	 *
diff --git a/tests/acceptance/features/webUISharingInternalUsers/shareAutocompletion.feature b/tests/acceptance/features/webUISharingInternalUsers/shareAutocompletion.feature
index 00ad0c95210a..600fa14c26a3 100644
--- a/tests/acceptance/features/webUISharingInternalUsers/shareAutocompletion.feature
+++ b/tests/acceptance/features/webUISharingInternalUsers/shareAutocompletion.feature
@@ -36,6 +36,7 @@ Feature: Autocompletion of share-with names
     When the user types "us" in the share-with-field
     Then all users and groups that contain the string "us" in their name should be listed in the autocomplete list on the webUI
     And the users own name should not be listed in the autocomplete list on the webUI
+    And user "Four" should not be listed in the autocomplete list on the webUI
 
   @skipOnLDAP
   @smokeTest
@@ -46,6 +47,7 @@ Feature: Autocompletion of share-with names
     When the user types "fi" in the share-with-field
     Then all users and groups that contain the string "fi" in their name should be listed in the autocomplete list on the webUI
     And the users own name should not be listed in the autocomplete list on the webUI
+    And user "other" should not be listed in the autocomplete list on the webUI
 
   Scenario: autocompletion for a pattern that does not match any user or group
     Given user "regularuser" has logged in using the webUI
@@ -66,6 +68,7 @@ Feature: Autocompletion of share-with names
     And the user has opened the share dialog for folder "simple-folder"
     When the user types "Use" in the share-with-field
     Then only "Use" should be listed in the autocomplete list on the webUI
+    And user "User Two" should not be listed in the autocomplete list on the webUI
 
   @skipOnLDAP
   Scenario: autocomplete short group names when completely typed
@@ -78,6 +81,7 @@ Feature: Autocompletion of share-with names
     And the user has opened the share dialog for folder "simple-folder"
     When the user types "fi" in the share-with-field
     Then only "fi (group)" should be listed in the autocomplete list on the webUI
+    And user "finance1" should not be listed in the autocomplete list on the webUI
 
   @skipOnLDAP
   Scenario: autocompletion when minimum characters is the default (2) and not enough characters are typed
@@ -107,6 +111,7 @@ Feature: Autocompletion of share-with names
     When the user types "use" in the share-with-field
     Then all users and groups that contain the string "use" in their name should be listed in the autocomplete list on the webUI
     And the users own name should not be listed in the autocomplete list on the webUI
+    And user "Four" should not be listed in the autocomplete list on the webUI
 
   @skipOnLDAP @user_ldap-issue-175
   Scenario: autocompletion of a pattern that matches regular existing users but also a user with whom the item is already shared (folder)
@@ -117,6 +122,7 @@ Feature: Autocompletion of share-with names
     When the user types "user" in the share-with-field
     Then all users and groups that contain the string "user" in their name should be listed in the autocomplete list on the webUI except user "User One"
     And the users own name should not be listed in the autocomplete list on the webUI
+    And user "Four" should not be listed in the autocomplete list on the webUI
 
   @skipOnLDAP @user_ldap-issue-175
   Scenario: autocompletion of a pattern that matches regular existing users but also a user with whom the item is already shared (file)
@@ -127,6 +133,7 @@ Feature: Autocompletion of share-with names
     When the user types "user" in the share-with-field
     Then all users and groups that contain the string "user" in their name should be listed in the autocomplete list on the webUI except user "User Grp"
     And the users own name should not be listed in the autocomplete list on the webUI
+    And user "Four" should not be listed in the autocomplete list on the webUI
 
   @skipOnLDAP
   Scenario: autocompletion of a pattern that matches regular existing groups but also a group with whom the item is already shared (folder)
@@ -137,6 +144,7 @@ Feature: Autocompletion of share-with names
     When the user types "fi" in the share-with-field
     Then all users and groups that contain the string "fi" in their name should be listed in the autocomplete list on the webUI except group "finance1"
     And the users own name should not be listed in the autocomplete list on the webUI
+    And user "Four" should not be listed in the autocomplete list on the webUI
 
   @skipOnLDAP
   Scenario: autocompletion of a pattern that matches regular existing groups but also a group with whom the item is already shared (file)
@@ -147,3 +155,24 @@ Feature: Autocompletion of share-with names
     When the user types "fi" in the share-with-field
     Then all users and groups that contain the string "fi" in their name should be listed in the autocomplete list on the webUI except group "finance1"
     And the users own name should not be listed in the autocomplete list on the webUI
+    And user "Four" should not be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: autocompletion of a pattern where the name of existing users contain the pattern somewhere in the middle
+    Given user "user1" has logged in using the webUI
+    And the user has browsed to the files page
+    And the user has opened the share dialog for folder "simple-folder"
+    When the user types "se" in the share-with-field
+    Then all users and groups that contain the string "se" in their name should be listed in the autocomplete list on the webUI
+    And the users own name should not be listed in the autocomplete list on the webUI
+    And user "Four" should not be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: autocompletion of a pattern where the name of existing users contain the pattern at the end
+    Given user "usergrp" has logged in using the webUI
+    And the user has browsed to the files page
+    And the user has opened the share dialog for folder "simple-folder"
+    When the user types "r3" in the share-with-field
+    Then all users and groups that contain the string "r3" in their name should be listed in the autocomplete list on the webUI
+    And the users own name should not be listed in the autocomplete list on the webUI
+    And user "User One" should not be listed in the autocomplete list on the webUI
\ No newline at end of file

From b268df6329de6611dd3006908548d06bfa27e199 Mon Sep 17 00:00:00 2001
From: Artur Neumann <artur@jankaritech.com>
Date: Mon, 6 May 2019 10:51:13 +0545
Subject: [PATCH 006/131] Test Helper to read file from server

---
 tests/TestHelpers/SetupHelper.php | 40 +++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/tests/TestHelpers/SetupHelper.php b/tests/TestHelpers/SetupHelper.php
index 1a757ac34211..67affb19cec6 100644
--- a/tests/TestHelpers/SetupHelper.php
+++ b/tests/TestHelpers/SetupHelper.php
@@ -470,6 +470,46 @@ public static function deleteFileOnServer(
 		}
 	}
 
+	/**
+	 * @param string $fileInCore e.g. 'app2/myapp/appinfo/info.xml'
+	 * @param string|null $baseUrl
+	 * @param string|null $adminUsername
+	 * @param string|null $adminPassword
+	 *
+	 * @return string
+	 * @throws Exception
+	 */
+	public static function readFileFromServer(
+		$fileInCore,
+		$baseUrl  = null,
+		$adminUsername = null,
+		$adminPassword = null
+	) {
+		$baseUrl = self::checkBaseUrl($baseUrl, "readFile");
+		$adminUsername = self::checkAdminUsername(
+			$adminUsername, "readFile"
+		);
+		$adminPassword = self::checkAdminPassword(
+			$adminPassword, "readFile"
+		);
+
+		$response = OcsApiHelper::sendRequest(
+			$baseUrl,
+			$adminUsername,
+			$adminPassword,
+			'GET',
+			"/apps/testing/api/v1/file?file={$fileInCore}"
+		);
+		self::assertSame(
+			200,
+			$response->getStatusCode(),
+			"Failed to read the file {$fileInCore}"
+		);
+		$localContent = HttpRequestHelper::getResponseXml($response);
+		$localContent = (string)$localContent->data->element->contentUrlEncoded;
+		return \urldecode($localContent);
+	}
+
 	/**
 	 * returns the content of a file in a skeleton folder
 	 *

From d12e0a8cc6505c071c4aa0b852d9accc24111410 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Wed, 8 May 2019 07:28:54 +0545
Subject: [PATCH 007/131] Split ocs Auth acceptance tests into apiAuthOcs suite

---
 .drone.yml                                            | 11 +++++++++++
 tests/acceptance/config/behat.yml                     |  6 ++++++
 .../{apiAuth => apiAuthOcs}/ocsDELETEAuth.feature     |  0
 .../{apiAuth => apiAuthOcs}/ocsGETAuth.feature        |  0
 .../{apiAuth => apiAuthOcs}/ocsPOSTAuth.feature       |  0
 .../{apiAuth => apiAuthOcs}/ocsPUTAuth.feature        |  0
 6 files changed, 17 insertions(+)
 rename tests/acceptance/features/{apiAuth => apiAuthOcs}/ocsDELETEAuth.feature (100%)
 rename tests/acceptance/features/{apiAuth => apiAuthOcs}/ocsGETAuth.feature (100%)
 rename tests/acceptance/features/{apiAuth => apiAuthOcs}/ocsPOSTAuth.feature (100%)
 rename tests/acceptance/features/{apiAuth => apiAuthOcs}/ocsPUTAuth.feature (100%)

diff --git a/.drone.yml b/.drone.yml
index ef8142bcd670..efedc92c30f1 100644
--- a/.drone.yml
+++ b/.drone.yml
@@ -825,6 +825,17 @@ matrix:
       OWNCLOUD_LOG: true
       INSTALL_TESTING_APP: true
 
+    - PHP_VERSION: 7.1
+      TEST_SUITE: api
+      BEHAT_SUITE: apiAuthOcs
+      DB_TYPE: mariadb
+      USE_SERVER: true
+      SERVER_PROTOCOL: https
+      INSTALL_SERVER: true
+      CHOWN_SERVER: true
+      OWNCLOUD_LOG: true
+      INSTALL_TESTING_APP: true
+
     - PHP_VERSION: 7.1
       TEST_SUITE: api
       BEHAT_SUITE: apiCapabilities
diff --git a/tests/acceptance/config/behat.yml b/tests/acceptance/config/behat.yml
index c139a7faeaf1..5a161146eca1 100644
--- a/tests/acceptance/config/behat.yml
+++ b/tests/acceptance/config/behat.yml
@@ -27,6 +27,12 @@ default:
         - FeatureContext: *common_feature_context_params
         - CorsContext:
 
+    apiAuthOcs:
+      paths:
+        - '%paths.base%/../features/apiAuthOcs'
+      contexts:
+        - FeatureContext: *common_feature_context_params
+
     apiCapabilities:
       paths:
         - '%paths.base%/../features/apiCapabilities'
diff --git a/tests/acceptance/features/apiAuth/ocsDELETEAuth.feature b/tests/acceptance/features/apiAuthOcs/ocsDELETEAuth.feature
similarity index 100%
rename from tests/acceptance/features/apiAuth/ocsDELETEAuth.feature
rename to tests/acceptance/features/apiAuthOcs/ocsDELETEAuth.feature
diff --git a/tests/acceptance/features/apiAuth/ocsGETAuth.feature b/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature
similarity index 100%
rename from tests/acceptance/features/apiAuth/ocsGETAuth.feature
rename to tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature
diff --git a/tests/acceptance/features/apiAuth/ocsPOSTAuth.feature b/tests/acceptance/features/apiAuthOcs/ocsPOSTAuth.feature
similarity index 100%
rename from tests/acceptance/features/apiAuth/ocsPOSTAuth.feature
rename to tests/acceptance/features/apiAuthOcs/ocsPOSTAuth.feature
diff --git a/tests/acceptance/features/apiAuth/ocsPUTAuth.feature b/tests/acceptance/features/apiAuthOcs/ocsPUTAuth.feature
similarity index 100%
rename from tests/acceptance/features/apiAuth/ocsPUTAuth.feature
rename to tests/acceptance/features/apiAuthOcs/ocsPUTAuth.feature

From 31765c81da0350f4134494651f71a04012d97d9a Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Wed, 8 May 2019 07:42:32 +0545
Subject: [PATCH 008/131] Split apiProvisioning acceptance groups tests into
 apiProvisioningGroups suites

---
 .drone.yml                                    | 22 +++++++++++++++++++
 tests/acceptance/config/behat.yml             | 16 ++++++++++++++
 .../addGroup.feature                          |  0
 .../addToGroup.feature                        |  0
 .../deleteGroup.feature                       |  0
 .../getGroup.feature                          |  0
 .../getGroups.feature                         |  0
 .../getSubAdminGroups.feature                 |  0
 .../getUserGroups.feature                     |  0
 .../removeFromGroup.feature                   |  0
 .../addGroup.feature                          |  0
 .../addToGroup.feature                        |  0
 .../deleteGroup.feature                       |  0
 .../getGroup.feature                          |  0
 .../getGroups.feature                         |  0
 .../getSubAdminGroups.feature                 |  0
 .../getUserGroups.feature                     |  0
 .../removeFromGroup.feature                   |  0
 18 files changed, 38 insertions(+)
 rename tests/acceptance/features/{apiProvisioning-v1 => apiProvisioningGroups-v1}/addGroup.feature (100%)
 rename tests/acceptance/features/{apiProvisioning-v1 => apiProvisioningGroups-v1}/addToGroup.feature (100%)
 rename tests/acceptance/features/{apiProvisioning-v1 => apiProvisioningGroups-v1}/deleteGroup.feature (100%)
 rename tests/acceptance/features/{apiProvisioning-v1 => apiProvisioningGroups-v1}/getGroup.feature (100%)
 rename tests/acceptance/features/{apiProvisioning-v1 => apiProvisioningGroups-v1}/getGroups.feature (100%)
 rename tests/acceptance/features/{apiProvisioning-v1 => apiProvisioningGroups-v1}/getSubAdminGroups.feature (100%)
 rename tests/acceptance/features/{apiProvisioning-v1 => apiProvisioningGroups-v1}/getUserGroups.feature (100%)
 rename tests/acceptance/features/{apiProvisioning-v1 => apiProvisioningGroups-v1}/removeFromGroup.feature (100%)
 rename tests/acceptance/features/{apiProvisioning-v2 => apiProvisioningGroups-v2}/addGroup.feature (100%)
 rename tests/acceptance/features/{apiProvisioning-v2 => apiProvisioningGroups-v2}/addToGroup.feature (100%)
 rename tests/acceptance/features/{apiProvisioning-v2 => apiProvisioningGroups-v2}/deleteGroup.feature (100%)
 rename tests/acceptance/features/{apiProvisioning-v2 => apiProvisioningGroups-v2}/getGroup.feature (100%)
 rename tests/acceptance/features/{apiProvisioning-v2 => apiProvisioningGroups-v2}/getGroups.feature (100%)
 rename tests/acceptance/features/{apiProvisioning-v2 => apiProvisioningGroups-v2}/getSubAdminGroups.feature (100%)
 rename tests/acceptance/features/{apiProvisioning-v2 => apiProvisioningGroups-v2}/getUserGroups.feature (100%)
 rename tests/acceptance/features/{apiProvisioning-v2 => apiProvisioningGroups-v2}/removeFromGroup.feature (100%)

diff --git a/.drone.yml b/.drone.yml
index efedc92c30f1..042a9e0a9be3 100644
--- a/.drone.yml
+++ b/.drone.yml
@@ -904,6 +904,28 @@ matrix:
       OWNCLOUD_LOG: true
       INSTALL_TESTING_APP: true
 
+    - PHP_VERSION: 7.1
+      TEST_SUITE: api
+      BEHAT_SUITE: apiProvisioningGroups-v1
+      DB_TYPE: mariadb
+      USE_SERVER: true
+      SERVER_PROTOCOL: https
+      INSTALL_SERVER: true
+      CHOWN_SERVER: true
+      OWNCLOUD_LOG: true
+      INSTALL_TESTING_APP: true
+
+    - PHP_VERSION: 7.1
+      TEST_SUITE: api
+      BEHAT_SUITE: apiProvisioningGroups-v2
+      DB_TYPE: mariadb
+      USE_SERVER: true
+      SERVER_PROTOCOL: https
+      INSTALL_SERVER: true
+      CHOWN_SERVER: true
+      OWNCLOUD_LOG: true
+      INSTALL_TESTING_APP: true
+
     - PHP_VERSION: 7.1
       TEST_SUITE: api
       BEHAT_SUITE: apiSharees
diff --git a/tests/acceptance/config/behat.yml b/tests/acceptance/config/behat.yml
index 5a161146eca1..2dd6b59b207f 100644
--- a/tests/acceptance/config/behat.yml
+++ b/tests/acceptance/config/behat.yml
@@ -80,6 +80,22 @@ default:
         - OccContext:
         - OccUsersGroupsContext:
 
+    apiProvisioningGroups-v1:
+      paths:
+        - '%paths.base%/../features/apiProvisioningGroups-v1'
+      contexts:
+        - FeatureContext: *common_feature_context_params
+        - OccContext:
+        - OccUsersGroupsContext:
+
+    apiProvisioningGroups-v2:
+      paths:
+        - '%paths.base%/../features/apiProvisioningGroups-v2'
+      contexts:
+        - FeatureContext: *common_feature_context_params
+        - OccContext:
+        - OccUsersGroupsContext:
+
     apiSharees:
       paths:
         - '%paths.base%/../features/apiSharees'
diff --git a/tests/acceptance/features/apiProvisioning-v1/addGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature
similarity index 100%
rename from tests/acceptance/features/apiProvisioning-v1/addGroup.feature
rename to tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature
diff --git a/tests/acceptance/features/apiProvisioning-v1/addToGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature
similarity index 100%
rename from tests/acceptance/features/apiProvisioning-v1/addToGroup.feature
rename to tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature
diff --git a/tests/acceptance/features/apiProvisioning-v1/deleteGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/deleteGroup.feature
similarity index 100%
rename from tests/acceptance/features/apiProvisioning-v1/deleteGroup.feature
rename to tests/acceptance/features/apiProvisioningGroups-v1/deleteGroup.feature
diff --git a/tests/acceptance/features/apiProvisioning-v1/getGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/getGroup.feature
similarity index 100%
rename from tests/acceptance/features/apiProvisioning-v1/getGroup.feature
rename to tests/acceptance/features/apiProvisioningGroups-v1/getGroup.feature
diff --git a/tests/acceptance/features/apiProvisioning-v1/getGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v1/getGroups.feature
similarity index 100%
rename from tests/acceptance/features/apiProvisioning-v1/getGroups.feature
rename to tests/acceptance/features/apiProvisioningGroups-v1/getGroups.feature
diff --git a/tests/acceptance/features/apiProvisioning-v1/getSubAdminGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v1/getSubAdminGroups.feature
similarity index 100%
rename from tests/acceptance/features/apiProvisioning-v1/getSubAdminGroups.feature
rename to tests/acceptance/features/apiProvisioningGroups-v1/getSubAdminGroups.feature
diff --git a/tests/acceptance/features/apiProvisioning-v1/getUserGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v1/getUserGroups.feature
similarity index 100%
rename from tests/acceptance/features/apiProvisioning-v1/getUserGroups.feature
rename to tests/acceptance/features/apiProvisioningGroups-v1/getUserGroups.feature
diff --git a/tests/acceptance/features/apiProvisioning-v1/removeFromGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature
similarity index 100%
rename from tests/acceptance/features/apiProvisioning-v1/removeFromGroup.feature
rename to tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature
diff --git a/tests/acceptance/features/apiProvisioning-v2/addGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/addGroup.feature
similarity index 100%
rename from tests/acceptance/features/apiProvisioning-v2/addGroup.feature
rename to tests/acceptance/features/apiProvisioningGroups-v2/addGroup.feature
diff --git a/tests/acceptance/features/apiProvisioning-v2/addToGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature
similarity index 100%
rename from tests/acceptance/features/apiProvisioning-v2/addToGroup.feature
rename to tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature
diff --git a/tests/acceptance/features/apiProvisioning-v2/deleteGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/deleteGroup.feature
similarity index 100%
rename from tests/acceptance/features/apiProvisioning-v2/deleteGroup.feature
rename to tests/acceptance/features/apiProvisioningGroups-v2/deleteGroup.feature
diff --git a/tests/acceptance/features/apiProvisioning-v2/getGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/getGroup.feature
similarity index 100%
rename from tests/acceptance/features/apiProvisioning-v2/getGroup.feature
rename to tests/acceptance/features/apiProvisioningGroups-v2/getGroup.feature
diff --git a/tests/acceptance/features/apiProvisioning-v2/getGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v2/getGroups.feature
similarity index 100%
rename from tests/acceptance/features/apiProvisioning-v2/getGroups.feature
rename to tests/acceptance/features/apiProvisioningGroups-v2/getGroups.feature
diff --git a/tests/acceptance/features/apiProvisioning-v2/getSubAdminGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v2/getSubAdminGroups.feature
similarity index 100%
rename from tests/acceptance/features/apiProvisioning-v2/getSubAdminGroups.feature
rename to tests/acceptance/features/apiProvisioningGroups-v2/getSubAdminGroups.feature
diff --git a/tests/acceptance/features/apiProvisioning-v2/getUserGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v2/getUserGroups.feature
similarity index 100%
rename from tests/acceptance/features/apiProvisioning-v2/getUserGroups.feature
rename to tests/acceptance/features/apiProvisioningGroups-v2/getUserGroups.feature
diff --git a/tests/acceptance/features/apiProvisioning-v2/removeFromGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature
similarity index 100%
rename from tests/acceptance/features/apiProvisioning-v2/removeFromGroup.feature
rename to tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature

From e638e27a61f2cfd9892b51018480c0023621b3c5 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Wed, 8 May 2019 07:55:21 +0545
Subject: [PATCH 009/131] Split apiShareManagement acceptance tests into
 apiShareManagementBasic suite

---
 .drone.yml                                            | 11 +++++++++++
 tests/acceptance/config/behat.yml                     |  9 +++++++++
 .../createShare.feature                               |  0
 .../deleteShare.feature                               |  0
 .../updateShare.feature                               |  0
 5 files changed, 20 insertions(+)
 rename tests/acceptance/features/{apiShareManagement => apiShareManagementBasic}/createShare.feature (100%)
 rename tests/acceptance/features/{apiShareManagement => apiShareManagementBasic}/deleteShare.feature (100%)
 rename tests/acceptance/features/{apiShareManagement => apiShareManagementBasic}/updateShare.feature (100%)

diff --git a/.drone.yml b/.drone.yml
index 042a9e0a9be3..4108ceca58f4 100644
--- a/.drone.yml
+++ b/.drone.yml
@@ -948,6 +948,17 @@ matrix:
       OWNCLOUD_LOG: true
       INSTALL_TESTING_APP: true
 
+    - PHP_VERSION: 7.1
+      TEST_SUITE: api
+      BEHAT_SUITE: apiShareManagementBasic
+      DB_TYPE: mariadb
+      USE_SERVER: true
+      SERVER_PROTOCOL: https
+      INSTALL_SERVER: true
+      CHOWN_SERVER: true
+      OWNCLOUD_LOG: true
+      INSTALL_TESTING_APP: true
+
     - PHP_VERSION: 7.1
       TEST_SUITE: api
       BEHAT_SUITE: apiShareOperations
diff --git a/tests/acceptance/config/behat.yml b/tests/acceptance/config/behat.yml
index 2dd6b59b207f..c2e6aaa54268 100644
--- a/tests/acceptance/config/behat.yml
+++ b/tests/acceptance/config/behat.yml
@@ -112,6 +112,15 @@ default:
         - TrashbinContext:
         - WebDavPropertiesContext:
 
+    apiShareManagementBasic:
+      paths:
+        - '%paths.base%/../features/apiShareManagementBasic'
+      contexts:
+        - FeatureContext: *common_feature_context_params
+        - PublicWebDavContext:
+        - TrashbinContext:
+        - WebDavPropertiesContext:
+
     apiShareOperations:
       paths:
         - '%paths.base%/../features/apiShareOperations'
diff --git a/tests/acceptance/features/apiShareManagement/createShare.feature b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
similarity index 100%
rename from tests/acceptance/features/apiShareManagement/createShare.feature
rename to tests/acceptance/features/apiShareManagementBasic/createShare.feature
diff --git a/tests/acceptance/features/apiShareManagement/deleteShare.feature b/tests/acceptance/features/apiShareManagementBasic/deleteShare.feature
similarity index 100%
rename from tests/acceptance/features/apiShareManagement/deleteShare.feature
rename to tests/acceptance/features/apiShareManagementBasic/deleteShare.feature
diff --git a/tests/acceptance/features/apiShareManagement/updateShare.feature b/tests/acceptance/features/apiShareManagementBasic/updateShare.feature
similarity index 100%
rename from tests/acceptance/features/apiShareManagement/updateShare.feature
rename to tests/acceptance/features/apiShareManagementBasic/updateShare.feature

From 2f8489bea43ce3f69b0e00c7bce72cf98deed44b Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Wed, 8 May 2019 08:06:57 +0545
Subject: [PATCH 010/131] Split apiWebdavLocks acceptance tests into
 apiWebdavLocks2 suite

---
 .drone.yml                                            | 11 +++++++++++
 tests/acceptance/config/behat.yml                     |  9 +++++++++
 .../resharedShares.feature                            |  0
 .../setTimeout.feature                                |  0
 .../unlock.feature                                    |  0
 5 files changed, 20 insertions(+)
 rename tests/acceptance/features/{apiWebdavLocks => apiWebdavLocks2}/resharedShares.feature (100%)
 rename tests/acceptance/features/{apiWebdavLocks => apiWebdavLocks2}/setTimeout.feature (100%)
 rename tests/acceptance/features/{apiWebdavLocks => apiWebdavLocks2}/unlock.feature (100%)

diff --git a/.drone.yml b/.drone.yml
index 4108ceca58f4..d60af56f196c 100644
--- a/.drone.yml
+++ b/.drone.yml
@@ -1026,6 +1026,17 @@ matrix:
       OWNCLOUD_LOG: true
       INSTALL_TESTING_APP: true
 
+    - PHP_VERSION: 7.1
+      TEST_SUITE: api
+      BEHAT_SUITE: apiWebdavLocks2
+      DB_TYPE: mariadb
+      USE_SERVER: true
+      SERVER_PROTOCOL: https
+      INSTALL_SERVER: true
+      CHOWN_SERVER: true
+      OWNCLOUD_LOG: true
+      INSTALL_TESTING_APP: true
+
     - PHP_VERSION: 7.1
       TEST_SUITE: api
       BEHAT_SUITE: apiWebdavMove
diff --git a/tests/acceptance/config/behat.yml b/tests/acceptance/config/behat.yml
index c2e6aaa54268..979cd355dadc 100644
--- a/tests/acceptance/config/behat.yml
+++ b/tests/acceptance/config/behat.yml
@@ -169,6 +169,15 @@ default:
         - WebDavLockingContext:
         - WebDavPropertiesContext:
 
+    apiWebdavLocks2:
+      paths:
+        - '%paths.base%/../features/apiWebdavLocks2'
+      contexts:
+        - FeatureContext: *common_feature_context_params
+        - PublicWebDavContext:
+        - WebDavLockingContext:
+        - WebDavPropertiesContext:
+
     apiWebdavMove:
       paths:
         - '%paths.base%/../features/apiWebdavMove'
diff --git a/tests/acceptance/features/apiWebdavLocks/resharedShares.feature b/tests/acceptance/features/apiWebdavLocks2/resharedShares.feature
similarity index 100%
rename from tests/acceptance/features/apiWebdavLocks/resharedShares.feature
rename to tests/acceptance/features/apiWebdavLocks2/resharedShares.feature
diff --git a/tests/acceptance/features/apiWebdavLocks/setTimeout.feature b/tests/acceptance/features/apiWebdavLocks2/setTimeout.feature
similarity index 100%
rename from tests/acceptance/features/apiWebdavLocks/setTimeout.feature
rename to tests/acceptance/features/apiWebdavLocks2/setTimeout.feature
diff --git a/tests/acceptance/features/apiWebdavLocks/unlock.feature b/tests/acceptance/features/apiWebdavLocks2/unlock.feature
similarity index 100%
rename from tests/acceptance/features/apiWebdavLocks/unlock.feature
rename to tests/acceptance/features/apiWebdavLocks2/unlock.feature

From 45bbef299eb6df0020726a40fc9c0bb94d6a4971 Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Thu, 9 May 2019 10:35:40 +0545
Subject: [PATCH 011/131] reorganization or createTags feature file into
 createTags, removeTags and deleteTags

---
 .../features/webUITags/createTags.feature     | 23 +---------
 .../features/webUITags/deleteTags.feature     | 45 +++++++++++++++++++
 .../features/webUITags/removeTags.feature     | 22 +++++++++
 3 files changed, 68 insertions(+), 22 deletions(-)
 create mode 100644 tests/acceptance/features/webUITags/deleteTags.feature
 create mode 100644 tests/acceptance/features/webUITags/removeTags.feature

diff --git a/tests/acceptance/features/webUITags/createTags.feature b/tests/acceptance/features/webUITags/createTags.feature
index 97df6c5b34b3..1b8fef9664d6 100644
--- a/tests/acceptance/features/webUITags/createTags.feature
+++ b/tests/acceptance/features/webUITags/createTags.feature
@@ -38,13 +38,6 @@ Feature: Creation of tags for the files and folders
     And file "simple-folder/lorem-big.txt" should have the following tags for user "user1"
       | lorem | normal |
 
-  Scenario: Remove a tag that already exists for a file in a folder
-    Given the user has browsed directly to display the details of file "lorem.txt" in folder "simple-folder"
-    And the user has added a tag "lorem" to the file using the webUI
-    When the user browses directly to display the details of file "lorem.txt" in folder "simple-folder"
-    And the user toggles a tag "lorem" on the file using the webUI
-    Then file "simple-folder/lorem.txt" should have no tags for user "user1"
-
   @skipOnFIREFOX
   Scenario: Create and add tag on a shared file
     When the user renames file "lorem.txt" to "coolnewfile.txt" using the webUI
@@ -59,18 +52,4 @@ Feature: Creation of tags for the files and folders
       | tag2 | normal |
     And file "coolnewfile.txt" should have the following tags for user "user2"
       | tag1 | normal |
-      | tag2 | normal |
-
-  @skipOnFIREFOX
-  Scenario: Delete a tag in a shared file
-    When the user renames file "lorem.txt" to "coolnewfile.txt" using the webUI
-    And the user browses directly to display the details of file "coolnewfile.txt" in folder ""
-    And the user adds a tag "tag1" to the file using the webUI
-    And the user shares file "coolnewfile.txt" with user "User Two" using the webUI
-    And the user re-logs in with username "user2" and password "%alt2%" using the webUI
-    Then file "coolnewfile.txt" should have the following tags for user "user2"
-      | tag1 | normal |
-    When the user browses directly to display the details of file "coolnewfile.txt" in folder ""
-    And the user deletes tag with name "tag1" using the webUI
-    Then tag "tag1" should not exist for user "user1"
-    And tag "tag1" should not exist for user "user2"
+      | tag2 | normal |
\ No newline at end of file
diff --git a/tests/acceptance/features/webUITags/deleteTags.feature b/tests/acceptance/features/webUITags/deleteTags.feature
new file mode 100644
index 000000000000..a4cba9c9de06
--- /dev/null
+++ b/tests/acceptance/features/webUITags/deleteTags.feature
@@ -0,0 +1,45 @@
+@webUI @insulated @disablePreviews @systemtags-app-required
+Feature: Deletion of existing tags from files and folders
+  As a user
+  I want to delete tags from files and folders
+  So that I can keep my filing system clean and tidy
+
+  Background:
+    Given these users have been created with default attributes:
+      | username |
+      | user1    |
+      | user2    |
+    And the user has browsed to the login page
+    And the user has logged in with username "user1" and password "%alt1%" using the webUI
+
+@skipOnFIREFOX
+  Scenario: Delete a tag in a shared file
+    When the user renames file "lorem.txt" to "coolnewfile.txt" using the webUI
+    And the user browses directly to display the details of file "coolnewfile.txt" in folder ""
+    And the user adds a tag "tag1" to the file using the webUI
+    And the user shares file "coolnewfile.txt" with user "User Two" using the webUI
+    And the user re-logs in with username "user2" and password "%alt2%" using the webUI
+    Then file "coolnewfile.txt" should have the following tags for user "user2"
+    | tag1 | normal |
+    When the user browses directly to display the details of file "coolnewfile.txt" in folder ""
+    And the user deletes tag with name "tag1" using the webUI
+    Then tag "tag1" should not exist for user "user1"
+    And tag "tag1" should not exist for user "user2"
+
+  Scenario: Delete a tag that already exists for a file in the root
+    Given the user has created a "normal" tag with name "lorem"
+    And the user has added tag "lorem" to file "lorem.txt"
+    When the user browses directly to display the details of file "lorem.txt" in folder "/"
+    Then file "lorem.txt" should have the following tags for user "user1"
+      | lorem | normal |
+    When the user deletes tag with name "lorem" using the webUI
+    Then tag "lorem" should not exist for user "user1"
+
+  Scenario: Delete a tag that already exists for a file in a folder
+    Given the user has created a "normal" tag with name "lorem"
+    And the user has added tag "lorem" to file "simple-folder/lorem.txt"
+    When the user browses directly to display the details of file "lorem.txt" in folder "simple-folder"
+    Then file "simple-folder/lorem.txt" should have the following tags for user "user1"
+      | lorem | normal |
+    When the user deletes tag with name "lorem" using the webUI
+    Then tag "lorem" should not exist for user "user1"
diff --git a/tests/acceptance/features/webUITags/removeTags.feature b/tests/acceptance/features/webUITags/removeTags.feature
new file mode 100644
index 000000000000..230c7a91ae74
--- /dev/null
+++ b/tests/acceptance/features/webUITags/removeTags.feature
@@ -0,0 +1,22 @@
+@webUI @insulated @disablePreviews @systemtags-app-required
+Feature: Removal of already existing tags from files and folders
+  As a user
+  I want to remove tags from files and folders
+  So that I can properly organize my filing system
+
+  Background:
+    Given these users have been created with default attributes:
+      | username |
+      | user1    |
+      | user2    |
+    And the user has browsed to the login page
+    And the user has logged in with username "user1" and password "%alt1%" using the webUI
+
+  Scenario: Remove a tag that already exists for a file in a folder
+    Given the user has browsed directly to display the details of file "lorem.txt" in folder "simple-folder"
+    And the user has added a tag "lorem" to the file using the webUI
+    When the user browses directly to display the details of file "lorem.txt" in folder "simple-folder"
+    And the user toggles a tag "lorem" on the file using the webUI
+    Then file "simple-folder/lorem.txt" should have no tags for user "user1"
+
+

From 07aeae6fe94c730c7ed639f89c8cfa78ac7e339e Mon Sep 17 00:00:00 2001
From: bhawana <bhawana.prs@gmail.com>
Date: Thu, 9 May 2019 11:06:26 +0545
Subject: [PATCH 012/131] Acceptance test for renaming subfolders with same
 name  shared by public links

---
 .../features/lib/SharedByLinkPage.php         |  2 +-
 .../shareByPublicLink.feature                 | 21 +++++++++++++++++++
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/tests/acceptance/features/lib/SharedByLinkPage.php b/tests/acceptance/features/lib/SharedByLinkPage.php
index 915fe2f9a1db..13857140cebc 100644
--- a/tests/acceptance/features/lib/SharedByLinkPage.php
+++ b/tests/acceptance/features/lib/SharedByLinkPage.php
@@ -28,7 +28,7 @@
 /**
  * Shared By Link page.
  */
-class SharedByLinkPage extends FilesPageBasic {
+class SharedByLinkPage extends FilesPageCRUD {
 
 	/**
 	 *
diff --git a/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature b/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
index 767cf08179e2..fb5365cd1f59 100644
--- a/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
+++ b/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
@@ -387,3 +387,24 @@ Feature: Share by public link
     And file "lorem.txt" should be listed on the webUI
     And the content of "lorem.txt" should not have changed
     And file "lorem (2).txt" should not be listed on the webUI
+
+  @issue-35177
+  Scenario: User renames a subfolder among subfolders with same names which are shared by public links
+    Given user "user1" has created folder "nf1"
+    And user "user1" has created folder "nf1/newfolder"
+    And user "user1" has created folder "nf2"
+    And user "user1" has created folder "nf2/newfolder"
+    And user "user1" has created folder "test"
+    And user "user1" has created folder "test/test"
+    And user "user1" has created a public link share with settings
+      | path | nf1/newfolder |
+    And user "user1" has created a public link share with settings
+      | path | nf2/newfolder |
+    And user "user1" has created a public link share with settings
+      | path | test/test |
+    And the user has browsed to the shared-by-link page
+    When the user renames folder "newfolder" to "newfolder1" using the webUI
+    Then folder "newfolder1" should be listed on the webUI
+    And folder "newfolder" should not be listed on the webUI
+    #And folder "newfolder" should be listed on the webUI
+    And folder "test" should be listed on the webUI

From ce5354cabdb3387f3f100703d1d370a11e08aace Mon Sep 17 00:00:00 2001
From: paurakhsharma <paurakh011@gmail.com>
Date: Mon, 13 May 2019 11:39:20 +0545
Subject: [PATCH 013/131] Add issue tag on scenario with invalid status code

---
 tests/acceptance/features/apiProvisioning-v2/getUser.feature | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/acceptance/features/apiProvisioning-v2/getUser.feature b/tests/acceptance/features/apiProvisioning-v2/getUser.feature
index 9fa22aa41ccb..7a02fe97c077 100644
--- a/tests/acceptance/features/apiProvisioning-v2/getUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/getUser.feature
@@ -49,11 +49,13 @@ Feature: get user
     And the HTTP status code should be "401"
     And the API should not return any data
 
+  @issue-31276
   Scenario: a normal user tries to get information of another user
     Given user "newuser" has been created with default attributes
     And user "anotheruser" has been created with default attributes
     When user "anotheruser" retrieves the information of user "newuser" 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
 

From 8732776ec0bbe6bc64594d33d6cc71fe1d4710b9 Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Thu, 2 May 2019 10:34:31 +0545
Subject: [PATCH 014/131] feature test for share autocomplete list in webUI

---
 tests/acceptance/config/behat.yml             |  1 +
 .../WebUIPersonalSharingSettingsContext.php   | 24 +++++
 .../bootstrap/WebUISharingContext.php         | 17 ++++
 .../lib/PersonalSharingSettingsPage.php       | 36 ++++++-
 .../shareAutocompletion.feature               | 94 ++++++++++++++++++-
 5 files changed, 170 insertions(+), 2 deletions(-)

diff --git a/tests/acceptance/config/behat.yml b/tests/acceptance/config/behat.yml
index 979cd355dadc..c172c89f012d 100644
--- a/tests/acceptance/config/behat.yml
+++ b/tests/acceptance/config/behat.yml
@@ -443,6 +443,7 @@ default:
         - WebUISharingContext:
         - EmailContext:
         - WebUIAdminSharingSettingsContext:
+        - WebUIPersonalSharingSettingsContext:
 
     webUISharingNotifications:
       paths:
diff --git a/tests/acceptance/features/bootstrap/WebUIPersonalSharingSettingsContext.php b/tests/acceptance/features/bootstrap/WebUIPersonalSharingSettingsContext.php
index 54522e0d14e4..72ba17015215 100644
--- a/tests/acceptance/features/bootstrap/WebUIPersonalSharingSettingsContext.php
+++ b/tests/acceptance/features/bootstrap/WebUIPersonalSharingSettingsContext.php
@@ -81,6 +81,19 @@ public function switchAutoAcceptingFederatedShares($action) {
 		);
 	}
 
+	/**
+	 * @When /^the user (disables|enables) allow finding you via autocomplete in share dialog$/
+	 *
+	 * @param string $action
+	 *
+	 * @return void
+	 */
+	public function switchAllowFindingYouViaAutocompleteInShareDialog($action) {
+		$this->personalSharingSettingsPage->toggleFindingYouViaAutocomplete(
+			$this->getSession(), $action
+		);
+	}
+
 	/**
 	 * @Then User-based auto accepting checkbox should not be displayed on the personal sharing settings page in the webUI
 	 *
@@ -102,4 +115,15 @@ public function autoAcceptingFederatedCheckboxShouldNotBeDisplayedOnThePersonalS
 			$this->personalSharingSettingsPage->isAutoAcceptFederatedSharesCheckboxDisplayed()
 		);
 	}
+
+	/**
+	 * @Then allow finding you via autocomplete checkbox should not be displayed on the personal sharing settings page
+	 *
+	 * @return void
+	 */
+	public function allowFindingYouViaAutocompleteCheckboxShouldNotBeDisplayedOnThePersonalSharingSettingsPage() {
+		PHPUnit\Framework\Assert::assertFalse(
+			$this->personalSharingSettingsPage->isAllowFindingYouViaAutocompleteCheckboxDisplayed()
+		);
+	}
 }
diff --git a/tests/acceptance/features/bootstrap/WebUISharingContext.php b/tests/acceptance/features/bootstrap/WebUISharingContext.php
index 348e64fe10d1..b23731cada47 100644
--- a/tests/acceptance/features/bootstrap/WebUISharingContext.php
+++ b/tests/acceptance/features/bootstrap/WebUISharingContext.php
@@ -930,6 +930,23 @@ public function theUsersOwnNameShouldNotBeListedInTheAutocompleteList() {
 		);
 	}
 
+	/**
+	 * @Then user :username should be listed in the autocomplete list on the webUI
+	 *
+	 * @param string $username
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public function userShouldBeListedInTheAutocompleteListOnTheWebui($username) {
+		$names = $this->sharingDialog->getAutocompleteItemsList();
+		PHPUnit\Framework\Assert::assertContains(
+			$username,
+			$names,
+			"$username not found in autocomplete list"
+		);
+	}
+
 	/**
 	 * @Then user :username should not be listed in the autocomplete list on the webUI
 	 *
diff --git a/tests/acceptance/features/lib/PersonalSharingSettingsPage.php b/tests/acceptance/features/lib/PersonalSharingSettingsPage.php
index 29dc179279ac..098dddbd203c 100644
--- a/tests/acceptance/features/lib/PersonalSharingSettingsPage.php
+++ b/tests/acceptance/features/lib/PersonalSharingSettingsPage.php
@@ -43,7 +43,10 @@ class PersonalSharingSettingsPage extends SharingSettingsPage {
 		= '//label[@for="userAutoAcceptShareTrustedInput"]';
 	protected $autoAcceptFederatedSharesCheckboxXpathCheckboxId
 		= 'userAutoAcceptShareTrustedInput';
-
+	protected $allowFindingYouViaAutocompleteCheckboxXpath
+		= '//label[@for="allow_share_dialog_user_enumeration_input"]';
+	protected $allowFindingYouViaAutocompleteCheckboxXpathCheckboxId
+		= 'allow_share_dialog_user_enumeration_input';
 	/**
 	 *
 	 * @param Session $session
@@ -76,6 +79,21 @@ public function toggleAutoAcceptingFederatedShares(Session $session, $action) {
 		);
 	}
 
+	/**
+	 *
+	 * @param Session $session
+	 * @param string $action "enables|disables"
+	 *
+	 * @return void
+	 */
+	public function toggleFindingYouViaAutocomplete(Session $session, $action) {
+		$this->toggleCheckbox(
+			$session,
+			$action,
+			$this->allowFindingYouViaAutocompleteCheckboxXpath,
+			$this->allowFindingYouViaAutocompleteCheckboxXpathCheckboxId
+		);
+	}
 	/**
 	 * there is no reliable loading indicator on the personal sharing settings page,
 	 * so just wait for files_sharing personal panel div to be there and all Ajax calls to finish
@@ -120,4 +138,20 @@ public function isAutoAcceptFederatedSharesCheckboxDisplayed() {
 		}
 		return true;
 	}
+
+	/**
+	 * Check if the allow finding you via autocomplete checkbox is shown in the webui
+	 *
+	 * @return boolean
+	 */
+	public function isAllowFindingYouViaAutocompleteCheckboxDisplayed() {
+		$localAutoAcceptCheckbox = $this->find(
+			'xpath',
+			$this->allowFindingYouViaAutocompleteCheckboxXpath
+		);
+		if ($localAutoAcceptCheckbox === null) {
+			return false;
+		}
+		return true;
+	}
 }
diff --git a/tests/acceptance/features/webUISharingInternalUsers/shareAutocompletion.feature b/tests/acceptance/features/webUISharingInternalUsers/shareAutocompletion.feature
index 600fa14c26a3..f34c39605569 100644
--- a/tests/acceptance/features/webUISharingInternalUsers/shareAutocompletion.feature
+++ b/tests/acceptance/features/webUISharingInternalUsers/shareAutocompletion.feature
@@ -175,4 +175,96 @@ Feature: Autocompletion of share-with names
     When the user types "r3" in the share-with-field
     Then all users and groups that contain the string "r3" in their name should be listed in the autocomplete list on the webUI
     And the users own name should not be listed in the autocomplete list on the webUI
-    And user "User One" should not be listed in the autocomplete list on the webUI
\ No newline at end of file
+    And user "User One" should not be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: allow user to disable autocomplete in sharing dialog
+    Given user "regularuser" has logged in using the webUI
+    And the user has browsed to the personal sharing settings page
+    When the user disables allow finding you via autocomplete in share dialog
+    And the user re-logs in as "user1" using the webUI
+    And the user browses to the files page
+    And the user opens the share dialog for folder "simple-folder"
+    And the user types "reg" in the share-with-field
+    Then user "Regular User" should not be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: user disables autocomplete in sharing dialog but the sharer types full username
+    Given user "regularuser" has logged in using the webUI
+    And the user has browsed to the personal sharing settings page
+    When the user disables allow finding you via autocomplete in share dialog
+    And the user re-logs in as "user1" using the webUI
+    And the user browses to the files page
+    And the user opens the share dialog for folder "simple-folder"
+    And the user types "regularuser" in the share-with-field
+    Then user "Regular User" should be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: user disables autocomplete in sharing dialog but the sharer types full display name
+    Given user "regularuser" has logged in using the webUI
+    And the user has browsed to the personal sharing settings page
+    When the user disables allow finding you via autocomplete in share dialog
+    And the user re-logs in as "user1" using the webUI
+    And the user browses to the files page
+    And the user opens the share dialog for folder "simple-folder"
+    And the user types "Regular User" in the share-with-field
+    Then user "Regular User" should be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: allow user to enable autocomplete in sharing dialog
+    Given user "regularuser" has logged in using the webUI
+    And the user has browsed to the personal sharing settings page
+    When the user enables allow finding you via autocomplete in share dialog
+    And the user re-logs in as "user1" using the webUI
+    And the user browses to the files page
+    And the user opens the share dialog for folder "simple-folder"
+    And the user types "reg" in the share-with-field
+    Then user "Regular User" should be listed in the autocomplete list on the webUI
+    And the users own name should not be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: autocompletion of a pattern when admin disables username autocompletion in share dialog
+    Given parameter "shareapi_allow_share_dialog_user_enumeration" of app "core" has been set to "no"
+    And user "regularuser" has logged in using the webUI
+    And the user has browsed to the files page
+    And the user has opened the share dialog for folder "simple-folder"
+    When the user types "user" in the share-with-field
+    Then a tooltip with the text "No users or groups found for user" should be shown near the share-with-field on the webUI
+    And the autocomplete list should not be displayed on the webUI
+
+  @skipOnLDAP
+  Scenario: admin disables share dialog user enumeration
+    Given parameter "shareapi_allow_share_dialog_user_enumeration" of app "core" has been set to "no"
+    And user "regularuser" has logged in using the webUI
+    When the user browses to the personal sharing settings page
+    Then allow finding you via autocomplete checkbox should not be displayed on the personal sharing settings page
+
+  @skipOnLDAP
+  Scenario: admin disables share dialog user enumeration and types full user name of user in sharing dialog
+    Given parameter "shareapi_allow_share_dialog_user_enumeration" of app "core" has been set to "no"
+    And user "regularuser" has logged in using the webUI
+    And the user has browsed to the files page
+    And the user has opened the share dialog for folder "simple-folder"
+    When the user types "user1" in the share-with-field
+    Then user "User One" should be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: admin disables share dialog user enumeration and types full display name of user in sharing dialog
+    Given parameter "shareapi_allow_share_dialog_user_enumeration" of app "core" has been set to "no"
+    And user "regularuser" has logged in using the webUI
+    And the user has browsed to the files page
+    And the user has opened the share dialog for folder "simple-folder"
+    When the user types "User One" in the share-with-field
+    Then user "User One" should be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: autocompletion of pattern when user disables and then enables autocompletion in sharing dialog
+    Given user "regularuser" has logged in using the webUI
+    And the user has browsed to the personal sharing settings page
+    When the user disables allow finding you via autocomplete in share dialog
+    And the user enables allow finding you via autocomplete in share dialog
+    And the user re-logs in as "user1" using the webUI
+    And the user browses to the files page
+    And the user opens the share dialog for folder "simple-folder"
+    And the user types "reg" in the share-with-field
+    Then user "Regular User" should be listed in the autocomplete list on the webUI

From eb107f756939ef870e86ff0b56c879b3c84d84f5 Mon Sep 17 00:00:00 2001
From: Artur Neumann <artur@jankaritech.com>
Date: Fri, 10 May 2019 14:41:40 +0545
Subject: [PATCH 015/131] tests demonstating issue #35200

---
 .../features/bootstrap/WebUIFilesContext.php  | 49 ++++++++++++-
 .../browseDirectlyToDetailsTab.feature        | 68 +++++++++++++++----
 2 files changed, 102 insertions(+), 15 deletions(-)

diff --git a/tests/acceptance/features/bootstrap/WebUIFilesContext.php b/tests/acceptance/features/bootstrap/WebUIFilesContext.php
index e123752a342d..7a7f71f270f5 100644
--- a/tests/acceptance/features/bootstrap/WebUIFilesContext.php
+++ b/tests/acceptance/features/bootstrap/WebUIFilesContext.php
@@ -240,12 +240,13 @@ public function theUserBrowsesToTheFilesPage() {
 	 * @param string $tabName
 	 * @param string $fileName
 	 * @param string $folderName
+	 * @param boolean $allowToFail
 	 *
 	 * @return void
 	 * @throws Exception
 	 */
 	public function theUserBrowsesDirectlyToDetailsTabOfFileInFolder(
-		$tabName, $fileName, $folderName
+		$tabName, $fileName, $folderName, $allowToFail = false
 	) {
 		$this->currentFolder = '/' . \trim($folderName, '/');
 		$this->currentFile = $fileName;
@@ -256,8 +257,35 @@ public function theUserBrowsesDirectlyToDetailsTabOfFileInFolder(
 		$this->filesPage->browseToFileId(
 			$fileId, $this->currentFolder, $tabName
 		);
-		$this->filesPage->waitTillPageIsLoaded($this->getSession());
-		$this->filesPage->getDetailsDialog()->waitTillPageIsLoaded($this->getSession());
+		$session = $this->getSession();
+		$this->filesPage->waitTillPageIsLoaded($session);
+		if ($allowToFail === true) {
+			try {
+				$this->filesPage->getDetailsDialog()->waitTillPageIsLoaded($session);
+			} catch (\Exception $e) {
+				//ignore it
+			}
+		} else {
+			$this->filesPage->getDetailsDialog()->waitTillPageIsLoaded($session);
+		}
+	}
+
+	/**
+	 * @When the user tries to browse directly to display the :tabName details of file :fileName in folder :folderName
+	 *
+	 * @param string $tabName
+	 * @param string $fileName
+	 * @param string $folderName
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public function theUserTriesToBrowseDirectlyToDetailsTabOfFileInFolder(
+		$tabName, $fileName, $folderName
+	) {
+		$this->theUserBrowsesDirectlyToDetailsTabOfFileInFolder(
+			$tabName, $fileName, $folderName, true
+		);
 	}
 
 	/**
@@ -313,6 +341,21 @@ public function theTabNameDetailsPanelShouldBeVisible($tabName) {
 		);
 	}
 
+	/**
+	 * @Then the :tabName details panel should not be visible
+	 *
+	 * @param string $tabName
+	 *
+	 * @return void
+	 */
+	public function theTabNameDetailsPanelShouldNotBeVisible($tabName) {
+		$detailsDialog = $this->filesPage->getDetailsDialog();
+		PHPUnit\Framework\Assert::assertFalse(
+			$detailsDialog->isDetailsPanelVisible($tabName),
+			"the $tabName panel is visible in the details panel but should not be"
+		);
+	}
+
 	/**
 	 * @Then the share-with field should be visible in the details panel
 	 *
diff --git a/tests/acceptance/features/webUIFiles/browseDirectlyToDetailsTab.feature b/tests/acceptance/features/webUIFiles/browseDirectlyToDetailsTab.feature
index 17a37a5da701..7f0f50a26ce0 100644
--- a/tests/acceptance/features/webUIFiles/browseDirectlyToDetailsTab.feature
+++ b/tests/acceptance/features/webUIFiles/browseDirectlyToDetailsTab.feature
@@ -10,31 +10,75 @@ Feature: browse directly to details tab
 
   @smokeTest
   Scenario Outline: Browse directly to the sharing details of a file
-    When the user browses directly to display the "sharing" details of file "lorem.txt" in folder "<folder>"
+    When the user browses directly to display the "sharing" details of file "<file>" in folder "<folder>"
     Then the thumbnail should be visible in the details panel
     And the "sharing" details panel should be visible
     And the share-with field should be visible in the details panel
     Examples:
-      | folder        |
-      | /             |
-      | simple-folder |
+      | file              | folder        | comment                     |
+      | block-aligned.txt | /             | one of the first files      |
+      | block-aligned.txt | simple-folder | one of the first files      |
+      | lorem.txt         | /             | a file somewhere in between |
+      | lorem.txt         | simple-folder | a file somewhere in between |
+
+  #merge this tests into previous scenario when bug is fixed
+  @smokeTest
+  @issue-35200
+  Scenario Outline: Browse directly to the sharing details of a file
+    When the user tries to browse directly to display the "sharing" details of file "<file>" in folder "<folder>"
+    #Then the thumbnail should be visible in the details panel
+    Then the "sharing" details panel should be visible
+    And the share-with field should not be visible in the details panel
+    #And the share-with field should be visible in the details panel
+    Examples:
+      | file                                 | folder        | comment   |
+      | zzzz-must-be-last-file-in-folder.txt | /             | last file |
+      | zzzz-must-be-last-file-in-folder.txt | simple-folder | last file |
 
   @comments-app-required
   Scenario Outline: Browse directly to the comments details of a file
-    When the user browses directly to display the "comments" details of file "lorem.txt" in folder "<folder>"
+    When the user browses directly to display the "comments" details of file "<file>" in folder "<folder>"
     Then the thumbnail should be visible in the details panel
     And the "comments" details panel should be visible
     Examples:
-      | folder        |
-      | /             |
-      | simple-folder |
+      | file              | folder        | comment                     |
+      | block-aligned.txt | /             | one of the first files      |
+      | block-aligned.txt | simple-folder | one of the first files      |
+      | lorem.txt         | /             | a file somewhere in between |
+      | lorem.txt         | simple-folder | a file somewhere in between |
+
+  #merge this tests into previous scenario when bug is fixed
+  @issue-35200
+  @comments-app-required
+  Scenario Outline: Browse directly to the comments details of a file
+    When the user tries to browse directly to display the "comments" details of file "<file>" in folder "<folder>"
+    #Then the thumbnail should be visible in the details panel
+    Then the "comments" details panel should be visible
+    Examples:
+      | file                                 | folder        | comment   |
+      | zzzz-must-be-last-file-in-folder.txt | /             | last file |
+      | zzzz-must-be-last-file-in-folder.txt | simple-folder | last file |
 
   @files_versions-app-required
   Scenario Outline: Browse directly to the versions details of a file
-    When the user browses directly to display the "versions" details of file "lorem.txt" in folder "<folder>"
+    When the user browses directly to display the "versions" details of file "<file>" in folder "<folder>"
     Then the thumbnail should be visible in the details panel
     And the "versions" details panel should be visible
     Examples:
-      | folder        |
-      | /             |
-      | simple-folder |
+      | file              | folder        | comment                     |
+      | block-aligned.txt | /             | one of the first files      |
+      | block-aligned.txt | simple-folder | one of the first files      |
+      | lorem.txt         | /             | a file somewhere in between |
+      | lorem.txt         | simple-folder | a file somewhere in between |
+
+  #merge this tests into previous scenario when bug is fixed
+  @issue-35200
+  @files_versions-app-required
+  Scenario Outline: Browse directly to the versions details of a file
+    When the user tries to browse directly to display the "versions" details of file "<file>" in folder "<folder>"
+    #Then the thumbnail should be visible in the details panel
+    Then the "versions" details panel should be visible
+    Examples:
+      | file                                 | folder        | comment   |
+      | zzzz-must-be-last-file-in-folder.txt | /             | last file |
+      | zzzz-must-be-last-file-in-folder.txt | simple-folder | last file |
\ No newline at end of file

From c565eafff298d32566adc499112388cc6c6039c4 Mon Sep 17 00:00:00 2001
From: bhawana <bhawana.prs@gmail.com>
Date: Fri, 10 May 2019 16:32:52 +0545
Subject: [PATCH 016/131] Acceptance test for renaming folders with  different
 path in Shared By Link section

---
 tests/acceptance/features/lib/FilesPage.php   | 32 ++++++++++---------
 .../acceptance/features/lib/FilesPageCRUD.php | 14 ++++++++
 .../shareByPublicLink.feature                 | 15 +++++++++
 3 files changed, 46 insertions(+), 15 deletions(-)

diff --git a/tests/acceptance/features/lib/FilesPage.php b/tests/acceptance/features/lib/FilesPage.php
index 1e97195c5d44..36198bfb402b 100644
--- a/tests/acceptance/features/lib/FilesPage.php
+++ b/tests/acceptance/features/lib/FilesPage.php
@@ -125,6 +125,23 @@ public function createFolder(
 		);
 	}
 
+	/**
+	 * returns the tooltip that is displayed next to the filename
+	 * if something is wrong
+	 *
+	 * @param string $fileName
+	 * @param Session $session
+	 *
+	 * @return string
+	 */
+	public function getTooltipOfFile(
+		$fileName, Session $session
+	) {
+		return $this->filesPageCRUDFunctions->getTooltipOfFile(
+			$fileName, $session
+		);
+	}
+
 	/**
 	 *
 	 * @throws ElementNotFoundException
@@ -257,21 +274,6 @@ public function moveFileTo(
 		);
 	}
 
-	/**
-	 * returns the tooltip that is displayed next to the filename
-	 * if something is wrong
-	 *
-	 * @param string $fileName
-	 * @param Session $session
-	 *
-	 * @return string
-	 * @throws ElementNotFoundException
-	 */
-	public function getTooltipOfFile($fileName, Session $session) {
-		$fileRow = $this->findFileRowByName($fileName, $session);
-		return $fileRow->getTooltip();
-	}
-
 	/**
 	 * same as the original open() function but with a more slack
 	 * URL verification as oC adds some extra parameters to the URL e.g.
diff --git a/tests/acceptance/features/lib/FilesPageCRUD.php b/tests/acceptance/features/lib/FilesPageCRUD.php
index 02d9d1ef1d97..d8940b91f023 100644
--- a/tests/acceptance/features/lib/FilesPageCRUD.php
+++ b/tests/acceptance/features/lib/FilesPageCRUD.php
@@ -151,6 +151,20 @@ protected function getDeleteAllSelectedBtnXpath() {
 		return $this->deleteAllSelectedBtnXpath;
 	}
 
+	/**
+	 * returns the tooltip that is displayed next to the filename
+	 * if something is wrong
+	 *
+	 * @param string $fileName
+	 * @param Session $session
+	 *
+	 * @return string
+	 */
+	public function getTooltipOfFile($fileName, Session $session) {
+		$fileRow = $this->findFileRowByName($fileName, $session);
+		return $fileRow->getTooltip();
+	}
+
 	/**
 	 * {@inheritDoc}
 	 *
diff --git a/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature b/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
index fb5365cd1f59..59d201c74693 100644
--- a/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
+++ b/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
@@ -408,3 +408,18 @@ Feature: Share by public link
     And folder "newfolder" should not be listed on the webUI
     #And folder "newfolder" should be listed on the webUI
     And folder "test" should be listed on the webUI
+
+    @issue-35174
+    Scenario: User renames folders with different path in Shared by link page
+      Given user "user1" has created folder "nf1"
+      And user "user1" has created folder "nf1/newfolder"
+      And user "user1" has created folder "test"
+      And user "user1" has created a public link share with settings
+        | path | nf1/newfolder |
+      And user "user1" has created a public link share with settings
+        | path | test |
+      And the user has browsed to the shared-by-link page
+      When the user renames folder "test" to "newfolder" using the webUI
+      Then near folder "test" a tooltip with the text 'newfolder already exists' should be displayed on the webUI
+      #Then folder "newfolder" should be listed on the webUI
+      #And folder "newfolder" should be listed on the webUI
\ No newline at end of file

From ee452d6065135d6d070214ccf5410ee34701f419 Mon Sep 17 00:00:00 2001
From: bhawana <bhawana.prs@gmail.com>
Date: Tue, 14 May 2019 15:50:53 +0545
Subject: [PATCH 017/131] Acceptance test for renaming folders with  different
 path in Shared By Link section

---
 .../features/webUISharingPublic/shareByPublicLink.feature    | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature b/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
index 59d201c74693..494cba0399a1 100644
--- a/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
+++ b/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
@@ -421,5 +421,6 @@ Feature: Share by public link
       And the user has browsed to the shared-by-link page
       When the user renames folder "test" to "newfolder" using the webUI
       Then near folder "test" a tooltip with the text 'newfolder already exists' should be displayed on the webUI
-      #Then folder "newfolder" should be listed on the webUI
-      #And folder "newfolder" should be listed on the webUI
\ No newline at end of file
+      #Then the following folder should be listed on the webUI
+        #| newfolder |
+        #| newfolder |

From 357cbe13f54192f73dab88cedae6abc4e7b62025 Mon Sep 17 00:00:00 2001
From: Artur Neumann <artur@jankaritech.com>
Date: Thu, 16 May 2019 16:51:52 +0545
Subject: [PATCH 018/131] quote inline code when checking response

---
 tests/acceptance/features/bootstrap/WebDavPropertiesContext.php | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/acceptance/features/bootstrap/WebDavPropertiesContext.php b/tests/acceptance/features/bootstrap/WebDavPropertiesContext.php
index 9a1b4ccb858f..6505d2f4d48b 100644
--- a/tests/acceptance/features/bootstrap/WebDavPropertiesContext.php
+++ b/tests/acceptance/features/bootstrap/WebDavPropertiesContext.php
@@ -322,7 +322,7 @@ public function assertValueOfItemInResponseRegExp($xpath, $pattern) {
 		);
 		$value = $xmlPart[0]->__toString();
 		$pattern = $this->featureContext->substituteInLineCodes(
-			$pattern
+			$pattern, ['preg_quote' => ['/'] ]
 		);
 		PHPUnit\Framework\Assert::assertRegExp(
 			$pattern, $value,

From 8145dbc1bd3e8527d3ac2efeb6e496350ab6391a Mon Sep 17 00:00:00 2001
From: Dipak Acharya <dpakach@gmail.com>
Date: Wed, 15 May 2019 15:49:29 +0545
Subject: [PATCH 019/131] Add api acceptance test for checking that the
 sensitive data are not exposed by ocs api on share

---
 .../createShare.feature                       | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/tests/acceptance/features/apiShareManagementBasic/createShare.feature b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
index e76b9a22cdc0..cfa92dd8cd76 100644
--- a/tests/acceptance/features/apiShareManagementBasic/createShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
@@ -123,6 +123,27 @@ Feature: sharing
       | 1               | 100             |
       | 2               | 200             |
 
+  @public_link_share-feature-required
+  Scenario Outline: Getting the share information of public link share form OCS API does not expose sensitive information
+    Given using OCS API version "<ocs_api_version>"
+    When user "user0" creates a public link share using the sharing API with settings
+      | path     | welcome.txt   |
+    Then the OCS status code should be "<ocs_status_code>"
+    And the HTTP status code should be "200"
+    And the share fields of the last share should include
+      | file_target            | /welcome.txt   |
+      | path                   | /welcome.txt   |
+      | item_type              | file           |
+      | share_type             | 3              |
+      | permissions            | 1              |
+      | uid_owner              | user0          |
+      | share_with             | ***redacted*** |
+      | share_with_displayname | ***redacted*** |
+    Examples:
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
+
   Scenario Outline: Creating a new share with a disabled user
     Given using OCS API version "<ocs_api_version>"
     And user "user1" has been created with default attributes

From 197ea57ecbe90b33cdb64305a491792122a8b8cc Mon Sep 17 00:00:00 2001
From: Artur Neumann <artur@jankaritech.com>
Date: Fri, 17 May 2019 16:31:38 +0545
Subject: [PATCH 020/131] restore acceptance tests to the correct server

---
 tests/acceptance/features/bootstrap/AppConfiguration.php | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tests/acceptance/features/bootstrap/AppConfiguration.php b/tests/acceptance/features/bootstrap/AppConfiguration.php
index 0c4367440d2e..82d2bd7fc56b 100644
--- a/tests/acceptance/features/bootstrap/AppConfiguration.php
+++ b/tests/acceptance/features/bootstrap/AppConfiguration.php
@@ -462,7 +462,11 @@ private function restoreParameters($server) {
 				|| $currentConfigList["system"][$configKey] !== $this->savedConfigList[$server]['system'][$configKey]
 			) {
 				SetupHelper::runOcc(
-					['config:system:set', "--type=json", "--value=" . \json_encode($configValue), $configKey]
+					['config:system:set', "--type=json", "--value=" . \json_encode($configValue), $configKey],
+					$this->getAdminUsername(),
+					$this->getAdminPassword(),
+					$this->getBaseUrl(),
+					$this->getOcPath()
 				);
 			}
 		}

From 5cebc6e7b6b71cbeebd9b5c51c5d350770cbfb22 Mon Sep 17 00:00:00 2001
From: Dipak Acharya <dpakach@gmail.com>
Date: Mon, 20 May 2019 15:02:12 +0545
Subject: [PATCH 021/131] Add exception page page object and its related steps
 in acceptance test

---
 .../bootstrap/WebUIGeneralContext.php         | 56 ++++++++++++-
 .../features/lib/GeneralExceptionPage.php     | 79 +++++++++++++++++++
 2 files changed, 134 insertions(+), 1 deletion(-)
 create mode 100644 tests/acceptance/features/lib/GeneralExceptionPage.php

diff --git a/tests/acceptance/features/bootstrap/WebUIGeneralContext.php b/tests/acceptance/features/bootstrap/WebUIGeneralContext.php
index 3d053d100e09..fc396ca9a167 100644
--- a/tests/acceptance/features/bootstrap/WebUIGeneralContext.php
+++ b/tests/acceptance/features/bootstrap/WebUIGeneralContext.php
@@ -33,6 +33,7 @@
 use TestHelpers\SetupHelper;
 use TestHelpers\UploadHelper;
 use Page\GeneralErrorPage;
+use Page\GeneralExceptionPage;
 
 require_once 'bootstrap.php';
 
@@ -48,6 +49,12 @@ class WebUIGeneralContext extends RawMinkContext implements Context {
 	 */
 	private $generalErrorPage;
 
+	/**
+	 *
+	 * @var GeneralExceptionPage
+	 */
+	private $generalExceptionPage;
+
 	/**
 	 *
 	 * @var LoginPage
@@ -141,15 +148,18 @@ class WebUIGeneralContext extends RawMinkContext implements Context {
 	 * @param OwncloudPage $owncloudPage
 	 * @param LoginPage $loginPage
 	 * @param GeneralErrorPage $generalErrorPage
+	 * @param GeneralExceptionPage $generalExceptionPage
 	 */
 	public function __construct(
 		OwncloudPage $owncloudPage,
 		LoginPage $loginPage,
-		GeneralErrorPage $generalErrorPage
+		GeneralErrorPage $generalErrorPage,
+		GeneralExceptionPage $generalExceptionPage
 	) {
 		$this->owncloudPage = $owncloudPage;
 		$this->loginPage = $loginPage;
 		$this->generalErrorPage = $generalErrorPage;
+		$this->generalExceptionPage = $generalExceptionPage;
 	}
 
 	/**
@@ -459,6 +469,50 @@ public function anErrorShouldBeDisplayedOnTheGeneralErrorPage($error) {
 		);
 	}
 
+	/**
+	 * @Then the user should be redirected to the general exception webUI page with the title :title
+	 *
+	 * @param string $title
+	 *
+	 * @return void
+	 */
+	public function theUserShouldBeRedirectedToGeneralExceptionPage($title) {
+		$title = $this->featureContext->substituteInLineCodes($title);
+		$this->generalExceptionPage->waitTillPageIsLoaded($this->getSession());
+		// Just check that the actual title starts with the expected title.
+		// Theming can have other text following.
+		PHPUnit\Framework\Assert::assertStringStartsWith(
+			$title, $this->generalExceptionPage->getPageTitle()
+		);
+	}
+
+	/**
+	 * @Then the title of the exception on general exception webUI page should be :title
+	 *
+	 * @param string $title
+	 *
+	 * @return void
+	 */
+	public function anErrorShouldBeDisplayedOnTheGeneralExceptionPageWithTitle($title) {
+		PHPUnit\Framework\Assert::assertEquals(
+			$title, $this->generalExceptionPage->getExceptionTitle()
+		);
+	}
+
+	/**
+	 * @Then a message should be displayed on the general exception webUI page containing :message
+	 *
+	 * @param string $message
+	 *
+	 * @return void
+	 */
+	public function anErrorShouldBeDisplayedOnTheGeneralErrorPageContaining($message) {
+		PHPUnit\Framework\Assert::assertContains(
+			$message,
+			$this->generalExceptionPage->getExceptionMessage()
+		);
+	}
+
 	/**
 	 * @When /^the administrator (disables|enables) the setting "([^"]*)" in the section "([^"]*)"$/
 	 *
diff --git a/tests/acceptance/features/lib/GeneralExceptionPage.php b/tests/acceptance/features/lib/GeneralExceptionPage.php
new file mode 100644
index 000000000000..bf894a8b0439
--- /dev/null
+++ b/tests/acceptance/features/lib/GeneralExceptionPage.php
@@ -0,0 +1,79 @@
+<?php
+/**
+ * ownCloud
+ *
+ * @author Dipak Acharya <dipak@jankaritech.com>
+ * @copyright Copyright (c) 2019 Dipak Acharya dipak@jankaritech.com
+ *
+ * This code is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU Affero General Public License,
+ * as published by the Free Software Foundation;
+ * either version 3 of the License, or any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU Affero General Public License for more details.
+ *
+ * You should have received a copy of the GNU Affero General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>
+ *
+ */
+
+namespace Page;
+
+use Behat\Mink\Session;
+use SensioLabs\Behat\PageObjectExtension\PageObject\Exception\ElementNotFoundException;
+
+/**
+ * GeneralExceptionPage page.
+ */
+class GeneralExceptionPage extends OwncloudPage {
+	protected $exceptionTitleXpath = ".//span[@class='error error-wide']//h2[1]";
+	protected $exceptionMessageXpath = ".//span[@class='error error-wide']//p[@class='hint']";
+
+	/**
+	 *
+	 * @throws ElementNotFoundException
+	 * @return string
+	 */
+	public function getExceptionMessage() {
+		$exceptionMessageElement = $this->find("xpath", $this->exceptionMessageXpath);
+		$this->assertElementNotNull(
+			$exceptionMessageElement,
+			__METHOD__ .
+			" could not find exception message xpath: '$this->exceptionMessageXpath'"
+		);
+		return $exceptionMessageElement->getText();
+	}
+
+	/**
+	 *
+	 * @throws ElementNotFoundException
+	 * @return string
+	 */
+	public function getExceptionTitle() {
+		$exceptionTitleElement = $this->find("xpath", $this->exceptionTitleXpath);
+		$this->assertElementNotNull(
+			$exceptionTitleElement,
+			__METHOD__ .
+			" could not find exception title xpath: '$this->exceptionTitleXpath'"
+		);
+		return $exceptionTitleElement->getText();
+	}
+
+	/**
+	 *
+	 * @param Session $session
+	 * @param int $timeout_msec
+	 *
+	 * @return void
+	 * @throws \Exception
+	 */
+	public function waitTillPageIsLoaded(
+		Session $session,
+		$timeout_msec = STANDARD_UI_WAIT_TIMEOUT_MILLISEC
+	) {
+		$this->waitTillXpathIsVisible($this->exceptionTitleXpath, $timeout_msec);
+	}
+}

From 314af4275c991353b8a0fc875278ab6aea1d3fb8 Mon Sep 17 00:00:00 2001
From: Dipak Acharya <dpakach@gmail.com>
Date: Sun, 12 May 2019 14:22:44 +0545
Subject: [PATCH 022/131] Add WebUI acceptance tests for checking permissions
 on public link share

---
 .../features/bootstrap/WebUIFilesContext.php  | 54 ++++++++++++++++++
 .../features/lib/FilesPageBasic.php           | 14 +++++
 .../acceptance/features/lib/FilesPageCRUD.php |  3 +
 .../lib/FilesPageElement/FileActionsMenu.php  | 20 +++++++
 .../features/lib/FilesPageElement/FileRow.php | 13 +++++
 .../shareByPublicLink.feature                 | 57 +++++++++++++++++++
 6 files changed, 161 insertions(+)

diff --git a/tests/acceptance/features/bootstrap/WebUIFilesContext.php b/tests/acceptance/features/bootstrap/WebUIFilesContext.php
index 7a7f71f270f5..76ce913f754c 100644
--- a/tests/acceptance/features/bootstrap/WebUIFilesContext.php
+++ b/tests/acceptance/features/bootstrap/WebUIFilesContext.php
@@ -1655,6 +1655,60 @@ public function itShouldNotBePossibleToDeleteFileFolderUsingTheWebUI($name) {
 		}
 	}
 
+	/**
+	 * @Then it should be possible to delete file/folder :name using the webUI
+	 *
+	 * @param string $name
+	 *
+	 * @return void
+	 * @throws \Exception
+	 */
+	public function itShouldBePossibleToDeleteFileFolderUsingTheWebUI($name) {
+		$this->deleteTheFileUsingTheWebUI($name, true);
+	}
+
+	/**
+	 * @Then /^the option to (delete|rename|download)\s?(?:file|folder) "([^"]*)" should (not|)\s?be available in the webUI$/
+	 *
+	 * @param string $action
+	 * @param string $name
+	 * @param string $shouldOrNot
+	 *
+	 * @return void
+	 * @throws \Exception
+	 */
+	public function optionShouldNotBeAvailable($action, $name, $shouldOrNot) {
+		$visible = $shouldOrNot !== "not";
+		$pageObject = $this->getCurrentPageObject();
+		$session = $this->getSession();
+		$pageObject->waitTillPageIsLoaded($session);
+		$fileRow = $pageObject->findFileRowByName($name, $session);
+		$action = \ucfirst($action);
+		if ($visible) {
+			PHPUnit\Framework\Assert::assertTrue($fileRow->isActionLabelAvailable($action, $session));
+		} else {
+			PHPUnit\Framework\Assert::assertFalse($fileRow->isActionLabelAvailable($action, $session));
+		}
+		$fileRow->clickFileActionButton();
+	}
+
+	/**
+	 * @Then /^the option to upload file should (not|)\s?be available in the webUI$/
+	 *
+	 * @param string $shouldOrNot
+	 *
+	 * @return void
+	 * @throws \Exception
+	 */
+	public function uploadButtonShouldNotBeVisible($shouldOrNot) {
+		$visible = $shouldOrNot !== "not";
+		if ($visible) {
+			PHPUnit\Framework\Assert::assertTrue($this->getCurrentPageObject()->isUploadButtonAvailable());
+		} else {
+			PHPUnit\Framework\Assert::assertFalse($this->getCurrentPageObject()->isUploadButtonAvailable());
+		}
+	}
+
 	/**
 	 * @Then the files action menu should be completely visible after opening it using the webUI
 	 *
diff --git a/tests/acceptance/features/lib/FilesPageBasic.php b/tests/acceptance/features/lib/FilesPageBasic.php
index 32076ab51628..eb14fd07297e 100644
--- a/tests/acceptance/features/lib/FilesPageBasic.php
+++ b/tests/acceptance/features/lib/FilesPageBasic.php
@@ -51,6 +51,7 @@ abstract class FilesPageBasic extends OwncloudPage {
 	protected $appSettingsContentId = "app-settings-content";
 	protected $styleOfCheckboxWhenVisible = "display: block;";
 	protected $detailsDialogXpath = "//*[contains(@id, 'app-sidebar') and not(contains(@class, 'disappear'))]";
+	protected $newFileFolderButtonXpath = './/*[@id="controls"]//a[@class="button new"]';
 
 	/**
 	 * @return string
@@ -649,4 +650,17 @@ public function enableShowHiddenFilesSettings() {
 		);
 		$showHiddenFilesCheckBox->click();
 	}
+
+	/**
+	 * Return is New File/folder button is available in the webUI
+	 *
+	 * @return boolean
+	 */
+	public function isUploadButtonAvailable() {
+		$btn = $this->find("xpath", $this->newFileFolderButtonXpath);
+		if ($btn === null) {
+			return false;
+		}
+		return $btn->isVisible();
+	}
 }
diff --git a/tests/acceptance/features/lib/FilesPageCRUD.php b/tests/acceptance/features/lib/FilesPageCRUD.php
index d8940b91f023..5181f0df46e9 100644
--- a/tests/acceptance/features/lib/FilesPageCRUD.php
+++ b/tests/acceptance/features/lib/FilesPageCRUD.php
@@ -416,6 +416,9 @@ public function deleteFile(
 			$message = "INFORMATION: retried to delete file '$name' $counter times";
 			echo $message;
 			\error_log($message);
+			if ($counter === $maxRetries) {
+				throw new \Exception($message);
+			}
 		}
 	}
 
diff --git a/tests/acceptance/features/lib/FilesPageElement/FileActionsMenu.php b/tests/acceptance/features/lib/FilesPageElement/FileActionsMenu.php
index 40e8f602e604..fbba563e9e08 100644
--- a/tests/acceptance/features/lib/FilesPageElement/FileActionsMenu.php
+++ b/tests/acceptance/features/lib/FilesPageElement/FileActionsMenu.php
@@ -218,4 +218,24 @@ public function getRenameActionLabel() {
 	public function getActionLabelLocalized($action) {
 		return $this->findButton($action)->getText();
 	}
+
+	/**
+	 * return if the Action label is visible
+	 *
+	 * @param string $action ("Delete"|"Rename"|"Details")
+	 *
+	 * @return boolean
+	 */
+	public function isActionLabelVisible($action) {
+		$xpathLocator = \sprintf($this->fileActionXpath, $action);
+		$this->waitTillElementIsNotNull($xpathLocator);
+		$button = $this->menuElement->find(
+			"xpath",
+			$xpathLocator
+		);
+		if (!$button) {
+			return false;
+		}
+		return $button->isVisible();
+	}
 }
diff --git a/tests/acceptance/features/lib/FilesPageElement/FileRow.php b/tests/acceptance/features/lib/FilesPageElement/FileRow.php
index d0d90eefb46d..be2e52a01aff 100644
--- a/tests/acceptance/features/lib/FilesPageElement/FileRow.php
+++ b/tests/acceptance/features/lib/FilesPageElement/FileRow.php
@@ -572,4 +572,17 @@ public function getHighlightsElement() {
 		);
 		return $element;
 	}
+
+	/**
+	 * Returns if action menu is Available in the fileRow
+	 *
+	 * @param string $actionLabel
+	 * @param Session $session
+	 *
+	 * @return boolean
+	 */
+	public function isActionLabelAvailable($actionLabel, Session $session) {
+		$actionMenu = $this->openFileActionsMenu($session);
+		return $actionMenu->isActionLabelVisible($actionLabel);
+	}
 }
diff --git a/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature b/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
index 494cba0399a1..6d3f2f17acc2 100644
--- a/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
+++ b/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
@@ -424,3 +424,60 @@ Feature: Share by public link
       #Then the following folder should be listed on the webUI
         #| newfolder |
         #| newfolder |
+
+  Scenario: Permissions work correctly on public link share with upload-write-without-modify
+    Given the user has created a new public link for folder "simple-folder" using the webUI with
+      | permission | upload-write-without-modify |
+    When the public accesses the last created public link using the webUI
+    Then the option to rename file "lorem.txt" should not be available in the webUI
+    And the option to delete file "lorem.txt" should not be available in the webUI
+    And the option to upload file should be available in the webUI
+
+  Scenario: Permissions work correctly on public link share with read-write
+    Given the user has created a new public link for folder "simple-folder" using the webUI with
+      | permission | read-write |
+    When the public accesses the last created public link using the webUI
+    Then the option to rename file "lorem.txt" should be available in the webUI
+    And the option to delete file "lorem.txt" should be available in the webUI
+    And the option to upload file should be available in the webUI
+
+  Scenario: User tries to upload existing file in public link share with permissions upload-write-without-modify
+    Given the user has created a new public link for folder "simple-folder" using the webUI with
+      | permission | upload-write-without-modify |
+    And the public accesses the last created public link using the webUI
+    When the user uploads file "lorem.txt" using the webUI
+    Then a notification should be displayed on the webUI with the text "The file lorem.txt already exists"
+    And file "lorem.txt" should be listed on the webUI
+    And file "lorem (2).txt" should not be listed on the webUI
+
+  Scenario: User tries to upload existing file in public link share with permissions read-write
+    Given the user has created a new public link for folder "simple-folder" using the webUI with
+      | permission | read-write |
+    And the public accesses the last created public link using the webUI
+    When the user uploads file "lorem.txt" keeping both new and existing files using the webUI
+    Then file "lorem.txt" should be listed on the webUI
+    And file "lorem (2).txt" should be listed on the webUI
+
+  Scenario: Editing the permission on a existing share from read-write to upload-write-without-modify works correctly
+    Given the user has created a new public link for folder "simple-folder" using the webUI with
+      | permission | read-write |
+    And the public accesses the last created public link using the webUI
+    Then it should be possible to delete file "lorem.txt" using the webUI
+    When the user browses to the files page
+    And the user opens the share dialog for folder "simple-folder"
+    And the user opens the public link share tab
+    And the user changes the permission of the public link named "Public link" to "upload-write-without-modify"
+    And the public accesses the last created public link using the webUI
+    Then the option to delete file "lorem-big.txt" should not be available in the webUI
+
+  Scenario: Editing the permission on a existing share from upload-write-without-modify to read-write works correctly
+    Given the user has created a new public link for folder "simple-folder" using the webUI with
+      | permission | upload-write-without-modify |
+    And the public accesses the last created public link using the webUI
+    Then the option to delete file "lorem.txt" should not be available in the webUI
+    When the user browses to the files page
+    And the user opens the share dialog for folder "simple-folder"
+    And the user opens the public link share tab
+    And the user changes the permission of the public link named "Public link" to "read-write"
+    And the public accesses the last created public link using the webUI
+    Then it should be possible to delete file "lorem-big.txt" using the webUI
\ No newline at end of file

From 39cbb80ead735ea0134b8b866e2e3d498879e4c8 Mon Sep 17 00:00:00 2001
From: Dipak Acharya <dpakach@gmail.com>
Date: Sun, 12 May 2019 21:47:04 +0545
Subject: [PATCH 023/131] API acceptance tests for public link share
 permissions

---
 .../createShare.feature                       |  2 +-
 .../updateShare.feature                       | 40 ++++++++++
 .../changingFilesShare.feature                | 79 ++++++++++++++++++-
 .../bootstrap/PublicWebDavContext.php         | 38 +++++++++
 .../acceptance/features/bootstrap/Sharing.php |  1 +
 5 files changed, 158 insertions(+), 2 deletions(-)

diff --git a/tests/acceptance/features/apiShareManagementBasic/createShare.feature b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
index cfa92dd8cd76..95a7f7f34651 100644
--- a/tests/acceptance/features/apiShareManagementBasic/createShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
@@ -587,4 +587,4 @@ Feature: sharing
     Examples:
       | ocs_api_version | ocs_status_code |
       | 1               | 100             |
-      | 2               | 200             |
+      | 2               | 200             |
\ No newline at end of file
diff --git a/tests/acceptance/features/apiShareManagementBasic/updateShare.feature b/tests/acceptance/features/apiShareManagementBasic/updateShare.feature
index 39c301f04ec2..cb633d1c0192 100644
--- a/tests/acceptance/features/apiShareManagementBasic/updateShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/updateShare.feature
@@ -440,3 +440,43 @@ Feature: sharing
       | ocs_api_version | ocs_status_code |
       | 1               | 100             |
       | 2               | 200             |
+
+  @public_link_share-feature-required
+  Scenario Outline: Updating share permissions from change to read/update/create restricts public from deleting files
+    Given using OCS API version "<ocs_api_version>"
+    And user "user0" has created a public link share with settings
+      | path        | /PARENT |
+      | permissions | 15      |
+    When user "user0" updates the last share using the sharing API with
+      | permissions | 7 |
+    Then the OCS status code should be "<ocs_status_code>"
+    And the HTTP status code should be "200"
+    When the user gets the info of the last share using the sharing API
+    Then the share fields of the last share should include
+      | permissions | 7 |
+    When the public deletes file "CHILD/child.txt" from the last public share using the public WebDAV API
+    Then the HTTP status code should be "403"
+    Examples:
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
+
+  @public_link_share-feature-required
+  Scenario Outline: Updating share permissions from read/update/create to change allows public to delete files
+    Given using OCS API version "<ocs_api_version>"
+    And user "user0" has created a public link share with settings
+      | path        | /PARENT |
+      | permissions | 7       |
+    When user "user0" updates the last share using the sharing API with
+      | permissions | 15 |
+    Then the OCS status code should be "<ocs_status_code>"
+    And the HTTP status code should be "200"
+    When the user gets the info of the last share using the sharing API
+    Then the share fields of the last share should include
+      | permissions | 15 |
+    When the public deletes file "CHILD/child.txt" from the last public share using the public WebDAV API
+    Then the HTTP status code should be "204"
+    Examples:
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
\ No newline at end of file
diff --git a/tests/acceptance/features/apiShareOperations/changingFilesShare.feature b/tests/acceptance/features/apiShareOperations/changingFilesShare.feature
index 197d14a30cc0..6adab561d552 100644
--- a/tests/acceptance/features/apiShareOperations/changingFilesShare.feature
+++ b/tests/acceptance/features/apiShareOperations/changingFilesShare.feature
@@ -37,4 +37,81 @@ Feature: sharing
     Then as "user1" file "/taken_out" should exist
     And as "user0" folder "/shared/sub" should not exist
     And as "user0" folder "/sub" should exist in trash
-    And as "user0" file "/sub/shared_file.txt" should exist in trash
\ No newline at end of file
+    And as "user0" file "/sub/shared_file.txt" should exist in trash
+
+  @public_link_share-feature-required
+  Scenario Outline: Public can delete file through publicly shared link having delete permissions
+    Given using OCS API version "<ocs_api_version>"
+    And user "user0" has moved file "welcome.txt" to "PARENT/welcome.txt"
+    When user "user0" creates a public link share using the sharing API with settings
+      | path        | /PARENT       |
+      | permissions | <permissions> |
+    And the public deletes file "welcome.txt" from the last public share using the public WebDAV API
+    Then the HTTP status code should be "<http-status-code>"
+    And as "user0" file "PARENT/welcome.txt" <should-or-not> exist
+    Examples:
+      | ocs_api_version | permissions               | http-status-code | should-or-not |
+      | 1               | read,update,create        | 403              | should        |
+      | 2               | read,update,create        | 403              | should        |
+      | 1               | read,update,create,delete | 204              | should not    |
+      | 2               | read,update,create,delete | 204              | should not    |
+
+  @public_link_share-feature-required
+  Scenario Outline: Public link share permissions work correctly for renaming and share permissions read,update,create
+    Given using OCS API version "<ocs_api_version>"
+    When user "user0" creates a public link share using the sharing API with settings
+      | path        | /PARENT            |
+      | permissions | read,update,create |
+    And the public renames file "parent.txt" to "newparent.txt" from the last public share using the public WebDAV API
+    Then the HTTP status code should be "403"
+    And as "user0" file "/PARENT/parent.txt" should exist
+    And as "user0" file "/PARENT/newparent.txt" should not exist
+    Examples:
+      | ocs_api_version |
+      | 1               |
+      | 2               |
+
+  @public_link_share-feature-required
+  Scenario Outline: Public link share permissions work correctly for renaming and share permissions 15
+    Given using OCS API version "<ocs_api_version>"
+    When user "user0" creates a public link share using the sharing API with settings
+      | path        | /PARENT                   |
+      | permissions | read,update,create,delete |
+    And the public renames file "parent.txt" to "newparent.txt" from the last public share using the public WebDAV API
+    Then the HTTP status code should be "201"
+    And as "user0" file "/PARENT/parent.txt" should not exist
+    And as "user0" file "/PARENT/newparent.txt" should exist
+    Examples:
+      | ocs_api_version |
+      | 1               |
+      | 2               |
+
+  @public_link_share-feature-required
+  Scenario Outline: Public link share permissions work correctly for upload with share permissions read,update,create
+    Given using OCS API version "<ocs_api_version>"
+    And user "user0" has moved file "welcome.txt" to "PARENT/welcome.txt"
+    When user "user0" creates a public link share using the sharing API with settings
+      | path        | /PARENT            |
+      | permissions | read,update,create |
+    And the public uploads file "lorem.txt" with content "test" using the public WebDAV API
+    Then the HTTP status code should be "403"
+    And as "user0" file "/PARENT/lorem.txt" should not exist
+    Examples:
+      | ocs_api_version |
+      | 1               |
+      | 2               |
+
+  @public_link_share-feature-required
+  Scenario Outline: Public link share permissions work correctly for upload with share permissions read,update,create,delete
+    Given using OCS API version "<ocs_api_version>"
+    And user "user0" has moved file "welcome.txt" to "PARENT/welcome.txt"
+    When user "user0" creates a public link share using the sharing API with settings
+      | path        | /PARENT                   |
+      | permissions | read,update,create,delete |
+    And the public uploads file "lorem.txt" with content "test" using the public WebDAV API
+    Then the HTTP status code should be "201"
+    And the content of file "PARENT/lorem.txt" for user "user0" should be "test"
+    Examples:
+      | ocs_api_version |
+      | 1               |
+      | 2               |
\ No newline at end of file
diff --git a/tests/acceptance/features/bootstrap/PublicWebDavContext.php b/tests/acceptance/features/bootstrap/PublicWebDavContext.php
index c69276ff7794..186ad3923f37 100644
--- a/tests/acceptance/features/bootstrap/PublicWebDavContext.php
+++ b/tests/acceptance/features/bootstrap/PublicWebDavContext.php
@@ -67,6 +67,44 @@ public function downloadPublicFile() {
 			HttpRequestHelper::get($fullUrl, $token)
 		);
 	}
+
+	/**
+	 * @When /^the public deletes file "([^"]*)" from the last public share using the public WebDAV API$/
+	 *
+	 * @param string $fileName
+	 *
+	 * @return void
+	 */
+	public function deleteFileFromPublicShare($fileName) {
+		$token = $this->featureContext->getLastShareData()->data->token;
+		$fullUrl = $this->featureContext->getBaseUrl() . "/public.php/webdav/" . $fileName;
+		$headers = [
+			'X-Requested-With' => 'XMLHttpRequest'
+		];
+		$this->featureContext->setResponse(
+			HttpRequestHelper::delete($fullUrl, $token, "", $headers)
+		);
+	}
+
+	/**
+	 * @When /^the public renames file "([^"]*)" to "([^"]*)" from the last public share using the public WebDAV API$/
+	 *
+	 * @param string $fileName
+	 * @param string $toFileName
+	 *
+	 * @return void
+	 */
+	public function renameFileFromPublicShare($fileName, $toFileName) {
+		$token = $this->featureContext->getLastShareData()->data->token;
+		$fullUrl = $this->featureContext->getBaseUrl() . "/public.php/webdav/" . $fileName;
+		$headers = [
+			'X-Requested-With' => 'XMLHttpRequest',
+			'Destination' => $this->featureContext->getBaseUrl() . "/public.php/webdav/" . $toFileName
+		];
+		$this->featureContext->setResponse(
+			HttpRequestHelper::sendRequest($fullUrl, "MOVE", $token, "", $headers)
+		);
+	}
 	
 	/**
 	 * @When /^the public downloads file "([^"]*)" from inside the last public shared folder with range "([^"]*)" using the public WebDAV API$/
diff --git a/tests/acceptance/features/bootstrap/Sharing.php b/tests/acceptance/features/bootstrap/Sharing.php
index 5e39b80c0453..7914bc6cdb45 100644
--- a/tests/acceptance/features/bootstrap/Sharing.php
+++ b/tests/acceptance/features/bootstrap/Sharing.php
@@ -590,6 +590,7 @@ public function userUpdatesTheLastShareWith($user, $body) {
 		$this->response = HttpRequestHelper::put(
 			$fullUrl, $user, $this->getPasswordForUser($user), null, $fd
 		);
+		$this->lastShareData = $this->getResponseXml();
 	}
 
 	/**

From d46a60ca6b300ddbd5f47e19713c458f1e965148 Mon Sep 17 00:00:00 2001
From: Artur Neumann <artur@jankaritech.com>
Date: Wed, 22 May 2019 12:24:48 +0545
Subject: [PATCH 024/131] revert saving response data in lastShareData when
 updating share

this was added in #35204 but causes problems when an invalid request is done but the original `lastShareData` need to be accessed e.g `\Sharing::getMimeTypeOfLastSharedFile`
---
 tests/acceptance/features/bootstrap/Sharing.php | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tests/acceptance/features/bootstrap/Sharing.php b/tests/acceptance/features/bootstrap/Sharing.php
index 7914bc6cdb45..5e39b80c0453 100644
--- a/tests/acceptance/features/bootstrap/Sharing.php
+++ b/tests/acceptance/features/bootstrap/Sharing.php
@@ -590,7 +590,6 @@ public function userUpdatesTheLastShareWith($user, $body) {
 		$this->response = HttpRequestHelper::put(
 			$fullUrl, $user, $this->getPasswordForUser($user), null, $fd
 		);
-		$this->lastShareData = $this->getResponseXml();
 	}
 
 	/**

From 7022643a5e90d90b10bba216953f0b1b10b7e620 Mon Sep 17 00:00:00 2001
From: Artur Neumann <artur@jankaritech.com>
Date: Wed, 22 May 2019 12:28:45 +0545
Subject: [PATCH 025/131] replace checking last share response with just
 checking last response

---
 .../features/apiFederation/federated.feature  |  6 ++--
 .../features/apiMain/external-storage.feature |  2 +-
 .../createShare.feature                       | 18 +++++-----
 .../updateShare.feature                       | 14 ++++----
 .../apiShareOperations/gettingShares.feature  |  2 +-
 .../acceptance/features/bootstrap/Sharing.php | 33 -------------------
 6 files changed, 22 insertions(+), 53 deletions(-)

diff --git a/tests/acceptance/features/apiFederation/federated.feature b/tests/acceptance/features/apiFederation/federated.feature
index c8b92b4091e8..68d24edb93c0 100644
--- a/tests/acceptance/features/apiFederation/federated.feature
+++ b/tests/acceptance/features/apiFederation/federated.feature
@@ -12,7 +12,7 @@ Feature: federated
     When user "user1" from server "LOCAL" shares "/textfile0.txt" with user "user0" from server "REMOTE" using the sharing API
     Then the OCS status code should be "<ocs-status>"
     And the HTTP status code should be "200"
-    And the share fields of the last share should include
+    And the fields of the last response should include
       | id                     | A_NUMBER       |
       | item_type              | file           |
       | item_source            | A_NUMBER       |
@@ -38,7 +38,7 @@ Feature: federated
     When user "user0" from server "REMOTE" shares "/textfile0.txt" with user "user1" from server "LOCAL" using the sharing API
     Then the OCS status code should be "<ocs-status>"
     And the HTTP status code should be "200"
-    And the share fields of the last share should include
+    And the fields of the last response should include
       | id                     | A_NUMBER       |
       | item_type              | file           |
       | item_source            | A_NUMBER       |
@@ -172,7 +172,7 @@ Feature: federated
       | permissions | 19                 |
     Then the OCS status code should be "<ocs-status>"
     And the HTTP status code should be "200"
-    And the share fields of the last share should include
+    And the fields of the last response should include
       | id                     | A_NUMBER           |
       | item_type              | file               |
       | item_source            | A_NUMBER           |
diff --git a/tests/acceptance/features/apiMain/external-storage.feature b/tests/acceptance/features/apiMain/external-storage.feature
index ef9921c91b20..99ce0d8818d3 100644
--- a/tests/acceptance/features/apiMain/external-storage.feature
+++ b/tests/acceptance/features/apiMain/external-storage.feature
@@ -16,7 +16,7 @@ Feature: external-storage
       | path | foo |
     Then the OCS status code should be "100"
     And the HTTP status code should be "200"
-    And the share fields of the last share should include
+    And the fields of the last response should include
       | id       | A_NUMBER             |
       | url      | AN_URL               |
       | token    | A_TOKEN              |
diff --git a/tests/acceptance/features/apiShareManagementBasic/createShare.feature b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
index 95a7f7f34651..5d1ed2bbf5b1 100644
--- a/tests/acceptance/features/apiShareManagementBasic/createShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
@@ -13,7 +13,7 @@ Feature: sharing
     When user "user0" shares file "welcome.txt" with user "user1" using the sharing API
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
-    And the share fields of the last share should include
+    And the fields of the last response should include
       | share_with  | user1        |
       | file_target | /welcome.txt |
       | path        | /welcome.txt |
@@ -30,7 +30,7 @@ Feature: sharing
     When user "user0" shares file "/welcome.txt" with group "grp1" using the sharing API
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
-    And the share fields of the last share should include
+    And the fields of the last response should include
       | share_with  | grp1         |
       | file_target | /welcome.txt |
       | path        | /welcome.txt |
@@ -50,7 +50,7 @@ Feature: sharing
     When user "user0" shares file "/welcome.txt" with user "user1" using the sharing API
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
-    And the share fields of the last share should include
+    And the fields of the last response should include
       | share_with  | user1        |
       | file_target | /welcome.txt |
       | path        | /welcome.txt |
@@ -96,7 +96,7 @@ Feature: sharing
       | permissions | 31          |
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
-    And the share fields of the last share should include
+    And the fields of the last response should include
       | file_target | /welcome.txt |
       | path        | /welcome.txt |
       | item_type   | file         |
@@ -130,7 +130,7 @@ Feature: sharing
       | path     | welcome.txt   |
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
-    And the share fields of the last share should include
+    And the fields of the last response should include
       | file_target            | /welcome.txt   |
       | path                   | /welcome.txt   |
       | item_type              | file           |
@@ -173,7 +173,7 @@ Feature: sharing
       | path | /afolder |
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
-    And the share fields of the last share should include
+    And the fields of the last response should include
       | id          | A_NUMBER |
       | share_type  | 3        |
       | permissions | 1        |
@@ -191,7 +191,7 @@ Feature: sharing
       | path | /afolder |
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
-    And the share fields of the last share should include
+    And the fields of the last response should include
       | id          | A_NUMBER |
       | share_type  | 3        |
       | permissions | 1        |
@@ -209,7 +209,7 @@ Feature: sharing
       | permissions | 15       |
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
-    And the share fields of the last share should include
+    And the fields of the last response should include
       | id          | A_NUMBER |
       | share_type  | 3        |
       | permissions | 15       |
@@ -227,7 +227,7 @@ Feature: sharing
       | permissions | 5        |
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
-    And the share fields of the last share should include
+    And the fields of the last response should include
       | id          | A_NUMBER |
       | share_type  | 3        |
       | permissions | 5        |
diff --git a/tests/acceptance/features/apiShareManagementBasic/updateShare.feature b/tests/acceptance/features/apiShareManagementBasic/updateShare.feature
index cb633d1c0192..c37597cf0ea7 100644
--- a/tests/acceptance/features/apiShareManagementBasic/updateShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/updateShare.feature
@@ -315,7 +315,8 @@ Feature: sharing
     And user "user0" has shared folder "/folder1" with user "user1" with permissions 31
     And user "user1" has shared folder "/folder1/folder2" with user "user2" with permissions 31
     When user "user1" moves folder "/folder1/folder2" to "/moved-out/folder2" using the WebDAV API
-    Then the share fields of the last share should include
+    And user "user1" gets the info of the last share using the sharing API
+    Then the fields of the last response should include
       | id                | A_NUMBER             |
       | item_type         | folder               |
       | item_source       | A_NUMBER             |
@@ -342,7 +343,8 @@ Feature: sharing
     And user "user0" has shared folder "/user0-folder" with user "user1" with permissions 31
     And user "user2" has shared folder "/user2-folder" with user "user1" with permissions 31
     When user "user1" moves folder "/user0-folder/folder2" to "/user2-folder/folder2" using the WebDAV API
-    Then the share fields of the last share should include
+    And user "user2" gets the info of the last share using the sharing API
+    Then the fields of the last response should include
       | id                | A_NUMBER             |
       | item_type         | folder               |
       | item_source       | A_NUMBER             |
@@ -451,8 +453,8 @@ Feature: sharing
       | permissions | 7 |
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
-    When the user gets the info of the last share using the sharing API
-    Then the share fields of the last share should include
+    When user "user0" gets the info of the last share using the sharing API
+    Then the fields of the last response should include
       | permissions | 7 |
     When the public deletes file "CHILD/child.txt" from the last public share using the public WebDAV API
     Then the HTTP status code should be "403"
@@ -471,8 +473,8 @@ Feature: sharing
       | permissions | 15 |
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
-    When the user gets the info of the last share using the sharing API
-    Then the share fields of the last share should include
+    When user "user0" gets the info of the last share using the sharing API
+    Then the fields of the last response should include
       | permissions | 15 |
     When the public deletes file "CHILD/child.txt" from the last public share using the public WebDAV API
     Then the HTTP status code should be "204"
diff --git a/tests/acceptance/features/apiShareOperations/gettingShares.feature b/tests/acceptance/features/apiShareOperations/gettingShares.feature
index cdf77e7dfac5..897220e1162d 100644
--- a/tests/acceptance/features/apiShareOperations/gettingShares.feature
+++ b/tests/acceptance/features/apiShareOperations/gettingShares.feature
@@ -95,7 +95,7 @@ Feature: sharing
     When user "user0" gets the info of the last share using the sharing API
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
-    And the share fields of the last share should include
+    And the fields of the last response should include
       | id                     | A_NUMBER           |
       | item_type              | file               |
       | item_source            | A_NUMBER           |
diff --git a/tests/acceptance/features/bootstrap/Sharing.php b/tests/acceptance/features/bootstrap/Sharing.php
index 5e39b80c0453..7a7e77a0d5a4 100644
--- a/tests/acceptance/features/bootstrap/Sharing.php
+++ b/tests/acceptance/features/bootstrap/Sharing.php
@@ -689,17 +689,6 @@ public function isFieldInResponse($field, $contentExpected, $data = null) {
 		}
 	}
 
-	/**
-	 * @param string $field
-	 * @param string $contentExpected
-	 *
-	 * @return bool
-	 */
-	public function isFieldInShareResponse($field, $contentExpected) {
-		$data = $this->lastShareData->data[0];
-		return $this->isFieldInResponse($field, $contentExpected, $data);
-	}
-
 	/**
 	 * @Then /^file "([^"]*)" should be included in the response$/
 	 *
@@ -1309,28 +1298,6 @@ public function checkingTheResponseEntriesCount($count) {
 		PHPUnit\Framework\Assert::assertEquals($count, $actualCount);
 	}
 
-	/**
-	 * @Then /^the share fields of the last share should include$/
-	 *
-	 * @param TableNode|null $body
-	 *
-	 * @return void
-	 */
-	public function checkShareFields($body) {
-		if ($body instanceof TableNode) {
-			$fd = $body->getRowsHash();
-
-			foreach ($fd as $field => $value) {
-				$value = $this->replaceValuesFromTable($field, $value);
-				if (!$this->isFieldInShareResponse($field, $value)) {
-					PHPUnit\Framework\Assert::fail(
-						"$field doesn't have value $value"
-					);
-				}
-			}
-		}
-	}
-
 	/**
 	 * @Then the fields of the last response should include
 	 *

From 57303b05cbaa47cc26e45451ee61de15d5873401 Mon Sep 17 00:00:00 2001
From: Dipak Acharya <dpakach@gmail.com>
Date: Mon, 20 May 2019 15:09:03 +0545
Subject: [PATCH 026/131] Fix openFile method to handle error in acceptance
 tests

---
 .../features/bootstrap/WebUIFilesContext.php  | 61 ++++++++++++++-----
 1 file changed, 46 insertions(+), 15 deletions(-)

diff --git a/tests/acceptance/features/bootstrap/WebUIFilesContext.php b/tests/acceptance/features/bootstrap/WebUIFilesContext.php
index 76ce913f754c..e44025175e04 100644
--- a/tests/acceptance/features/bootstrap/WebUIFilesContext.php
+++ b/tests/acceptance/features/bootstrap/WebUIFilesContext.php
@@ -34,6 +34,7 @@
 use Page\TrashbinPage;
 use Page\FilesPageElement\ConflictDialog;
 use Page\FilesPageElement\FileActionsMenu;
+use Page\GeneralExceptionPage;
 use SensioLabs\Behat\PageObjectExtension\PageObject\Exception\ElementNotFoundException;
 use TestHelpers\DeleteHelper;
 use TestHelpers\Asserts\WebDav as WebDavAssert;
@@ -144,6 +145,12 @@ class WebUIFilesContext extends RawMinkContext implements Context {
 
 	private $uploadConflictDialogTitle = "file conflict";
 
+	/**
+	 *
+	 * @var GeneralExceptionPage
+	 */
+	private $generalExceptionPage;
+
 	/**
 	 * WebUIFilesContext constructor.
 	 *
@@ -155,6 +162,7 @@ class WebUIFilesContext extends RawMinkContext implements Context {
 	 * @param TagsPage $tagsPage
 	 * @param SharedByLinkPage $sharedByLinkPage
 	 * @param SharedWithOthersPage $sharedWithOthersPage
+	 * @param GeneralExceptionPage $generalExceptionPage
 	 *
 	 * @return void
 	 */
@@ -166,7 +174,8 @@ public function __construct(
 		SharedWithYouPage $sharedWithYouPage,
 		TagsPage $tagsPage,
 		SharedByLinkPage $sharedByLinkPage,
-		SharedWithOthersPage $sharedWithOthersPage
+		SharedWithOthersPage $sharedWithOthersPage,
+		GeneralExceptionPage $generalExceptionPage
 	) {
 		$this->trashbinPage = $trashbinPage;
 		$this->filesPage = $filesPage;
@@ -176,6 +185,7 @@ public function __construct(
 		$this->tagsPage = $tagsPage;
 		$this->sharedByLinkPage = $sharedByLinkPage;
 		$this->sharedWithOthersPage = $sharedWithOthersPage;
+		$this->generalExceptionPage = $generalExceptionPage;
 	}
 
 	/**
@@ -1235,23 +1245,25 @@ public function theUserMarksAllFilesForBatchActionUsingTheWebUI() {
 	}
 
 	/**
-	 * @When /^the user opens (trashbin|)\s?(file|folder) ((?:'[^']*')|(?:"[^"]*")) using the webUI$/
-	 * @Given /^the user has opened (trashbin|)\s?(file|folder) ((?:'[^']*')|(?:"[^"]*")) using the webUI$/
+	 * @When /^the user opens (trashbin|)\s?(file|folder) ((?:'[^']*')|(?:"[^"]*")) (expecting to fail|)\s?using the webUI$/
+	 * @Given /^the user has opened (trashbin|)\s?(file|folder) ((?:'[^']*')|(?:"[^"]*")) (expecting to fail|)\s?using the webUI$/
 	 *
 	 * @param string $typeOfFilesPage
 	 * @param string $fileOrFolder
 	 * @param string $name enclosed in single or double quotes
+	 * @param string $expectToFail
 	 *
 	 * @return void
 	 * @throws \Exception
 	 */
 	public function theUserOpensFolderNamedUsingTheWebUI(
-		$typeOfFilesPage, $fileOrFolder, $name
+		$typeOfFilesPage, $fileOrFolder, $name, $expectToFail
 	) {
+		$expectToFail = $expectToFail !== "";
 		// The capturing groups of the regex include the quotes at each
 		// end of the captured string, so trim them.
 		$this->theUserOpensTheFileOrFolderUsingTheWebUI(
-			$typeOfFilesPage, $fileOrFolder, \trim($name, $name[0])
+			$typeOfFilesPage, $fileOrFolder, \trim($name, $name[0]), $expectToFail
 		);
 	}
 
@@ -1265,12 +1277,13 @@ public function theUserOpensFolderNamedUsingTheWebUI(
 	 * @param string|array $relativePath the path from the currently open folder
 	 *                                   down to and including the file or folder
 	 *                                   to open
+	 * @param boolean $expectToFail
 	 *
 	 * @return void
 	 * @throws \Exception
 	 */
 	public function theUserOpensTheFileOrFolderUsingTheWebUI(
-		$typeOfFilesPage, $fileOrFolder, $relativePath
+		$typeOfFilesPage, $fileOrFolder, $relativePath, $expectToFail = false
 	) {
 		if ($typeOfFilesPage === "trashbin") {
 			$this->theUserBrowsesToTheTrashbinPage();
@@ -1293,19 +1306,37 @@ public function theUserOpensTheFileOrFolderUsingTheWebUI(
 			$breadCrumbs = \explode('/', \ltrim($relativePath, '/'));
 			$breadCrumbsForOpenFile = $breadCrumbs;
 		}
-
+		$failed = false;
 		foreach ($breadCrumbsForOpenFile as $breadCrumb) {
 			$pageObject->openFile($breadCrumb, $this->getSession());
-			$pageObject->waitTillPageIsLoaded($this->getSession());
-		}
-
-		if ($fileOrFolder !== "folder") {
-			// Pop the file name off the end of the array of breadcrumbs
-			\array_pop($breadCrumbs);
+			try {
+				$pageObject->waitTillPageIsLoaded($this->getSession());
+			} catch (\Exception $e) {
+				// The file was not opened correctly as the page didn't load correctly
+				$failed = true;
+				break;
+			}
 		}
+		// Check the status of file opened according to the expected result.
+		if ($failed) {
+			// The task was not expected to fail but failed.
+			if (!$expectToFail) {
+				throw new \Exception('The file was expected to open successfully but failed!');
+			}
+		} else {
+			// The task was expected to fail but didn't fail.
+			if ($expectToFail) {
+				throw new \Exception('The file was not expected to open successfully but was opened!');
+			}
 
-		if (\count($breadCrumbs)) {
-			$this->currentFolder .= "/" . \implode('/', $breadCrumbs);
+			// The task was not expected to fail and was successful.
+			if ($fileOrFolder !== "folder") {
+				// Pop the file name off the end of the array of breadcrumbs
+				\array_pop($breadCrumbs);
+			}
+			if (\count($breadCrumbs)) {
+				$this->currentFolder .= "/" . \implode('/', $breadCrumbs);
+			};
 		}
 	}
 

From 5ba985a10a9250abc7e7bb370ea3219c8b62c849 Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Fri, 17 May 2019 12:40:00 +0545
Subject: [PATCH 027/131] user creation with username containing capital
 letters

---
 .../apiProvisioning-v1/addUser.feature        | 25 +++++++++++++++++++
 .../apiProvisioning-v2/addUser.feature        | 25 +++++++++++++++++++
 2 files changed, 50 insertions(+)

diff --git a/tests/acceptance/features/apiProvisioning-v1/addUser.feature b/tests/acceptance/features/apiProvisioning-v1/addUser.feature
index aa9b4614012e..810ec8a1bf9c 100644
--- a/tests/acceptance/features/apiProvisioning-v1/addUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/addUser.feature
@@ -66,3 +66,28 @@ Feature: add user
     And the HTTP status code should be "200"
     And user "brand-new-user" should exist
     And user "brand-new-user" should be able to access a skeleton file
+
+  Scenario Outline: admin creates a user with username that contains capital letters
+    When the administrator sends a user creation request for user "<display-name>" password "%alt1%" using the provisioning API
+    Then the OCS status code should be "100"
+    And the HTTP status code should be "200"
+    And user "Brand-New-User" should exist
+    And user "BRAND-NEW-USER" should exist
+    And user "brand-new-user" should exist
+    And user "brand-NEW-user" should exist
+    And user "BrAnD-nEw-UsEr" should exist
+    And the display name of user "brand-new-user" should be "<display-name>"
+    Examples:
+      |  display-name   |
+      | Brand-New-User  |
+      | BRAND-NEW-USER  |
+      | brand-new-user  |
+      | brand-NEW-user  |
+      | BrAnD-nEw-UsEr  |
+
+  Scenario: admin tries to create an existing user but with username containing capital letters
+    Given user "brand-new-user" has been created with default attributes
+    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
diff --git a/tests/acceptance/features/apiProvisioning-v2/addUser.feature b/tests/acceptance/features/apiProvisioning-v2/addUser.feature
index 3a9fe6c563b6..3ff1abe60d86 100644
--- a/tests/acceptance/features/apiProvisioning-v2/addUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/addUser.feature
@@ -66,3 +66,28 @@ Feature: add user
     And the HTTP status code should be "200"
     And user "brand-new-user" should exist
     And user "brand-new-user" should be able to access a skeleton file
+
+  Scenario Outline: admin creates a user with username that contains capital letters
+    When the administrator sends a user creation request for user "<display-name>" password "%alt1%" using the provisioning API
+    Then the OCS status code should be "200"
+    And the HTTP status code should be "200"
+    And user "Brand-New-User" should exist
+    And user "BRAND-NEW-USER" should exist
+    And user "brand-new-user" should exist
+    And user "brand-NEW-user" should exist
+    And user "BrAnD-nEw-UsEr" should exist
+    And the display name of user "brand-new-user" should be "<display-name>"
+    Examples:
+      |  display-name   |
+      | Brand-New-User  |
+      | BRAND-NEW-USER  |
+      | brand-new-user  |
+      | brand-NEW-user  |
+      | BrAnD-nEw-UsEr  |
+
+  Scenario: admin tries to create an existing user but with username containing capital letters
+    Given user "brand-new-user" has been created with default attributes
+    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
\ No newline at end of file

From 044770cce17c90fbb289a0b65d712cc0593ae638 Mon Sep 17 00:00:00 2001
From: Saugat Pachhai <suagatchhetri@outlook.com>
Date: Tue, 21 May 2019 14:40:33 +0545
Subject: [PATCH 028/131] Test if robots.txt is accessible or not

---
 tests/acceptance/features/apiMain/main.feature       |  7 +++++++
 .../acceptance/features/bootstrap/BasicStructure.php | 12 ++++++++++++
 2 files changed, 19 insertions(+)
 create mode 100644 tests/acceptance/features/apiMain/main.feature

diff --git a/tests/acceptance/features/apiMain/main.feature b/tests/acceptance/features/apiMain/main.feature
new file mode 100644
index 000000000000..1dce2f4449fe
--- /dev/null
+++ b/tests/acceptance/features/apiMain/main.feature
@@ -0,0 +1,7 @@
+@api
+Feature: Other tests related to api
+
+  Scenario: robots.txt file should be accessible
+    When a user requests "/robots.txt" with "GET" and no authentication
+    Then the HTTP status code should be "200"
+    And the content in the response should match with the content of file "robots.txt" in the server root
\ No newline at end of file
diff --git a/tests/acceptance/features/bootstrap/BasicStructure.php b/tests/acceptance/features/bootstrap/BasicStructure.php
index fe34ab72d098..2c36274b99b4 100644
--- a/tests/acceptance/features/bootstrap/BasicStructure.php
+++ b/tests/acceptance/features/bootstrap/BasicStructure.php
@@ -1724,6 +1724,18 @@ public function theFileWithContentShouldExistInTheServerRoot($path, $content) {
 		);
 	}
 
+	/**
+	 * @Then /^the content in the response should match with the content of file "([^"]*)" in the server root$/
+	 *
+	 * @param string $path
+	 *
+	 * @return void
+	 */
+	public function theContentInTheRespShouldMatchWithFileInTheServerRoot($path) {
+		$content = $this->getResponse()->getBody()->getContents();
+		$this->theFileWithContentShouldExistInTheServerRoot($path, $content);
+	}
+
 	/**
 	 * @Then the file :path should not exist in the server root
 	 *

From ee9d3d4f99bf274ea60ce3c985b0e392584f1638 Mon Sep 17 00:00:00 2001
From: Artur Neumann <artur@jankaritech.com>
Date: Wed, 22 May 2019 16:46:47 +0545
Subject: [PATCH 029/131] skip tests that fail on encryption

---
 .../features/webUISharingInternalGroups/shareWithGroups.feature | 2 ++
 .../features/webUISharingInternalUsers/shareWithUsers.feature   | 1 +
 2 files changed, 3 insertions(+)

diff --git a/tests/acceptance/features/webUISharingInternalGroups/shareWithGroups.feature b/tests/acceptance/features/webUISharingInternalGroups/shareWithGroups.feature
index 016b8b89cbcd..954c3b9db96a 100644
--- a/tests/acceptance/features/webUISharingInternalGroups/shareWithGroups.feature
+++ b/tests/acceptance/features/webUISharingInternalGroups/shareWithGroups.feature
@@ -131,6 +131,7 @@ Feature: Sharing files and folders with internal groups
     Then a tooltip with the text "No users or groups found for system-group" should be shown near the share-with-field on the webUI
     And the autocomplete list should not be displayed on the webUI
 
+  @skipOnEncryptionType:user-keys @issue-encryption-126
   @mailhog
   Scenario: user should be able to send notification by email when allow share mail notification has been enabled
     Given parameter "shareapi_allow_mail_notification" of app "core" has been set to "yes"
@@ -179,6 +180,7 @@ Feature: Sharing files and folders with internal groups
     When the administrator adds user "user0" to group "grp1" using the provisioning API
     Then the email address "user0@example.org" should not have received an email
 
+  @skipOnEncryptionType:user-keys @issue-encryption-126
   @mailhog
   Scenario: user should get an error message when trying to send notification by email to the group where some user have set up their email and others haven't
     Given parameter "shareapi_allow_mail_notification" of app "core" has been set to "yes"
diff --git a/tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature b/tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature
index 453806f52018..be452e56294a 100644
--- a/tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature
+++ b/tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature
@@ -234,6 +234,7 @@ Feature: Sharing files and folders with internal users
     And file "lorem.txt" should not be listed in shared-with-others page on the webUI
     And as "user2" file "lorem (2).txt" should not exist
 
+  @skipOnEncryptionType:user-keys @issue-encryption-126
   @mailhog
   Scenario: user should be able to send notification by email when allow share mail notification has been enabled
     Given parameter "shareapi_allow_mail_notification" of app "core" has been set to "yes"

From 86066adb1e879c2670f674bba3b10c91f05032e6 Mon Sep 17 00:00:00 2001
From: Sujith H <sharidasan@owncloud.com>
Date: Tue, 21 May 2019 12:24:45 +0530
Subject: [PATCH 030/131] [stable10] Backport of Accessing sharetab directly
 for a long list of files

Accessing sharetab directly for a long list of
files caused problems. The pages need to be fetched
appropriately to get the data. This changeset fixes
the problem.

Signed-off-by: Sujith H <sharidasan@owncloud.com>
---
 apps/files/js/filelist.js                            | 12 ++++++++++++
 .../webUIFiles/browseDirectlyToDetailsTab.feature    |  5 +----
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/apps/files/js/filelist.js b/apps/files/js/filelist.js
index f8312fcb569e..e76008dc344b 100644
--- a/apps/files/js/filelist.js
+++ b/apps/files/js/filelist.js
@@ -2533,6 +2533,18 @@
 			}
 			if (!_.isUndefined(detailTabId)) {
 				var filename = file[file.length - 1];
+				//Double check if the area that you are scrolling is beyond the page limit?
+				var pageSize = this.pageSize();
+				var index = _.findIndex(this.files, function (obj) {
+					return obj.name === filename;
+				});
+				if (index >= pageSize) {
+					var numberOfMorePagesToScroll = Math.floor(index / pageSize);
+					while (numberOfMorePagesToScroll > 0) {
+						this._nextPage();
+						numberOfMorePagesToScroll--;
+					}
+				}
 				this.showDetailsView(filename, detailTabId);
 			}
 			this.highlightFiles(file, function($tr) {
diff --git a/tests/acceptance/features/webUIFiles/browseDirectlyToDetailsTab.feature b/tests/acceptance/features/webUIFiles/browseDirectlyToDetailsTab.feature
index 7f0f50a26ce0..5df2a54ad5ca 100644
--- a/tests/acceptance/features/webUIFiles/browseDirectlyToDetailsTab.feature
+++ b/tests/acceptance/features/webUIFiles/browseDirectlyToDetailsTab.feature
@@ -23,12 +23,11 @@ Feature: browse directly to details tab
 
   #merge this tests into previous scenario when bug is fixed
   @smokeTest
-  @issue-35200
   Scenario Outline: Browse directly to the sharing details of a file
     When the user tries to browse directly to display the "sharing" details of file "<file>" in folder "<folder>"
     #Then the thumbnail should be visible in the details panel
     Then the "sharing" details panel should be visible
-    And the share-with field should not be visible in the details panel
+    And the share-with field should be visible in the details panel
     #And the share-with field should be visible in the details panel
     Examples:
       | file                                 | folder        | comment   |
@@ -48,7 +47,6 @@ Feature: browse directly to details tab
       | lorem.txt         | simple-folder | a file somewhere in between |
 
   #merge this tests into previous scenario when bug is fixed
-  @issue-35200
   @comments-app-required
   Scenario Outline: Browse directly to the comments details of a file
     When the user tries to browse directly to display the "comments" details of file "<file>" in folder "<folder>"
@@ -72,7 +70,6 @@ Feature: browse directly to details tab
       | lorem.txt         | simple-folder | a file somewhere in between |
 
   #merge this tests into previous scenario when bug is fixed
-  @issue-35200
   @files_versions-app-required
   Scenario Outline: Browse directly to the versions details of a file
     When the user tries to browse directly to display the "versions" details of file "<file>" in folder "<folder>"

From 7b00d35b015df800c8d049a992ab9f0aa716235c Mon Sep 17 00:00:00 2001
From: paurakhsharma <paurakh011@gmail.com>
Date: Wed, 15 May 2019 13:09:33 +0545
Subject: [PATCH 031/131] Add cli tests for background queue status and delete

---
 .../features/bootstrap/OccContext.php         | 73 +++++++++++++++++++
 .../cliBackground/backgroundQueue.feature     | 30 ++++++++
 2 files changed, 103 insertions(+)
 create mode 100644 tests/acceptance/features/cliBackground/backgroundQueue.feature

diff --git a/tests/acceptance/features/bootstrap/OccContext.php b/tests/acceptance/features/bootstrap/OccContext.php
index 14f3e45150ad..db57ea37a730 100644
--- a/tests/acceptance/features/bootstrap/OccContext.php
+++ b/tests/acceptance/features/bootstrap/OccContext.php
@@ -38,6 +38,11 @@ class OccContext implements Context {
 	 */
 	private $featureContext;
 
+	/**
+	 * @var string lastDeletedJobId
+	 */
+	private $lastDeletedJobId;
+
 	/**
 	 * @When /^the administrator invokes occ command "([^"]*)"$/
 	 * @Given /^the administrator has invoked occ command "([^"]*)"$/
@@ -597,6 +602,52 @@ public function theAdministratorEmptiesTheTrashbinOfAllUsersUsingTheOccCommand()
 		$this->theAdministratorEmptiesTheTrashbinOfUserUsingTheOccCommand('');
 	}
 
+	/**
+	 * @When the administrator gets all the jobs in the background queue using the occ command
+	 *
+	 * @return void
+	 */
+	public function theAdministratorGetsAllTheJobsInTheBackgroundQueueUsingTheOccCommand() {
+		$this->invokingTheCommand(
+			"background:queue:status"
+		);
+	}
+
+	/**
+	 * @When the administrator deletes last background job :job using the occ command
+	 *
+	 * @param string $job
+	 *
+	 * @return void
+	 */
+	public function theAdministratorDeletesLastBackgroundJobUsingTheOccCommand($job) {
+		$match = $this->getLastJobIdForJob($job);
+		if ($match === false) {
+			throw new \Exception("Couldn't find jobId for given job: $job");
+		}
+		$this->invokingTheCommand(
+			"background:queue:delete $match"
+		);
+		$this->lastDeletedJobId = $match;
+	}
+
+	/**
+	 * @Then the last deleted background job :job should not be listed in the background jobs queue
+	 *
+	 * @param string $job
+	 *
+	 * @return void
+	 */
+	public function theLastDeletedJobShouldNotBeListedInTheJobsQueue($job) {
+		$jobId = $this->lastDeletedJobId;
+		$match = $this->getLastJobIdForJob($job);
+		PHPUnit\Framework\Assert::assertNotEquals(
+			$jobId, $match,
+			"job $job with jobId $jobId" .
+			" was not expected to be listed in background queue, but was"
+		);
+	}
+
 	/**
 	 * @Then system config key :key should have value :value
 	 *
@@ -721,6 +772,28 @@ public function theAdministratorHasClearedTheVersionsForAllUsers() {
 		);
 	}
 
+	/**
+	 * get jobId of the latest job found of given job class
+	 *
+	 * @param string $job
+	 *
+	 * @return string|boolean
+	 */
+	public function getLastJobIdForJob($job) {
+		$this->theAdministratorGetsAllTheJobsInTheBackgroundQueueUsingTheOccCommand();
+		$commandOutput = $this->featureContext->getStdOutOfOccCommand();
+		$lines = $this->featureContext->findLines(
+			$commandOutput,
+			$job
+		);
+		// find the jobId of the newest job among the jobs with given class
+		$success = \preg_match("/\d+/", \end($lines), $match);
+		if ($success) {
+			return $match[0];
+		}
+		return false;
+	}
+
 	/**
 	 * This will run before EVERY scenario.
 	 * It will set the properties for this object.
diff --git a/tests/acceptance/features/cliBackground/backgroundQueue.feature b/tests/acceptance/features/cliBackground/backgroundQueue.feature
new file mode 100644
index 000000000000..3ff3e87160b4
--- /dev/null
+++ b/tests/acceptance/features/cliBackground/backgroundQueue.feature
@@ -0,0 +1,30 @@
+@cli @files_trashbin-app-required
+Feature: get status, delete and execute jobs in background queue
+  As an admin
+  I want to be able to see, delete and execute the jobs in background queue
+  So that I have control over background job queue
+
+  Scenario: get the list of jobs in background queue
+    When the administrator gets all the jobs in the background queue using the occ command
+    Then the command should have been successful
+    And the command output table should contain the following text:
+      | table_column                                       |
+      | OCA\Files\BackgroundJob\ScanFiles                  |
+      | OCA\Files\BackgroundJob\DeleteOrphanedItems        |
+      | OCA\Files\BackgroundJob\CleanupFileLocks           |
+      | OCA\Files\BackgroundJob\CleanupPersistentFileLocks |
+      | OCA\DAV\CardDAV\SyncJob                            |
+      | OCA\DAV\BackgroundJob\CleanProperties              |
+      | OCA\Files_Sharing\DeleteOrphanedSharesJob          |
+      | OCA\Files_Sharing\ExpireSharesJob                  |
+      | OCA\Files_Trashbin\BackgroundJob\ExpireTrash       |
+      | OCA\Files_Versions\BackgroundJob\ExpireVersions    |
+      | OCA\UpdateNotification\Notification\BackgroundJob  |
+      | OC\Authentication\Token\DefaultTokenCleanupJob     |
+
+  Scenario: delete one of the job in background queue
+    Given user "user0" has been created with default attributes
+    And user "user0" has deleted file "/textfile0.txt"
+    When the administrator deletes last background job "OC\Command\CommandJob" using the occ command
+    Then the command should have been successful
+    And the last deleted background job "OC\Command\CommandJob" should not be listed in the background jobs queue

From d620fd7c5ae197d689f3ef852239a425307fa220 Mon Sep 17 00:00:00 2001
From: paurakhsharma <paurakh011@gmail.com>
Date: Tue, 21 May 2019 13:33:32 +0545
Subject: [PATCH 032/131] Add cli tests for config.php default values

---
 .../features/bootstrap/OccContext.php         | 49 +++++++++++++++++++
 .../features/cliMain/configKey.feature        | 19 +++++++
 2 files changed, 68 insertions(+)

diff --git a/tests/acceptance/features/bootstrap/OccContext.php b/tests/acceptance/features/bootstrap/OccContext.php
index db57ea37a730..b48f12fc8b45 100644
--- a/tests/acceptance/features/bootstrap/OccContext.php
+++ b/tests/acceptance/features/bootstrap/OccContext.php
@@ -794,6 +794,55 @@ public function getLastJobIdForJob($job) {
 		return false;
 	}
 
+	/**
+	 * @Then the system config key :key from the last command output should match value :value of type :type
+	 *
+	 * @param string $key
+	 * @param string $value
+	 * @param string $type
+	 *
+	 * @return void
+	 */
+	public function theSystemConfigKeyFromLastCommandOutputShouldContainValue(
+		$key, $value, $type
+	) {
+		$configList = \json_decode(
+			$this->featureContext->getStdOutOfOccCommand(), true
+		);
+		$systemConfig = $configList['system'];
+
+		// convert the value to it's respective type based on type given in the type column
+		if ($type === 'boolean') {
+			$value = $value === 'true' ? true : false;
+		} elseif ($type === 'integer') {
+			$value = (int) $value;
+		} elseif ($type === 'json') {
+			// if the expected value of the key is a json
+			// match the value with the regular expression
+			$actualKeyValuePair = \json_encode(
+				$systemConfig[$key], JSON_UNESCAPED_SLASHES
+			);
+
+			PHPUnit\Framework\Assert::assertThat(
+				$actualKeyValuePair,
+				PHPUnit\Framework\Assert::matchesRegularExpression($value)
+			);
+			return;
+		}
+
+		if (!\array_key_exists($key, $systemConfig)) {
+			PHPUnit\Framework\Assert::fail(
+				"system config doesn't contain key: " . $key
+			);
+		}
+
+		PHPUnit\Framework\Assert::assertEquals(
+			$value,
+			$systemConfig[$key],
+			"config: $key doesn't contain value: $value"
+		);
+	}
+
 	/**
 	 * This will run before EVERY scenario.
 	 * It will set the properties for this object.
diff --git a/tests/acceptance/features/cliMain/configKey.feature b/tests/acceptance/features/cliMain/configKey.feature
index 16d1ae08d9be..ffbc8555524b 100644
--- a/tests/acceptance/features/cliMain/configKey.feature
+++ b/tests/acceptance/features/cliMain/configKey.feature
@@ -35,3 +35,22 @@ Feature: add and delete app configs using occ command
     Then the command should have been successful
     And the command output should contain the apps configs
 
+  Scenario: app directory should be listed in the config file
+    When the administrator lists the config keys
+    Then the command should have been successful
+    And the system config key "apps_paths" from the last command output should match value '/\"url\":\"\/apps\",\"writable\":false/' of type "json"
+
+  Scenario: app-external directory should be listed in the config
+    When the administrator lists the config keys
+    Then the command should have been successful
+    And the system config key "apps_paths" from the last command output should match value '/\"url\":\"\/apps-external\",\"writable\":true/' of type "json"
+
+  Scenario: log time zone should be listed in the config file
+    When the administrator lists the config keys
+    Then the command should have been successful
+    And the system config key "logtimezone" from the last command output should match value "UTC" of type "string"
+
+  Scenario: server installed should be listed in the config file
+    When the administrator lists the config keys
+    Then the command should have been successful
+    And the system config key "installed" from the last command output should match value "true" of type "boolean"

From 7efac479b5971afdee583a2f6e12090901200b12 Mon Sep 17 00:00:00 2001
From: bhawana <bhawana.prs@gmail.com>
Date: Thu, 16 May 2019 15:27:36 +0545
Subject: [PATCH 033/131] Acceptance test for group names with emoji

---
 .../features/apiProvisioningGroups-v1/addGroup.feature       | 3 ++-
 .../features/apiProvisioningGroups-v1/addToGroup.feature     | 3 ++-
 .../features/apiProvisioningGroups-v1/deleteGroup.feature    | 5 +++--
 .../apiProvisioningGroups-v1/getSubAdminGroups.feature       | 3 +++
 .../features/apiProvisioningGroups-v1/getUserGroups.feature  | 5 ++++-
 .../apiProvisioningGroups-v1/removeFromGroup.feature         | 1 +
 .../features/apiProvisioningGroups-v2/addGroup.feature       | 1 +
 .../features/apiProvisioningGroups-v2/addToGroup.feature     | 1 +
 .../features/apiProvisioningGroups-v2/deleteGroup.feature    | 1 +
 .../apiProvisioningGroups-v2/getSubAdminGroups.feature       | 3 +++
 .../features/apiProvisioningGroups-v2/getUserGroups.feature  | 3 +++
 .../apiProvisioningGroups-v2/removeFromGroup.feature         | 3 ++-
 12 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature
index b5c73c3596e5..2216c783103f 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature
@@ -17,7 +17,7 @@ Feature: add groups
       | group_id    | comment                     |
       | simplegroup | nothing special here        |
       | España      | special European characters |
-      | नेपाली      | Unicode group name          |
+      | नेपाली        | Unicode group name          |
 
   Scenario Outline: admin creates a group
     When the administrator sends a group creation request for group "<group_id>" using the provisioning API
@@ -42,6 +42,7 @@ Feature: add groups
       | 50%2Eagle           | %2E literal looks like an escaped "."   |
       | 50%2Fix             | %2F literal looks like an escaped slash |
       | staff?group         | Question mark                           |
+      | 😅 😆               | emoji                                   |
 
     # Note: these groups do get created OK, but:
     # 1) the "should exist" step fails because the API to check their existence does not work.
diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature
index e669e18b1a42..b5c77a42e031 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature
@@ -18,7 +18,7 @@ Feature: add users to group
       | group_id    | comment                     |
       | simplegroup | nothing special here        |
       | España      | special European characters |
-      | नेपाली      | Unicode group name          |
+      | नेपाली        | Unicode group name          |
 
   Scenario Outline: adding a user to a group
     Given user "brand-new-user" has been created with default attributes
@@ -44,6 +44,7 @@ Feature: add users to group
       | 50%2Eagle           | %2E literal looks like an escaped "."   |
       | 50%2Fix             | %2F literal looks like an escaped slash |
       | staff?group         | Question mark                           |
+      | 😁 😂               | emoji                                   |
 
   @issue-31015
   Scenario Outline: adding a user to a group that has a forward-slash in the group name
diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/deleteGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/deleteGroup.feature
index 58b76be90b72..c14ce5a84e1a 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v1/deleteGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v1/deleteGroup.feature
@@ -18,7 +18,7 @@ Feature: delete groups
       | group_id    | comment                     |
       | simplegroup | nothing special here        |
       | España      | special European characters |
-      | नेपाली      | Unicode group name          |
+      | नेपाली        | Unicode group name          |
 
   Scenario Outline: admin deletes a group
     Given group "<group_id>" has been created
@@ -44,6 +44,7 @@ Feature: delete groups
       | 50%2Eagle           | %2E literal looks like an escaped "."   |
       | 50%2Fix             | %2F literal looks like an escaped slash |
       | staff?group         | Question mark                           |
+      | 😁 😂               | emoji                                   |
 
   @issue-31015
   Scenario Outline: admin deletes a group that has a forward-slash in the group name
@@ -82,4 +83,4 @@ Feature: delete groups
     When user "subadmin" tries to delete group "new-group" using the provisioning API
     Then the OCS status code should be "997"
     And the HTTP status code should be "401"
-    And group "new-group" should exist
\ No newline at end of file
+    And group "new-group" should exist
diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/getSubAdminGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v1/getSubAdminGroups.feature
index ec3c10572d73..7fc059941f51 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v1/getSubAdminGroups.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v1/getSubAdminGroups.feature
@@ -11,10 +11,13 @@ Feature: get subadmin groups
   Scenario: admin gets subadmin groups of a user
     Given user "brand-new-user" has been created with default attributes
     And group "new-group" has been created
+    And group "😅 😆" has been created
     And user "brand-new-user" has been made a subadmin of group "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 subadmin groups returned by the API should be
       | new-group |
+      | 😅 😆      |
     And the OCS status code should be "100"
     And the HTTP status code should be "200"
 
diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/getUserGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v1/getUserGroups.feature
index 7672d67cb6dc..c819e5d34652 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v1/getUserGroups.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v1/getUserGroups.feature
@@ -16,18 +16,21 @@ Feature: get user groups
     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 "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 groups returned by the API should be
       | new-group            |
       | 0                    |
       | Admin & Finance (NP) |
       | admin:Pokhara@Nepal  |
-      | नेपाली               |
+      | नेपाली                 |
+      | 😅 😆                |
     And the OCS status code should be "100"
     And the HTTP status code should be "200"
 
diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature
index 46e146d8913e..ab4cf1f7cdd4 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature
@@ -48,6 +48,7 @@ Feature: remove a user from a group
       | 50%2Eagle           | %2E literal looks like an escaped "."   |
       | 50%2Fix             | %2F literal looks like an escaped slash |
       | staff?group         | Question mark                           |
+      | 😁 😂               | emoji                                   |
 
   @issue-31015
   Scenario Outline: admin removes a user from a group that has a forward-slash in the group name
diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/addGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/addGroup.feature
index 933f2090e396..1e761afb9e60 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v2/addGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v2/addGroup.feature
@@ -42,6 +42,7 @@ Feature: add groups
       | 50%2Eagle           | %2E literal looks like an escaped "."   |
       | 50%2Fix             | %2F literal looks like an escaped slash |
       | staff?group         | Question mark                           |
+      | 😅 😆               | emoji                                   |
 
     # Note: these groups do get created OK, but:
     # 1) the "should exist" step fails because the API to check their existence does not work.
diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature
index 1ae6b0eab8a2..286e75682354 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature
@@ -44,6 +44,7 @@ Feature: add users to group
       | 50%2Eagle           | %2E literal looks like an escaped "."   |
       | 50%2Fix             | %2F literal looks like an escaped slash |
       | staff?group         | Question mark                           |
+      | 😅 😆               | emoji                                   |
 
   @issue-31015
   Scenario Outline: adding a user to a group that has a forward-slash in the group name
diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/deleteGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/deleteGroup.feature
index 7b4c4dbe317d..9e78caf81312 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v2/deleteGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v2/deleteGroup.feature
@@ -44,6 +44,7 @@ Feature: delete groups
       | 50%2Eagle           | %2E literal looks like an escaped "."   |
       | 50%2Fix             | %2F literal looks like an escaped slash |
       | staff?group         | Question mark                           |
+      | 😅 😆               | emoji                                   |
 
   @issue-31015
   Scenario Outline: admin deletes a group that has a forward-slash in the group name
diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/getSubAdminGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v2/getSubAdminGroups.feature
index 5dfb1563253b..865b2d3a9182 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v2/getSubAdminGroups.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v2/getSubAdminGroups.feature
@@ -11,10 +11,13 @@ Feature: get subadmin groups
   Scenario: admin gets subadmin groups of a user
     Given user "brand-new-user" has been created with default attributes
     And group "new-group" has been created
+    And group "😅 😆" has been created
     And user "brand-new-user" has been made a subadmin of group "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 subadmin groups returned by the API should be
       | new-group |
+      | 😅 😆      |
     And the OCS status code should be "200"
     And the HTTP status code should be "200"
 
diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/getUserGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v2/getUserGroups.feature
index 6bd9bc54328f..bfbd49cf7207 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v2/getUserGroups.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v2/getUserGroups.feature
@@ -16,11 +16,13 @@ Feature: get user groups
     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 "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 groups returned by the API should be
       | new-group            |
@@ -28,6 +30,7 @@ Feature: get user groups
       | Admin & Finance (NP) |
       | admin:Pokhara@Nepal  |
       | नेपाली               |
+      | 😅 😆                |
     And the OCS status code should be "200"
     And the HTTP status code should be "200"
 
diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature
index 63a985d7300a..e15a8242ef23 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature
@@ -22,7 +22,7 @@ Feature: remove a user from a group
       | España      | special European characters |
       | नेपाली      | Unicode group name          |
 
-  Scenario Outline: admin removes a user from a group
+   Scenario Outline: admin removes a user from a group
     Given user "brand-new-user" has been created with default attributes
     And group "<group_id>" has been created
     And user "brand-new-user" has been added to group "<group_id>"
@@ -48,6 +48,7 @@ Feature: remove a user from a group
       | 50%2Eagle           | %2E literal looks like an escaped "."   |
       | 50%2Fix             | %2F literal looks like an escaped slash |
       | staff?group         | Question mark                           |
+      | 😅 😆               | emoji                                   |
 
   @issue-31015
   Scenario Outline: admin removes a user from a group that has a forward-slash in the group name

From 58630d9312ecd2c62176ab7b7283097c696a476b Mon Sep 17 00:00:00 2001
From: bhawana <bhawana.prs@gmail.com>
Date: Mon, 20 May 2019 16:57:22 +0545
Subject: [PATCH 034/131] Acceptance test for giving controlled  access to
 users to change their fullname

---
 .../features/bootstrap/OccContext.php         |  6 +++--
 .../WebUIPersonalGeneralSettingsContext.php   | 17 ++++++++++++++
 ...ccessToChangeFullNameThroughConfig.feature | 23 +++++++++++++++++++
 3 files changed, 44 insertions(+), 2 deletions(-)
 create mode 100644 tests/acceptance/features/webUIPersonalSettings/accessToChangeFullNameThroughConfig.feature

diff --git a/tests/acceptance/features/bootstrap/OccContext.php b/tests/acceptance/features/bootstrap/OccContext.php
index b48f12fc8b45..7987eab2edbd 100644
--- a/tests/acceptance/features/bootstrap/OccContext.php
+++ b/tests/acceptance/features/bootstrap/OccContext.php
@@ -555,15 +555,17 @@ public function theAdministratorDeletesConfigKeyOfAppUsingTheOccCommand($key, $a
 	/**
 	 * @Given the administrator has added system config key :key with value :value
 	 * @When the administrator adds/updates system config key :key with value :value using the occ command
+	 * @When the administrator adds/updates system config key :key with value :value and type :type using the occ command
 	 *
 	 * @param string $key
 	 * @param string $value
+	 * @param boolean $type
 	 *
 	 * @return void
 	 */
-	public function theAdministratorAddsSystemConfigKeyWithValueUsingTheOccCommand($key, $value) {
+	public function theAdministratorAddsSystemConfigKeyWithValueUsingTheOccCommand($key, $value, $type="string") {
 		$this->invokingTheCommand(
-			"config:system:set --value ${value} ${key}"
+			"config:system:set --value ${value} --type ${type} ${key}"
 		);
 	}
 
diff --git a/tests/acceptance/features/bootstrap/WebUIPersonalGeneralSettingsContext.php b/tests/acceptance/features/bootstrap/WebUIPersonalGeneralSettingsContext.php
index e0c593b90cdb..daf23dc045d8 100644
--- a/tests/acceptance/features/bootstrap/WebUIPersonalGeneralSettingsContext.php
+++ b/tests/acceptance/features/bootstrap/WebUIPersonalGeneralSettingsContext.php
@@ -24,6 +24,7 @@
 use Behat\Behat\Hook\Scope\BeforeScenarioScope;
 use Behat\MinkExtension\Context\RawMinkContext;
 use Page\PersonalGeneralSettingsPage;
+use PHPUnit\Framework\Assert;
 use TestHelpers\EmailHelper;
 
 require_once 'bootstrap.php';
@@ -156,6 +157,22 @@ public function theUserChangesTheFullnameToUsingTheWebUI($newFullname) {
 		);
 	}
 
+	/**
+	 * @Then the user should not be able to change the full name using the webUI
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public function theUserShouldNotBeAbleToChangeTheFullNameUsingTheWebui() {
+		try {
+			$this->personalGeneralSettingsPage->changeFullname(
+				"anything", $this->getSession()
+			);
+			PHPUnit\Framework\Assert::fail("changing the full name was possible, but should not");
+		} catch (Behat\Mink\Exception\ElementNotFoundException $e) {
+		}
+	}
+
 	/**
 	 * @When the user changes the email address to :emailAddress using the webUI
 	 * @Given the user has changed the email address to :emailAddress using the webUI
diff --git a/tests/acceptance/features/webUIPersonalSettings/accessToChangeFullNameThroughConfig.feature b/tests/acceptance/features/webUIPersonalSettings/accessToChangeFullNameThroughConfig.feature
new file mode 100644
index 000000000000..4b0fffa502d6
--- /dev/null
+++ b/tests/acceptance/features/webUIPersonalSettings/accessToChangeFullNameThroughConfig.feature
@@ -0,0 +1,23 @@
+@webUI @insulated @disablePreviews
+Feature: Control access to edit fullname of user through config file
+  As an admin
+  I want to control the access to users to edit their fullname in settings page
+  So that users can edit their fullname after getting permission from administrator
+
+  Scenario: Admin gives access to users to change their full name
+    Given user "user1" has been created with default attributes
+    And user "user1" has logged in using the webUI
+    When the administrator updates system config key "allow_user_to_change_display_name" with value "true" and type "boolean" using the occ command
+    And the user browses to the personal general settings page
+    And the user changes the full name to "my#very&weird?नेपालि%name" using the webUI
+    And the user reloads the current page of the webUI
+    Then "my#very&weird?नेपालि%name" should be shown as the name of the current user on the WebUI
+    And the attributes of user "user1" returned by the API should include
+      | displayname | my#very&weird?नेपालि%name |
+
+  Scenario: Admin doesnot give access to users to change their full name
+    Given user "user1" has been created with default attributes
+    And user "user1" has logged in using the webUI
+    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 user browses to the personal general settings page
+    Then the user should not be able to change the full name using the webUI
\ No newline at end of file

From 795a5e48c07983b3f194e84cf0bda680cffc6735 Mon Sep 17 00:00:00 2001
From: Artur Neumann <artur@jankaritech.com>
Date: Mon, 27 May 2019 17:38:27 +0545
Subject: [PATCH 035/131] do not generate token when not needed and do not run
 tests double

---
 .../acceptance/features/apiAuth/cors.feature  |  1 -
 .../features/apiAuthOcs/ocsDELETEAuth.feature |  1 -
 .../features/apiAuthOcs/ocsGETAuth.feature    | 27 +------------------
 .../features/apiAuthOcs/ocsPOSTAuth.feature   |  1 -
 .../features/apiAuthOcs/ocsPUTAuth.feature    |  1 -
 5 files changed, 1 insertion(+), 30 deletions(-)

diff --git a/tests/acceptance/features/apiAuth/cors.feature b/tests/acceptance/features/apiAuth/cors.feature
index 53deb891b738..eb25580f449f 100644
--- a/tests/acceptance/features/apiAuth/cors.feature
+++ b/tests/acceptance/features/apiAuth/cors.feature
@@ -2,7 +2,6 @@
 Feature: CORS headers
   Background:
     Given user "user0" has been created with default attributes
-    And a new client token for "user0" has been generated
 
   Scenario Outline: CORS headers should be returned when setting CORS domain sending Origin header
     Given using OCS API version "<ocs_api_version>"
diff --git a/tests/acceptance/features/apiAuthOcs/ocsDELETEAuth.feature b/tests/acceptance/features/apiAuthOcs/ocsDELETEAuth.feature
index f1feb2eb5f5b..aa3cfe9d793a 100644
--- a/tests/acceptance/features/apiAuthOcs/ocsDELETEAuth.feature
+++ b/tests/acceptance/features/apiAuthOcs/ocsDELETEAuth.feature
@@ -3,7 +3,6 @@ Feature: auth
 
   Background:
     Given user "user0" has been created with default attributes
-    And a new client token for "user0" has been generated
 
   @issue-32068
   Scenario Outline: send DELETE requests to OCS endpoints as admin with wrong password
diff --git a/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature b/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature
index 71d2656b47f8..5ea4181b8131 100644
--- a/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature
+++ b/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature
@@ -2,7 +2,6 @@
 Feature: auth
   Background:
     Given user "user0" has been created with default attributes
-    And a new client token for "user0" has been generated
 
   @issue-32068
   Scenario Outline: using OCS anonymously
@@ -200,6 +199,7 @@ Feature: auth
       | 2               |/cloud/users/user0/subadmins                         | 997      | 401       |
 
   Scenario Outline: using OCS with token auth of a normal user
+    Given a new client token for "user0" has been generated
     When user "user0" requests "<endpoint>" with "GET" using basic token auth
     Then the OCS status code should be "<ocs-code>"
     And the HTTP status code should be "<http-code>"
@@ -224,31 +224,6 @@ Feature: auth
       |/ocs/v1.php/privatedata/getattribute                        | 100      | 200       |
       |/ocs/v2.php/privatedata/getattribute                        | 200      | 200       |
 
-  Scenario Outline: using OCS with client token of a normal user
-    When the user requests "<endpoint>" with "GET" using the generated client token
-    Then the OCS status code should be "<ocs-code>"
-    And the HTTP status code should be "<http-code>"
-    Examples:
-      |endpoint                                                    | ocs-code | http-code |
-      |/ocs/v1.php/apps/files_external/api/v1/mounts               | 100      | 200       |
-      |/ocs/v2.php/apps/files_external/api/v1/mounts               | 200      | 200       |
-      |/ocs/v1.php/apps/files_sharing/api/v1/remote_shares         | 100      | 200       |
-      |/ocs/v2.php/apps/files_sharing/api/v1/remote_shares         | 200      | 200       |
-      |/ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending | 100      | 200       |
-      |/ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending | 200      | 200       |
-      |/ocs/v1.php/apps/files_sharing/api/v1/shares                | 100      | 200       |
-      |/ocs/v2.php/apps/files_sharing/api/v1/shares                | 200      | 200       |
-      |/ocs/v1.php/cloud/apps                                      | 997      | 401       |
-      |/ocs/v2.php/cloud/apps                                      | 997      | 401       |
-      |/ocs/v1.php/cloud/groups                                    | 997      | 401       |
-      |/ocs/v2.php/cloud/groups                                    | 997      | 401       |
-      |/ocs/v1.php/cloud/users                                     | 997      | 401       |
-      |/ocs/v2.php/cloud/users                                     | 997      | 401       |
-      |/ocs/v1.php/config                                          | 100      | 200       |
-      |/ocs/v2.php/config                                          | 200      | 200       |
-      |/ocs/v1.php/privatedata/getattribute                        | 100      | 200       |
-      |/ocs/v2.php/privatedata/getattribute                        | 200      | 200       |
-
   Scenario Outline: using OCS with browser session of a normal user
     Given a new browser session for "user0" has been started
     When the user requests "<endpoint>" with "GET" using the browser session
diff --git a/tests/acceptance/features/apiAuthOcs/ocsPOSTAuth.feature b/tests/acceptance/features/apiAuthOcs/ocsPOSTAuth.feature
index 342533f3c26f..d4b6feef2579 100644
--- a/tests/acceptance/features/apiAuthOcs/ocsPOSTAuth.feature
+++ b/tests/acceptance/features/apiAuthOcs/ocsPOSTAuth.feature
@@ -3,7 +3,6 @@ Feature: auth
 
   Background:
     Given user "user0" has been created with default attributes
-    And a new client token for "user0" has been generated
 
   @issue-32068
   Scenario Outline: send POST requests to OCS endpoints as normal user with wrong password
diff --git a/tests/acceptance/features/apiAuthOcs/ocsPUTAuth.feature b/tests/acceptance/features/apiAuthOcs/ocsPUTAuth.feature
index 38792496717c..567fb8b913e3 100644
--- a/tests/acceptance/features/apiAuthOcs/ocsPUTAuth.feature
+++ b/tests/acceptance/features/apiAuthOcs/ocsPUTAuth.feature
@@ -3,7 +3,6 @@ Feature: auth
 
   Background:
     Given user "user0" has been created with default attributes
-    And a new client token for "user0" has been generated
 
   @issue-32068
   Scenario Outline: send PUT requests to OCS endpoints as admin with wrong password

From 156e158548bc2f4b8bc5a89c41876723ce289f55 Mon Sep 17 00:00:00 2001
From: Artur Neumann <artur@jankaritech.com>
Date: Mon, 27 May 2019 17:40:32 +0545
Subject: [PATCH 036/131] do not create user when not needed

---
 tests/acceptance/features/apiAuthOcs/ocsDELETEAuth.feature | 3 ---
 tests/acceptance/features/apiAuthOcs/ocsPUTAuth.feature    | 3 ---
 2 files changed, 6 deletions(-)

diff --git a/tests/acceptance/features/apiAuthOcs/ocsDELETEAuth.feature b/tests/acceptance/features/apiAuthOcs/ocsDELETEAuth.feature
index aa3cfe9d793a..29bb6d0a0959 100644
--- a/tests/acceptance/features/apiAuthOcs/ocsDELETEAuth.feature
+++ b/tests/acceptance/features/apiAuthOcs/ocsDELETEAuth.feature
@@ -1,9 +1,6 @@
 @api @TestAlsoOnExternalUserBackend
 Feature: auth
 
-  Background:
-    Given user "user0" has been created with default attributes
-
   @issue-32068
   Scenario Outline: send DELETE requests to OCS endpoints as admin with wrong password
     Given using OCS API version "<ocs_api_version>"
diff --git a/tests/acceptance/features/apiAuthOcs/ocsPUTAuth.feature b/tests/acceptance/features/apiAuthOcs/ocsPUTAuth.feature
index 567fb8b913e3..1f2351326cae 100644
--- a/tests/acceptance/features/apiAuthOcs/ocsPUTAuth.feature
+++ b/tests/acceptance/features/apiAuthOcs/ocsPUTAuth.feature
@@ -1,9 +1,6 @@
 @api @TestAlsoOnExternalUserBackend
 Feature: auth
 
-  Background:
-    Given user "user0" has been created with default attributes
-
   @issue-32068
   Scenario Outline: send PUT requests to OCS endpoints as admin with wrong password
     Given using OCS API version "<ocs_api_version>"

From eb42436d0969244a0af6f383042d967ff26b0f23 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Mon, 27 May 2019 14:24:03 +0545
Subject: [PATCH 037/131] API acceptance tests for case sensitive group names

---
 .../apiProvisioningGroups-v1/addGroup.feature | 14 +++++++++++++
 .../deleteGroup.feature                       | 16 +++++++++++++++
 .../apiProvisioningGroups-v1/getGroup.feature | 20 +++++++++++++++++++
 .../apiProvisioningGroups-v2/addGroup.feature | 14 +++++++++++++
 .../deleteGroup.feature                       | 16 +++++++++++++++
 .../apiProvisioningGroups-v2/getGroup.feature | 20 +++++++++++++++++++
 6 files changed, 100 insertions(+)

diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature
index 2216c783103f..30872315b94f 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature
@@ -44,6 +44,20 @@ Feature: add groups
       | staff?group         | Question mark                           |
       | 😅 😆               | emoji                                   |
 
+  Scenario Outline: 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 group "<group_id1>" using the provisioning API
+    And the administrator sends a group creation request for group "<group_id2>" using the provisioning API
+    Then the OCS status code should be "100"
+    And the HTTP status code should be "200"
+    And group "<group_id1>" should exist
+    And group "<group_id2>" should exist
+    But group "<group_id3>" should not 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 |
+
     # 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
diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/deleteGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/deleteGroup.feature
index c14ce5a84e1a..762c88abb8fd 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v1/deleteGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v1/deleteGroup.feature
@@ -46,6 +46,22 @@ Feature: delete groups
       | staff?group         | Question mark                           |
       | 😁 😂               | emoji                                   |
 
+  Scenario Outline: group names are case-sensitive, the correct group is deleted
+    Given group "<group_id1>" has been created
+    And group "<group_id2>" has been created
+    And group "<group_id3>" has been created
+    When the administrator deletes group "<group_id1>" using the provisioning API
+    Then the OCS status code should be "100"
+    And the HTTP status code should be "200"
+    And group "<group_id1>" should not exist
+    But group "<group_id2>" should exist
+    And group "<group_id3>" should exist
+    Examples:
+      | group_id1            | group_id2            | group_id3 |
+      | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP |
+      | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group |
+      | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group |
+
   @issue-31015
   Scenario Outline: 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"
diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/getGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/getGroup.feature
index 9287067a38ff..838f61b891a7 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v1/getGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v1/getGroup.feature
@@ -28,6 +28,26 @@ Feature: get group
     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 non-existent group
+    Given group "new-group" has been created
+    When the administrator gets all the members of group "not-a-group" using the provisioning API
+    Then the OCS status code should be "998"
+    And the HTTP status code should be "200"
+
+  Scenario Outline: admin tries to get users in a group but using wrong case of the group name
+    Given group "<group_id1>" has been created
+    When the administrator gets all the members of group "<group_id2>" using the provisioning API
+    Then the OCS status code should be "998"
+    And the HTTP status code should be "200"
+    Examples:
+      | group_id1            | group_id2            |
+      | case-sensitive-group | Case-Sensitive-Group |
+      | case-sensitive-group | CASE-SENSITIVE-GROUP |
+      | Case-Sensitive-Group | case-sensitive-group |
+      | Case-Sensitive-Group | CASE-SENSITIVE-GROUP |
+      | CASE-SENSITIVE-GROUP | Case-Sensitive-Group |
+      | CASE-SENSITIVE-GROUP | case-sensitive-group |
+
   @smokeTest
   Scenario: subadmin gets users in a group they are responsible for
     Given user "user1" has been created with default attributes
diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/addGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/addGroup.feature
index 1e761afb9e60..f5b69933cf70 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v2/addGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v2/addGroup.feature
@@ -44,6 +44,20 @@ Feature: add groups
       | staff?group         | Question mark                           |
       | 😅 😆               | emoji                                   |
 
+  Scenario Outline: 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 group "<group_id1>" using the provisioning API
+    And the administrator sends a group creation request for group "<group_id2>" using the provisioning API
+    Then the OCS status code should be "200"
+    And the HTTP status code should be "200"
+    And group "<group_id1>" should exist
+    And group "<group_id2>" should exist
+    But group "<group_id3>" should not 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 |
+
     # 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
diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/deleteGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/deleteGroup.feature
index 9e78caf81312..b3cf27c0aa6c 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v2/deleteGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v2/deleteGroup.feature
@@ -46,6 +46,22 @@ Feature: delete groups
       | staff?group         | Question mark                           |
       | 😅 😆               | emoji                                   |
 
+  Scenario Outline: group names are case-sensitive, the correct group is deleted
+    Given group "<group_id1>" has been created
+    And group "<group_id2>" has been created
+    And group "<group_id3>" has been created
+    When the administrator deletes group "<group_id1>" using the provisioning API
+    Then the OCS status code should be "200"
+    And the HTTP status code should be "200"
+    And group "<group_id1>" should not exist
+    But group "<group_id2>" should exist
+    And group "<group_id3>" should exist
+    Examples:
+      | group_id1            | group_id2            | group_id3 |
+      | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP |
+      | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group |
+      | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group |
+
   @issue-31015
   Scenario Outline: 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"
diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/getGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/getGroup.feature
index 69a3515e689f..9b2a13fa0300 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v2/getGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v2/getGroup.feature
@@ -28,6 +28,26 @@ Feature: get group
     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 non-existent group
+    Given group "new-group" has been created
+    When the administrator gets all the members of group "not-a-group" using the provisioning API
+    Then the OCS status code should be "404"
+    And the HTTP status code should be "404"
+
+  Scenario Outline: admin tries to get users in a group but using wrong case of the group name
+    Given group "<group_id1>" has been created
+    When the administrator gets all the members of group "<group_id2>" using the provisioning API
+    Then the OCS status code should be "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
   Scenario: subadmin gets users in a group they are responsible for
     Given user "user1" has been created with default attributes

From de92607aac8c8c8fbb2b3a8908c18b2bd5a65471 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Mon, 27 May 2019 14:41:41 +0545
Subject: [PATCH 038/131] CLI acceptance tests for case sensitive group names

---
 .../features/cliProvisioning/addGroup.feature | 13 +++++++++++
 .../cliProvisioning/deleteGroup.feature       | 18 ++++++++++++++-
 .../features/cliProvisioning/getGroup.feature | 22 ++++++++++++++++++-
 3 files changed, 51 insertions(+), 2 deletions(-)

diff --git a/tests/acceptance/features/cliProvisioning/addGroup.feature b/tests/acceptance/features/cliProvisioning/addGroup.feature
index c8ff7d4c5589..6b96557fe14e 100644
--- a/tests/acceptance/features/cliProvisioning/addGroup.feature
+++ b/tests/acceptance/features/cliProvisioning/addGroup.feature
@@ -15,6 +15,19 @@ Feature: add group
       | España      | special European characters |
       | नेपाली      | Unicode group name          |
 
+  Scenario Outline: group names are case-sensitive, multiple groups can exist with different upper and lower case names
+    When the administrator creates group "<group_id1>" using the occ command
+    And the administrator creates group "<group_id2>" using the occ command
+    Then the command should have been successful
+    And group "<group_id1>" should exist
+    And group "<group_id2>" should exist
+    But group "<group_id3>" should not 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 |
+
   Scenario: admin tries to create a group that already exists
     Given group "new-group" has been created
     When the administrator creates group "new-group" using the occ command
diff --git a/tests/acceptance/features/cliProvisioning/deleteGroup.feature b/tests/acceptance/features/cliProvisioning/deleteGroup.feature
index a218579ec1e5..9dd162bb1eeb 100644
--- a/tests/acceptance/features/cliProvisioning/deleteGroup.feature
+++ b/tests/acceptance/features/cliProvisioning/deleteGroup.feature
@@ -14,4 +14,20 @@ Feature: delete groups
       | group_id    | comment                     |
       | simplegroup | nothing special here        |
       | España      | special European characters |
-      | नेपाली      | Unicode group name          |
\ No newline at end of file
+      | नेपाली      | Unicode group name          |
+
+  Scenario Outline: group names are case-sensitive, the correct group is deleted
+    Given group "<group_id1>" has been created
+    And group "<group_id2>" has been created
+    And group "<group_id3>" has been created
+    When the administrator deletes group "<group_id1>" using the occ command
+    Then the command should have been successful
+    And the command output should contain the text 'The specified group was deleted'
+    And group "<group_id1>" should not exist
+    But group "<group_id2>" should exist
+    And group "<group_id3>" should exist
+    Examples:
+      | group_id1            | group_id2            | group_id3 |
+      | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP |
+      | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group |
+      | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group |
diff --git a/tests/acceptance/features/cliProvisioning/getGroup.feature b/tests/acceptance/features/cliProvisioning/getGroup.feature
index 23a25d952a71..f265d54bfdde 100644
--- a/tests/acceptance/features/cliProvisioning/getGroup.feature
+++ b/tests/acceptance/features/cliProvisioning/getGroup.feature
@@ -30,4 +30,24 @@ Feature: get group
     Then the command should have been successful
     And the users returned by the occ command should be
       | uid            | display name |
-      | brand-new-user | Anne Brown   |
\ No newline at end of file
+      | brand-new-user | Anne Brown   |
+
+  Scenario: admin tries to get users in a non-existent group
+    Given group "new-group" has been created
+    When the administrator gets the users in group "not-a-group" in JSON format using the occ command
+    Then the command should have failed with exit code 1
+    And the command output should contain the text 'Group not-a-group does not exist'
+
+  Scenario Outline: admin tries to get users in a group but using wrong case of the group name
+    Given group "<group_id1>" has been created
+    When the administrator gets the users in group "<group_id2>" in JSON format using the occ command
+    Then the command should have failed with exit code 1
+    And the command output should contain the text 'Group <group_id2> does not exist'
+    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 |

From 0b8af3d7cd5f36cb5ca99b64abda91ea2c7e7edd Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Mon, 27 May 2019 15:07:22 +0545
Subject: [PATCH 039/131] API acceptance tests to add and remove users in
 groups using mixed case user and group names

---
 .../addToGroup.feature                        | 17 ++++++++++++++++
 .../removeFromGroup.feature                   | 20 +++++++++++++++++++
 .../addToGroup.feature                        | 17 ++++++++++++++++
 .../removeFromGroup.feature                   | 20 +++++++++++++++++++
 4 files changed, 74 insertions(+)

diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature
index b5c77a42e031..b733eb202344 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature
@@ -65,6 +65,23 @@ Feature: add users to group
       | var/../etc       | using slash-dot-dot                |
       | priv/subadmins/1 | Subadmins mentioned not at the end |
 
+  Scenario Outline: adding a user to 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 group "<group_id1>" has been created
+    And group "<group_id2>" has been created
+    And group "<group_id3>" has been created
+    When the administrator adds user "<user_id>" to group "<group_id1>" using the provisioning API
+    Then the OCS status code should be "100"
+    And the HTTP status code should be "200"
+    And user "brand-new-user" should belong to group "<group_id1>"
+    But user "brand-new-user" should not belong to group "<group_id2>"
+    And user "brand-new-user" should not belong to group "<group_id3>"
+    Examples:
+      | user_id        | group_id1 | group_id2 | group_id3 |
+      | BRAND-NEW-USER | New-Group | new-group | NEW-GROUP |
+      | Brand-New-User | new-group | NEW-GROUP | New-Group |
+      | brand-new-user | NEW-GROUP | New-Group | new-group |
+
   Scenario: normal user tries to add himself to a group
     Given user "brand-new-user" has been created with default attributes
     When user "brand-new-user" tries to add himself to group "new-group" using the provisioning API
diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature
index ab4cf1f7cdd4..63812f0709f6 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature
@@ -71,6 +71,26 @@ Feature: remove a user from a group
       | var/../etc       | using slash-dot-dot                |
       | priv/subadmins/1 | Subadmins mentioned not at the end |
 
+  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 group "<group_id1>" has been created
+    And group "<group_id2>" has been created
+    And group "<group_id3>" has been created
+    And user "brand-new-user" has been added to group "<group_id1>"
+    And user "brand-new-user" has been added to group "<group_id2>"
+    And user "brand-new-user" has been added to group "<group_id3>"
+    When the administrator removes user "<user_id>" from group "<group_id1>" using the provisioning API
+    Then the OCS status code should be "100"
+    And the HTTP status code should be "200"
+    And user "brand-new-user" should not belong to group "<group_id1>"
+    But user "brand-new-user" should belong to group "<group_id2>"
+    And user "brand-new-user" should belong to group "<group_id3>"
+    Examples:
+      | user_id        | group_id1 | group_id2 | group_id3 |
+      | BRAND-NEW-USER | New-Group | new-group | NEW-GROUP |
+      | Brand-New-User | new-group | NEW-GROUP | New-Group |
+      | brand-new-user | NEW-GROUP | New-Group | new-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 group "not-group" has been deleted
diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature
index 286e75682354..d93e9e415b4e 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature
@@ -65,6 +65,23 @@ Feature: add users to group
       | var/../etc       | using slash-dot-dot                |
       | priv/subadmins/1 | Subadmins mentioned not at the end |
 
+  Scenario Outline: adding a user to 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 group "<group_id1>" has been created
+    And group "<group_id2>" has been created
+    And group "<group_id3>" has been created
+    When the administrator adds user "<user_id>" to group "<group_id1>" 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 "<group_id1>"
+    But user "brand-new-user" should not belong to group "<group_id2>"
+    And user "brand-new-user" should not belong to group "<group_id3>"
+    Examples:
+      | user_id        | group_id1 | group_id2 | group_id3 |
+      | BRAND-NEW-USER | New-Group | new-group | NEW-GROUP |
+      | Brand-New-User | new-group | NEW-GROUP | New-Group |
+      | brand-new-user | NEW-GROUP | New-Group | new-group |
+
   @issue-31276
   Scenario: normal user tries to add himself to a group
     Given user "brand-new-user" has been created with default attributes
diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature
index e15a8242ef23..972ef0399471 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature
@@ -71,6 +71,26 @@ Feature: remove a user from a group
       | var/../etc       | using slash-dot-dot                |
       | priv/subadmins/1 | Subadmins mentioned not at the end |
 
+  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 group "<group_id1>" has been created
+    And group "<group_id2>" has been created
+    And group "<group_id3>" has been created
+    And user "brand-new-user" has been added to group "<group_id1>"
+    And user "brand-new-user" has been added to group "<group_id2>"
+    And user "brand-new-user" has been added to group "<group_id3>"
+    When the administrator removes user "<user_id>" from group "<group_id1>" using the provisioning API
+    Then the OCS status code should be "200"
+    And the HTTP status code should be "200"
+    And user "brand-new-user" should not belong to group "<group_id1>"
+    But user "brand-new-user" should belong to group "<group_id2>"
+    And user "brand-new-user" should belong to group "<group_id3>"
+    Examples:
+      | user_id        | group_id1 | group_id2 | group_id3 |
+      | BRAND-NEW-USER | New-Group | new-group | NEW-GROUP |
+      | Brand-New-User | new-group | NEW-GROUP | New-Group |
+      | brand-new-user | NEW-GROUP | New-Group | new-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 group "not-group" has been deleted

From c9223b21d1fa90826c26884a70671bc3421524e1 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Mon, 27 May 2019 16:30:04 +0545
Subject: [PATCH 040/131] CLI acceptance tests to add and remove users in
 groups using mixed case user and group names

---
 .../cliProvisioning/addToGroup.feature        | 17 ++++++++++++++++
 .../cliProvisioning/removeFromGroup.feature   | 20 +++++++++++++++++++
 2 files changed, 37 insertions(+)

diff --git a/tests/acceptance/features/cliProvisioning/addToGroup.feature b/tests/acceptance/features/cliProvisioning/addToGroup.feature
index 063f20a384ec..bd3ddf5a8e12 100644
--- a/tests/acceptance/features/cliProvisioning/addToGroup.feature
+++ b/tests/acceptance/features/cliProvisioning/addToGroup.feature
@@ -18,6 +18,23 @@ Feature: add users to group
       | España      | special European characters |
       | नेपाली      | Unicode group name          |
 
+  Scenario Outline: adding a user to 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 group "<group_id1>" has been created
+    And group "<group_id2>" has been created
+    And group "<group_id3>" has been created
+    When the administrator adds user "<user_id>" to group "<group_id1>" using the occ command
+    Then the command should have been successful
+    And the command output should contain the text 'User "brand-new-user" added to group "<group_id1>"'
+    And user "brand-new-user" should belong to group "<group_id1>"
+    But user "brand-new-user" should not belong to group "<group_id2>"
+    And user "brand-new-user" should not belong to group "<group_id3>"
+    Examples:
+      | user_id        | group_id1 | group_id2 | group_id3 |
+      | BRAND-NEW-USER | New-Group | new-group | NEW-GROUP |
+      | Brand-New-User | new-group | NEW-GROUP | New-Group |
+      | brand-new-user | NEW-GROUP | New-Group | new-group |
+
   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 group "not-group" has been deleted
diff --git a/tests/acceptance/features/cliProvisioning/removeFromGroup.feature b/tests/acceptance/features/cliProvisioning/removeFromGroup.feature
index 058886eb7cb1..47d115273cac 100644
--- a/tests/acceptance/features/cliProvisioning/removeFromGroup.feature
+++ b/tests/acceptance/features/cliProvisioning/removeFromGroup.feature
@@ -18,6 +18,26 @@ Feature: remove a user from a group
       | España      | special European characters |
       | नेपाली      | Unicode group name          |
 
+  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 group "<group_id1>" has been created
+    And group "<group_id2>" has been created
+    And group "<group_id3>" has been created
+    And user "brand-new-user" has been added to group "<group_id1>"
+    And user "brand-new-user" has been added to group "<group_id2>"
+    And user "brand-new-user" has been added to group "<group_id3>"
+    When the administrator removes user "<user_id>" from group "<group_id1>" using the occ command
+    Then the command should have been successful
+    And the command output should contain the text 'Member "brand-new-user" removed from group "<group_id1>"'
+    And user "brand-new-user" should not belong to group "<group_id1>"
+    But user "brand-new-user" should belong to group "<group_id2>"
+    And user "brand-new-user" should belong to group "<group_id3>"
+    Examples:
+      | user_id        | group_id1 | group_id2 | group_id3 |
+      | BRAND-NEW-USER | New-Group | new-group | NEW-GROUP |
+      | Brand-New-User | new-group | NEW-GROUP | New-Group |
+      | brand-new-user | NEW-GROUP | New-Group | new-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 group "not-group" has been deleted

From 29a48c2d4c64ae63231498dfb5afb286dbc18fd1 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Mon, 27 May 2019 16:36:16 +0545
Subject: [PATCH 041/131] API acceptance tests for listing groups with
 different case in the name

---
 .../apiProvisioningGroups-v1/getGroups.feature        | 11 +++++++++++
 .../apiProvisioningGroups-v2/getGroups.feature        | 11 +++++++++++
 2 files changed, 22 insertions(+)

diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/getGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v1/getGroups.feature
index f459f7b7f64e..8b6ede4dde0f 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v1/getGroups.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v1/getGroups.feature
@@ -18,3 +18,14 @@ Feature: get groups
       | admin     |
       | new-group |
       | 0         |
+
+  Scenario: admin gets all the groups, including groups with mixed case
+    Given group "new-group" has been created
+    And group "New-Group" has been created
+    And group "NEW-GROUP" has been created
+    When the administrator gets all the groups using the provisioning API
+    Then the groups returned by the API should be
+      | admin     |
+      | new-group |
+      | New-Group |
+      | NEW-GROUP |
diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/getGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v2/getGroups.feature
index 3c3d67f52828..dfc3226a3421 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v2/getGroups.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v2/getGroups.feature
@@ -18,3 +18,14 @@ Feature: get groups
       | admin     |
       | new-group |
       | 0         |
+
+  Scenario: admin gets all the groups, including groups with mixed case
+    Given group "new-group" has been created
+    And group "New-Group" has been created
+    And group "NEW-GROUP" has been created
+    When the administrator gets all the groups using the provisioning API
+    Then the groups returned by the API should be
+      | admin     |
+      | new-group |
+      | New-Group |
+      | NEW-GROUP |

From fc345763b7b89eae4b081929b9aacae0c0a139b4 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Mon, 27 May 2019 16:41:27 +0545
Subject: [PATCH 042/131] CLI acceptance tests for listing groups with
 different case in the name

---
 .../features/cliProvisioning/getGroups.feature      | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/tests/acceptance/features/cliProvisioning/getGroups.feature b/tests/acceptance/features/cliProvisioning/getGroups.feature
index 4b2713930fe8..c1d685186be3 100644
--- a/tests/acceptance/features/cliProvisioning/getGroups.feature
+++ b/tests/acceptance/features/cliProvisioning/getGroups.feature
@@ -16,3 +16,16 @@ Feature: get groups
       | admin     |
       | new-group |
       | 0         |
+
+  Scenario: admin gets all the groups, including groups with mixed case
+    Given group "new-group" has been created
+    And group "New-Group" has been created
+    And group "NEW-GROUP" has been created
+    When the administrator gets the groups in JSON format using the occ command
+    Then the command should have been successful
+    And the groups returned by the occ command should be
+      | group     |
+      | admin     |
+      | new-group |
+      | New-Group |
+      | NEW-GROUP |

From fba56b3b3b12733b50c79e7a94fde9cd6650e2e2 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Tue, 28 May 2019 09:11:23 +0545
Subject: [PATCH 043/131] API tests to delete a user using mixed case for the
 username

---
 .../features/apiProvisioning-v1/deleteUser.feature         | 7 +++++++
 .../features/apiProvisioning-v2/deleteUser.feature         | 7 +++++++
 2 files changed, 14 insertions(+)

diff --git a/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature b/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature
index 1a4b2d4b15a0..b092939ab953 100644
--- a/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature
@@ -15,6 +15,13 @@ Feature: delete users
     And the HTTP status code should be "200"
     And user "brand-new-user" should not exist
 
+  Scenario: Delete a user, and specify the user name in different case
+    Given user "brand-new-user" has been created with default attributes
+    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
   Scenario: subadmin deletes a user in their group
     Given user "subadmin" has been created with default attributes
diff --git a/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature b/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature
index 45d80b1eda01..7123410daf8f 100644
--- a/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature
@@ -15,6 +15,13 @@ Feature: delete users
     And the HTTP status code should be "200"
     And user "brand-new-user" should not exist
 
+  Scenario: Delete a user, and specify the user name in different case
+    Given user "brand-new-user" has been created with default attributes
+    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
   Scenario: subadmin deletes a user in their group
     Given user "subadmin" has been created with default attributes

From 0a261901f50c2a9c9ddb7a91c0c3b1419fb3d830 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Tue, 28 May 2019 09:12:11 +0545
Subject: [PATCH 044/131] Remember normalized lowercase username in acceptance
 tests

---
 .../features/bootstrap/BasicStructure.php     |  3 ++
 .../features/bootstrap/Provisioning.php       | 30 ++++++++++++++++---
 2 files changed, 29 insertions(+), 4 deletions(-)

diff --git a/tests/acceptance/features/bootstrap/BasicStructure.php b/tests/acceptance/features/bootstrap/BasicStructure.php
index 2c36274b99b4..ccb92d485e8e 100644
--- a/tests/acceptance/features/bootstrap/BasicStructure.php
+++ b/tests/acceptance/features/bootstrap/BasicStructure.php
@@ -1331,6 +1331,7 @@ public function rememberNewAdminPassword($password) {
 	 */
 	public function getPasswordForUser($userName) {
 		$userName = $this->getActualUsername($userName);
+		$userName = $this->normalizeUsername($userName);
 		if ($userName === $this->getAdminUsername()) {
 			return (string) $this->getAdminPassword();
 		} elseif (\array_key_exists($userName, $this->createdUsers)) {
@@ -1377,6 +1378,7 @@ public function getDisplayNameForUser($userName) {
 		// The hard-coded user names and display names are also in ldap-users.ldif
 		// for testing in an LDAP environment. The mapping must be kept the
 		// same in both places.
+		$userName = $this->normalizeUsername($userName);
 		if (\array_key_exists($userName, $this->createdUsers)) {
 			return (string) $this->createdUsers[$userName]['displayname'];
 		} elseif (\array_key_exists($userName, $this->createdRemoteUsers)) {
@@ -1419,6 +1421,7 @@ public function getEmailAddressForUser($userName) {
 		// The hard-coded user names and email addresses are also in ldap-users.ldif
 		// for testing in an LDAP environment. The mapping must be kept the
 		// same in both places.
+		$userName = $this->normalizeUsername($userName);
 		if (\array_key_exists($userName, $this->createdUsers)) {
 			return (string) $this->createdUsers[$userName]['email'];
 		} elseif (\array_key_exists($userName, $this->createdRemoteUsers)) {
diff --git a/tests/acceptance/features/bootstrap/Provisioning.php b/tests/acceptance/features/bootstrap/Provisioning.php
index a685f0acb5f0..741952ece072 100644
--- a/tests/acceptance/features/bootstrap/Provisioning.php
+++ b/tests/acceptance/features/bootstrap/Provisioning.php
@@ -34,14 +34,17 @@
 trait Provisioning {
 
 	/**
-	 * list of users that were created during test runs
-	 * key is the username value is an array of user attributes
+	 * list of users that were created on the local server during test runs
+	 * key is the lowercase username, value is an array of user attributes
 	 *
 	 * @var array
 	 */
 	private $createdUsers = [];
 
 	/**
+	 * list of users that were created on the remote server during test runs
+	 * key is the lowercase username, value is an array of user attributes
+	 *
 	 * @var array
 	 */
 	private $createdRemoteUsers = [];
@@ -66,6 +69,19 @@ trait Provisioning {
 	 */
 	private $createdGroups = [];
 
+	/**
+	 * Usernames are not case-sensitive, and can generally be specified with any
+	 * mix of upper and lower case. For remembering usernames use the normalized
+	 * form so that "User0" and "user0" are remembered as the same user.
+	 *
+	 * @param string $username
+	 *
+	 * @return string
+	 */
+	public function normalizeUsername($username) {
+		return \strtolower($username);
+	}
+
 	/**
 	 * @return array
 	 */
@@ -99,8 +115,9 @@ public function getCurrentUserDisplayName() {
 	 * @return string
 	 */
 	public function getUserDisplayName($username) {
-		if (isset($this->createdUsers[$username]['displayname'])) {
-			$displayName = (string) $this->createdUsers[$username]['displayname'];
+		$user = $this->normalizeUsername($username);
+		if (isset($this->createdUsers[$user]['displayname'])) {
+			$displayName = (string) $this->createdUsers[$user]['displayname'];
 			if ($displayName !== '') {
 				return $displayName;
 			}
@@ -130,6 +147,7 @@ public function getCreatedUserDisplayNames() {
 	 * @throws \Exception
 	 */
 	public function getUserPassword($username) {
+		$username = $this->normalizeUsername($username);
 		if ($username === $this->getAdminUsername()) {
 			$password = $this->getAdminPassword();
 		} elseif (\array_key_exists($username, $this->createdUsers)) {
@@ -154,6 +172,7 @@ public function getUserPassword($username) {
 	 * @throws \Exception
 	 */
 	public function theUserShouldExist($username) {
+		$username = $this->normalizeUsername($username);
 		if (\array_key_exists($username, $this->createdUsers)) {
 			return $this->createdUsers[$username]['shouldExist'];
 		}
@@ -1132,6 +1151,7 @@ public function initializeUser($user, $password) {
 	public function addUserToCreatedUsersList(
 		$user, $password, $displayName = null, $email = null, $shouldExist = true
 	) {
+		$user = $this->normalizeUsername($user);
 		$userData = [
 			"password" => $password,
 			"displayname" => $displayName,
@@ -1158,6 +1178,7 @@ public function addUserToCreatedUsersList(
 	public function rememberUserPassword(
 		$user, $password
 	) {
+		$user = $this->normalizeUsername($user);
 		if ($this->currentServer === 'LOCAL') {
 			if (\array_key_exists($user, $this->createdUsers)) {
 				$this->createdUsers[$user]['password'] = $password;
@@ -1180,6 +1201,7 @@ public function rememberUserPassword(
 	 * @return void
 	 */
 	public function rememberThatUserIsNotExpectedToExist($user) {
+		$user = $this->normalizeUsername($user);
 		if (\array_key_exists($user, $this->createdUsers)) {
 			$this->createdUsers[$user]['shouldExist'] = false;
 		}

From 04ad35a5db2a398a797a89b89c23a4f97a3e69df Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Tue, 28 May 2019 09:30:32 +0545
Subject: [PATCH 045/131] CLI tests to add and delete a user using mixed case
 for the username

---
 .../features/cliProvisioning/addUser.feature  | 19 +++++++++++++++++++
 .../cliProvisioning/deleteUser.feature        |  9 +++++++++
 2 files changed, 28 insertions(+)

diff --git a/tests/acceptance/features/cliProvisioning/addUser.feature b/tests/acceptance/features/cliProvisioning/addUser.feature
index 261932c97596..f84578a35fc1 100644
--- a/tests/acceptance/features/cliProvisioning/addUser.feature
+++ b/tests/acceptance/features/cliProvisioning/addUser.feature
@@ -69,3 +69,22 @@ Feature: add a user using the using the occ command
     When the administrator creates user "brand-new-user" password " " group "brand-new-group" using the occ command
     Then the command should have failed with exit code 1
     And user "brand-new-user" should not exist
+
+  Scenario: admin creates a user with username that contains capital letters
+    When the administrator creates this user using the occ command:
+      | username       |
+      | Brand-New-User |
+    Then the command should have been successful
+    And the command output should contain the text 'The user "Brand-New-User" was created successfully'
+    And user "Brand-New-User" should exist
+    And user "brand-new-user" should exist
+    And user "Brand-New-User" should be able to access a skeleton file
+    And the display name of user "brand-new-user" should be "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
+    When the administrator creates this user using the occ command:
+      | username       |
+      | Brand-New-User |
+    Then the command should have failed with exit code 1
+    And the command output should contain the text 'The user "Brand-New-User" already exists'
diff --git a/tests/acceptance/features/cliProvisioning/deleteUser.feature b/tests/acceptance/features/cliProvisioning/deleteUser.feature
index b3519702ca90..b9a8ec5bc3de 100644
--- a/tests/acceptance/features/cliProvisioning/deleteUser.feature
+++ b/tests/acceptance/features/cliProvisioning/deleteUser.feature
@@ -13,6 +13,15 @@ Feature: delete users
     And the command output should contain the text "User with uid 'brand-new-user', display name 'brand-new-user', email '' was deleted"
     And user "brand-new-user" should not exist
 
+  Scenario: Delete a user, and specify the user name in different case
+    Given these users have been created:
+      | username       |
+      | brand-new-user |
+    When the administrator deletes user "Brand-New-User" using the occ command
+    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: admin tries to delete a non-existing user
     Given user "brand-new-user" has been deleted
     When the administrator deletes user "brand-new-user" using the occ command

From af4d267ad49716b6d289cd037ed40a012327345a Mon Sep 17 00:00:00 2001
From: Artur Neumann <artur@jankaritech.com>
Date: Wed, 29 May 2019 09:23:54 +0545
Subject: [PATCH 046/131] merge tests into Scenario Outline that were fixed by
 #35283

---
 .../browseDirectlyToDetailsTab.feature        | 71 ++++++-------------
 1 file changed, 21 insertions(+), 50 deletions(-)

diff --git a/tests/acceptance/features/webUIFiles/browseDirectlyToDetailsTab.feature b/tests/acceptance/features/webUIFiles/browseDirectlyToDetailsTab.feature
index 5df2a54ad5ca..2a44593c1142 100644
--- a/tests/acceptance/features/webUIFiles/browseDirectlyToDetailsTab.feature
+++ b/tests/acceptance/features/webUIFiles/browseDirectlyToDetailsTab.feature
@@ -15,24 +15,13 @@ Feature: browse directly to details tab
     And the "sharing" details panel should be visible
     And the share-with field should be visible in the details panel
     Examples:
-      | file              | folder        | comment                     |
-      | block-aligned.txt | /             | one of the first files      |
-      | block-aligned.txt | simple-folder | one of the first files      |
-      | lorem.txt         | /             | a file somewhere in between |
-      | lorem.txt         | simple-folder | a file somewhere in between |
-
-  #merge this tests into previous scenario when bug is fixed
-  @smokeTest
-  Scenario Outline: Browse directly to the sharing details of a file
-    When the user tries to browse directly to display the "sharing" details of file "<file>" in folder "<folder>"
-    #Then the thumbnail should be visible in the details panel
-    Then the "sharing" details panel should be visible
-    And the share-with field should be visible in the details panel
-    #And the share-with field should be visible in the details panel
-    Examples:
-      | file                                 | folder        | comment   |
-      | zzzz-must-be-last-file-in-folder.txt | /             | last file |
-      | zzzz-must-be-last-file-in-folder.txt | simple-folder | last file |
+      | file                                 | folder        | comment                     |
+      | block-aligned.txt                    | /             | one of the first files      |
+      | block-aligned.txt                    | simple-folder | one of the first files      |
+      | lorem.txt                            | /             | a file somewhere in between |
+      | lorem.txt                            | simple-folder | a file somewhere in between |
+      | zzzz-must-be-last-file-in-folder.txt | /             | last file                   |
+      | zzzz-must-be-last-file-in-folder.txt | simple-folder | last file                   |
 
   @comments-app-required
   Scenario Outline: Browse directly to the comments details of a file
@@ -40,22 +29,13 @@ Feature: browse directly to details tab
     Then the thumbnail should be visible in the details panel
     And the "comments" details panel should be visible
     Examples:
-      | file              | folder        | comment                     |
-      | block-aligned.txt | /             | one of the first files      |
-      | block-aligned.txt | simple-folder | one of the first files      |
-      | lorem.txt         | /             | a file somewhere in between |
-      | lorem.txt         | simple-folder | a file somewhere in between |
-
-  #merge this tests into previous scenario when bug is fixed
-  @comments-app-required
-  Scenario Outline: Browse directly to the comments details of a file
-    When the user tries to browse directly to display the "comments" details of file "<file>" in folder "<folder>"
-    #Then the thumbnail should be visible in the details panel
-    Then the "comments" details panel should be visible
-    Examples:
-      | file                                 | folder        | comment   |
-      | zzzz-must-be-last-file-in-folder.txt | /             | last file |
-      | zzzz-must-be-last-file-in-folder.txt | simple-folder | last file |
+      | file                                 | folder        | comment                     |
+      | block-aligned.txt                    | /             | one of the first files      |
+      | block-aligned.txt                    | simple-folder | one of the first files      |
+      | lorem.txt                            | /             | a file somewhere in between |
+      | lorem.txt                            | simple-folder | a file somewhere in between |
+      | zzzz-must-be-last-file-in-folder.txt | /             | last file                   |
+      | zzzz-must-be-last-file-in-folder.txt | simple-folder | last file                   |
 
   @files_versions-app-required
   Scenario Outline: Browse directly to the versions details of a file
@@ -63,19 +43,10 @@ Feature: browse directly to details tab
     Then the thumbnail should be visible in the details panel
     And the "versions" details panel should be visible
     Examples:
-      | file              | folder        | comment                     |
-      | block-aligned.txt | /             | one of the first files      |
-      | block-aligned.txt | simple-folder | one of the first files      |
-      | lorem.txt         | /             | a file somewhere in between |
-      | lorem.txt         | simple-folder | a file somewhere in between |
-
-  #merge this tests into previous scenario when bug is fixed
-  @files_versions-app-required
-  Scenario Outline: Browse directly to the versions details of a file
-    When the user tries to browse directly to display the "versions" details of file "<file>" in folder "<folder>"
-    #Then the thumbnail should be visible in the details panel
-    Then the "versions" details panel should be visible
-    Examples:
-      | file                                 | folder        | comment   |
-      | zzzz-must-be-last-file-in-folder.txt | /             | last file |
-      | zzzz-must-be-last-file-in-folder.txt | simple-folder | last file |
\ No newline at end of file
+      | file                                 | folder        | comment                     |
+      | block-aligned.txt                    | /             | one of the first files      |
+      | block-aligned.txt                    | simple-folder | one of the first files      |
+      | lorem.txt                            | /             | a file somewhere in between |
+      | lorem.txt                            | simple-folder | a file somewhere in between |
+      | zzzz-must-be-last-file-in-folder.txt | /             | last file                   |
+      | zzzz-must-be-last-file-in-folder.txt | simple-folder | last file                   |

From b5af117c087b1914e17d24517c91dab8062fb9cd Mon Sep 17 00:00:00 2001
From: Artur Neumann <artur@jankaritech.com>
Date: Tue, 21 May 2019 13:58:00 +0545
Subject: [PATCH 047/131] cli test for polling incomming shares

Co-authored-by: Dipak Acharya <dipak@jankaritech.com>
---
 tests/acceptance/config/behat.yml             |  2 +
 .../cliMain/cliIncomingShares.feature         | 66 +++++++++++++++++++
 2 files changed, 68 insertions(+)
 create mode 100644 tests/acceptance/features/cliMain/cliIncomingShares.feature

diff --git a/tests/acceptance/config/behat.yml b/tests/acceptance/config/behat.yml
index c172c89f012d..88a01ea4fbb5 100644
--- a/tests/acceptance/config/behat.yml
+++ b/tests/acceptance/config/behat.yml
@@ -234,6 +234,8 @@ default:
         - FeatureContext: *common_feature_context_params
         - OccContext:
         - TransferOwnershipContext:
+        - FederationContext:
+        - WebDavPropertiesContext:
 
     cliProvisioning:
       paths:
diff --git a/tests/acceptance/features/cliMain/cliIncomingShares.feature b/tests/acceptance/features/cliMain/cliIncomingShares.feature
new file mode 100644
index 000000000000..60823ead83c5
--- /dev/null
+++ b/tests/acceptance/features/cliMain/cliIncomingShares.feature
@@ -0,0 +1,66 @@
+@cli @TestAlsoOnExternalUserBackend
+
+Feature: poll incoming shares
+  As an administrator of a ownCloud Server
+  I want to be able to poll incoming shares manually
+  So that I can make sure all shares are up-to-date
+
+  Scenario: poll incoming share with a federation share of deep nested folders when there is a file change in remote end
+    Given using server "REMOTE"
+    And user "user0" has been created with default attributes
+    And user "user0" has created folder "/really/"
+    And user "user0" has created folder "/really/very/"
+    And user "user0" has created folder "/really/very/deeply/"
+    And user "user0" has created folder "/really/very/deeply/nested/"
+    And user "user0" has created folder "/really/very/deeply/nested/folder/"
+    And user "user0" has created folder "/really/very/deeply/nested/folder/with/"
+    And user "user0" has created folder "/really/very/deeply/nested/folder/with/sub/"
+    And user "user0" has created folder "/really/very/deeply/nested/folder/with/sub/folders"
+    And using server "LOCAL"
+    And user "user1" has been created with default attributes
+    And user "user1" has stored etag of element "/"
+    And user "user0" from server "REMOTE" has shared "/really" with user "user1" from server "LOCAL"
+    And user "user1" from server "LOCAL" has accepted the last pending share
+    When user "user0" on "REMOTE" uploads file "filesForUpload/lorem.txt" to "/really/very/deeply/nested/folder/with/sub/folders/lorem.txt" using the WebDAV API
+    And using server "LOCAL"
+    Then the etag of element "/" of user "user1" should not have changed
+    When the administrator invokes occ command "incoming-shares:poll"
+    Then the etag of element "/" of user "user1" should have changed
+
+  Scenario: poll incoming share with a federation share and no file change
+    Given using server "REMOTE"
+    And user "user0" has been created with default attributes
+    And user "user0" has created folder "/shareFolder/"
+    And using server "LOCAL"
+    And user "user1" has been created with default attributes
+    And user "user1" has stored etag of element "/"
+    And user "user0" from server "REMOTE" has shared "/shareFolder" with user "user1" from server "LOCAL"
+    And user "user1" from server "LOCAL" has accepted the last pending share
+    And using server "LOCAL"
+    Then the etag of element "/" of user "user1" should not have changed
+    When the administrator invokes occ command "incoming-shares:poll"
+    Then the etag of element "/" of user "user1" should have changed
+
+  Scenario: poll incoming share multiple times
+    Given using server "REMOTE"
+    And user "user0" has been created with default attributes
+    And user "user0" has created folder "/shareFolder/"
+    And using server "LOCAL"
+    And user "user1" has stored etag of element "/"
+    And user "user1" has been created with default attributes
+    And user "user0" from server "REMOTE" has shared "/shareFolder" with user "user1" from server "LOCAL"
+    And user "user1" from server "LOCAL" has accepted the last pending share
+    And using server "LOCAL"
+    And the administrator has invoked occ command "incoming-shares:poll"
+    Then the etag of element "/" of user "user1" should have changed
+    When user "user1" stores etag of element "/" using the WebDAV API
+    And the administrator invokes occ command "incoming-shares:poll"
+    Then the etag of element "/" of user "user1" should not have changed
+    When the administrator invokes occ command "incoming-shares:poll"
+    Then the etag of element "/" of user "user1" should not have changed
+
+  Scenario: poll incoming share when there is no share
+    Given user "user1" has been created with default attributes
+    And user "user1" has stored etag of element "/"
+    When the administrator invokes occ command "incoming-shares:poll"
+    Then the etag of element "/" of user "user1" should not have changed
\ No newline at end of file

From 1389e49d51450eddb3e7b68cab237dd11cf310e6 Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Thu, 23 May 2019 11:49:55 +0545
Subject: [PATCH 048/131] api test for sharing with user by entering username
 in capital letters

---
 .../createShare.feature                       | 30 ++++++++++++++++++-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/tests/acceptance/features/apiShareManagementBasic/createShare.feature b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
index 5d1ed2bbf5b1..4ea11243b324 100644
--- a/tests/acceptance/features/apiShareManagementBasic/createShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
@@ -587,4 +587,32 @@ Feature: sharing
     Examples:
       | ocs_api_version | ocs_status_code |
       | 1               | 100             |
-      | 2               | 200             |
\ No newline at end of file
+      | 2               | 200             |
+
+  Scenario: share with user when username contains capital letters
+    Given these users have been created:
+      | username |
+      | user1    |
+    When user "user0" shares file "/welcome.txt" with user "USER1" 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 should include
+      | share_with  |  user1       |
+      | file_target | /welcome.txt |
+      | path        | /welcome.txt |
+      | permissions | 19           |
+      | uid_owner   | user0        |
+    And user "user1" should see the following elements
+      | /welcome.txt |
+
+  Scenario: creating a new share with user of a group when username contains capital letters
+    Given these users have been created:
+      | username |
+      | user1    |
+    And group "grp1" has been created
+    And user "USER1" has been added to group "grp1"
+    And user "user0" has shared file "welcome.txt" with group "grp1"
+    Then the OCS status code should be "100"
+    And the HTTP status code should be "200"
+    And user "user1" should see the following elements
+      | /welcome.txt |

From d8aa953149bbc9d347ff710b5a1cff4e52b0f80c Mon Sep 17 00:00:00 2001
From: paurakhsharma <paurakh011@gmail.com>
Date: Wed, 29 May 2019 13:16:07 +0545
Subject: [PATCH 049/131] move user creation without skeleton from activity app

---
 .../features/bootstrap/Provisioning.php       | 21 ++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/tests/acceptance/features/bootstrap/Provisioning.php b/tests/acceptance/features/bootstrap/Provisioning.php
index 741952ece072..084b907a5080 100644
--- a/tests/acceptance/features/bootstrap/Provisioning.php
+++ b/tests/acceptance/features/bootstrap/Provisioning.php
@@ -271,6 +271,21 @@ public function userHasBeenCreatedWithDefaultAttributes($user) {
 		}
 	}
 
+	/**
+	 * @Given /^user "([^"]*)" has been created with default attributes and without skeleton files$/
+	 *
+	 * @param string $user
+	 *
+	 * @return void
+	 */
+	public function userHasBeenCreatedWithDefaultAttributesAndWithoutSkeletonFiles($user) {
+		$this->featureContext->runOcc(["config:system:get skeletondirectory"]);
+		$path = \trim($this->featureContext->getStdOutOfOccCommand());
+		$this->featureContext->runOcc(["config:system:delete skeletondirectory"]);
+		$this->featureContext->userHasBeenCreatedWithDefaultAttributes($user);
+		$this->featureContext->runOcc(["config:system:set skeletondirectory --value $path"]);
+	}
+
 	/**
 	 * @Given /^these users have been created\s?(with default attributes|)\s?(but not initialized|):$/
 	 * expects a table of users with the heading
@@ -2069,7 +2084,7 @@ public function theAdministratorGetsAllTheGroupsWhereUserIsSubadminUsingTheProvi
 			$fullUrl, $this->getAdminUsername(), $this->getAdminPassword()
 		);
 	}
-	
+
 	/**
 	 * @Given /^user "([^"]*)" has been made a subadmin of group "([^"]*)"$/
 	 *
@@ -2790,7 +2805,7 @@ public function cleanupGroups() {
 		}
 		$this->usingServer($previousServer);
 	}
-	
+
 	/**
 	 * @BeforeScenario
 	 *
@@ -2800,7 +2815,7 @@ public function rememberAppEnabledDisabledState() {
 		$this->enabledApps = $this->getEnabledApps();
 		$this->disabledApps = $this->getDisabledApps();
 	}
-	
+
 	/**
 	 * @AfterScenario
 	 *

From fad7a9147dc2ea529a075154f3bd95205df781f4 Mon Sep 17 00:00:00 2001
From: paurakhsharma <paurakh011@gmail.com>
Date: Wed, 29 May 2019 13:45:19 +0545
Subject: [PATCH 050/131] Add error handling on user creation

---
 tests/acceptance/features/bootstrap/Provisioning.php | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tests/acceptance/features/bootstrap/Provisioning.php b/tests/acceptance/features/bootstrap/Provisioning.php
index 084b907a5080..6f6d2964c579 100644
--- a/tests/acceptance/features/bootstrap/Provisioning.php
+++ b/tests/acceptance/features/bootstrap/Provisioning.php
@@ -282,8 +282,12 @@ public function userHasBeenCreatedWithDefaultAttributesAndWithoutSkeletonFiles($
 		$this->featureContext->runOcc(["config:system:get skeletondirectory"]);
 		$path = \trim($this->featureContext->getStdOutOfOccCommand());
 		$this->featureContext->runOcc(["config:system:delete skeletondirectory"]);
-		$this->featureContext->userHasBeenCreatedWithDefaultAttributes($user);
-		$this->featureContext->runOcc(["config:system:set skeletondirectory --value $path"]);
+		try {
+			$this->featureContext->userHasBeenCreatedWithDefaultAttributes($user);
+		} finally {
+			// restore skeletondirectory even if user creation failed
+			$this->featureContext->runOcc(["config:system:set skeletondirectory --value $path"]);
+		}
 	}
 
 	/**

From 59d231f3e67f60dc19f4a0c503c4cf951c190b4f Mon Sep 17 00:00:00 2001
From: Dipak Acharya <dpakach@gmail.com>
Date: Wed, 29 May 2019 14:33:34 +0545
Subject: [PATCH 051/131] Remove unnecessary create users from background in
 feature files for webUI tests

---
 .../webUICreateDelete/deleteFilesFolders.feature       |  2 +-
 .../acceptance/features/webUIFiles/fileDetails.feature |  7 ++++---
 tests/acceptance/features/webUIFiles/search.feature    |  4 +++-
 tests/acceptance/features/webUIFiles/versions.feature  | 10 ++++++----
 .../webUIRestrictSharing/restrictReSharing.feature     |  1 -
 .../webUISharingAcceptShares/acceptShares.feature      |  4 +++-
 tests/acceptance/features/webUITags/createTags.feature |  2 +-
 tests/acceptance/features/webUITags/deleteTags.feature |  2 +-
 tests/acceptance/features/webUITags/removeTags.feature |  1 -
 9 files changed, 19 insertions(+), 14 deletions(-)

diff --git a/tests/acceptance/features/webUICreateDelete/deleteFilesFolders.feature b/tests/acceptance/features/webUICreateDelete/deleteFilesFolders.feature
index 015dadf6e15c..144effee3893 100644
--- a/tests/acceptance/features/webUICreateDelete/deleteFilesFolders.feature
+++ b/tests/acceptance/features/webUICreateDelete/deleteFilesFolders.feature
@@ -8,7 +8,6 @@ Feature: deleting files and folders
     Given these users have been created with default attributes:
       | username |
       | user1    |
-      | user2    |
     And user "user1" has logged in using the webUI
     And the user has browsed to the files page
 
@@ -118,6 +117,7 @@ Feature: deleting files and folders
     And file "zzzz-must-be-last-file-in-folder.txt" should not be listed on the webUI
 
   Scenario: delete files from shared with others page
+    Given user "user2" has been created with default attributes
     Given the user has shared file "lorem.txt" with user "User Two" using the webUI
     And the user has shared folder "simple-folder" with user "User Two" using the webUI
     And the user has browsed to the shared-with-others page
diff --git a/tests/acceptance/features/webUIFiles/fileDetails.feature b/tests/acceptance/features/webUIFiles/fileDetails.feature
index a3d1602e65ea..4d8d0f35e42a 100644
--- a/tests/acceptance/features/webUIFiles/fileDetails.feature
+++ b/tests/acceptance/features/webUIFiles/fileDetails.feature
@@ -8,7 +8,6 @@ Feature: User can open the details panel for any file or folder
     Given these users have been created with default attributes:
       | username |
       | user1    |
-      | user2    |
     And user "user1" has logged in using the webUI
     And the user has browsed to the files page
 
@@ -56,7 +55,8 @@ Feature: User can open the details panel for any file or folder
 
   @comments-app-required
   Scenario: user shares a file and then the details dialog should work in a Shared with others page
-    Given the user has shared folder "simple-folder" with user "User Two" using the webUI
+    Given user "user2" has been created with default attributes
+    And the user has shared folder "simple-folder" with user "User Two" using the webUI
     When the user browses to the shared-with-others page
     Then folder "simple-folder" should be listed on the webUI
     When the user opens the file action menu of folder "simple-folder" in the webUI
@@ -70,7 +70,8 @@ Feature: User can open the details panel for any file or folder
 
   @comments-app-required
   Scenario: the recipient user should be able to view different areas of details panel in Shared with you page
-    Given the user has shared folder "simple-folder" with user "User Two" using the webUI
+    Given user "user2" has been created with default attributes
+    And the user has shared folder "simple-folder" with user "User Two" using the webUI
     And the user re-logs in as "user2" using the webUI
     When the user browses to the shared-with-you page
     Then folder "simple-folder (2)" should be listed on the webUI
diff --git a/tests/acceptance/features/webUIFiles/search.feature b/tests/acceptance/features/webUIFiles/search.feature
index 70420bf902cf..b44a972d0657 100644
--- a/tests/acceptance/features/webUIFiles/search.feature
+++ b/tests/acceptance/features/webUIFiles/search.feature
@@ -7,7 +7,6 @@ Feature: Search
 
   Background:
     Given user "user1" has been created with default attributes
-    And user "user0" has been created with default attributes
     And user "user1" has logged in using the webUI
     And the user has browsed to the files page
 
@@ -78,6 +77,7 @@ Feature: Search
     And file "lorem.txt" with path "/simple-folder" should be listed in the tags page on the webUI
 
   Scenario: Search for a shared file
+    Given user "user0" has been created with default attributes
     When user "user0" shares file "/lorem.txt" with user "user1" using the sharing API
     And the user reloads the current page of the webUI
     And the user searches for "lorem" using the webUI
@@ -85,6 +85,7 @@ Feature: Search
 
   Scenario: Search for a re-shared file
     Given user "user2" has been created with default attributes
+    And user "user0" has been created with default attributes
     When user "user2" shares file "/lorem.txt" with user "user0" using the sharing API
     And user "user0" shares file "/lorem (2).txt" with user "user1" using the sharing API
     And the user reloads the current page of the webUI
@@ -92,6 +93,7 @@ Feature: Search
     Then file "lorem (2).txt" should be listed on the webUI
 
   Scenario: Search for a shared folder
+    Given user "user0" has been created with default attributes
     When user "user0" shares folder "simple-folder" with user "user1" using the sharing API
     And the user reloads the current page of the webUI
     And the user searches for "simple" using the webUI
diff --git a/tests/acceptance/features/webUIFiles/versions.feature b/tests/acceptance/features/webUIFiles/versions.feature
index e07f66aa2d40..1c4b93642bb7 100644
--- a/tests/acceptance/features/webUIFiles/versions.feature
+++ b/tests/acceptance/features/webUIFiles/versions.feature
@@ -10,7 +10,6 @@ Feature: Versions of a file
     Given these users have been created with default attributes:
       | username |
       | user0    |
-      | user1    |
 
   @skipOnStorage:ceph @files_primary_s3-issue-67
   Scenario: upload new file with same name to see if different versions are shown
@@ -32,7 +31,8 @@ Feature: Versions of a file
     Then the content of file "lorem-file.txt" for user "user0" should be "lorem content"
 
   Scenario: sharee can see the versions of a file
-    Given user "user0" has uploaded file with content "lorem content" to "/lorem-file.txt"
+    Given user "user1" has been created with default attributes
+    And user "user0" has uploaded file with content "lorem content" to "/lorem-file.txt"
     And user "user0" has uploaded file with content "lorem" to "/lorem-file.txt"
     And user "user0" has uploaded file with content "new lorem content" to "/lorem-file.txt"
     And user "user0" has shared file "lorem-file.txt" with user "user1"
@@ -55,7 +55,8 @@ Feature: Versions of a file
 
   @skipOnStorage:ceph @files_primary_s3-issue-155
   Scenario: file versions cannot be seen in the webUI only for user whose versions is deleted
-    Given user "user0" has uploaded file with content "lorem content" to "/lorem-file.txt"
+    Given user "user1" has been created with default attributes
+    And user "user0" has uploaded file with content "lorem content" to "/lorem-file.txt"
     And user "user0" has uploaded file with content "lorem" to "/lorem-file.txt"
     And user "user1" has uploaded file with content "lorem content" to "/lorem-file.txt"
     And user "user1" has uploaded file with content "lorem" to "/lorem-file.txt"
@@ -72,7 +73,8 @@ Feature: Versions of a file
 
   @skipOnStorage:ceph @files_primary_s3-issue-155
   Scenario: file versions cannot be seen in the webUI for all users after deleting versions for all users
-    Given user "user0" has uploaded file with content "lorem content" to "/lorem-file.txt"
+    Given user "user1" has been created with default attributes
+    And user "user0" has uploaded file with content "lorem content" to "/lorem-file.txt"
     And user "user0" has uploaded file with content "lorem" to "/lorem-file.txt"
     And user "user1" has uploaded file with content "lorem content" to "/lorem-file.txt"
     And user "user1" has uploaded file with content "lorem" to "/lorem-file.txt"
diff --git a/tests/acceptance/features/webUIRestrictSharing/restrictReSharing.feature b/tests/acceptance/features/webUIRestrictSharing/restrictReSharing.feature
index 2b1a58951e7e..040c60f8630d 100644
--- a/tests/acceptance/features/webUIRestrictSharing/restrictReSharing.feature
+++ b/tests/acceptance/features/webUIRestrictSharing/restrictReSharing.feature
@@ -10,7 +10,6 @@ Feature: restrict resharing
       | username |
       | user1    |
       | user2    |
-      | user3    |
     And these groups have been created:
       | groupname |
       | grp1      |
diff --git a/tests/acceptance/features/webUISharingAcceptShares/acceptShares.feature b/tests/acceptance/features/webUISharingAcceptShares/acceptShares.feature
index 964dd8ddcecc..8aa19eff1144 100644
--- a/tests/acceptance/features/webUISharingAcceptShares/acceptShares.feature
+++ b/tests/acceptance/features/webUISharingAcceptShares/acceptShares.feature
@@ -9,7 +9,6 @@ Feature: accept/decline shares coming from internal users
       | username |
       | user1    |
       | user2    |
-      | user3    |
     And these groups have been created:
       | groupname |
       | grp1      |
@@ -31,6 +30,7 @@ Feature: accept/decline shares coming from internal users
 
   Scenario: receive shares with same name from different users
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been disabled
+    And user "user3" has been created with default attributes
     And user "user2" has shared folder "/simple-folder" with user "user3"
     And user "user1" has shared folder "/simple-folder" with user "user3"
     When user "user3" logs in using the webUI
@@ -39,6 +39,7 @@ Feature: accept/decline shares coming from internal users
 
   Scenario: receive shares with same name from different users, accept one by one
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been disabled
+    And user "user3" has been created with default attributes
     And user "user2" has created folder "/simple-folder/from_user2"
     And user "user2" has shared folder "/simple-folder" with user "user3"
     And user "user1" has created folder "/simple-folder/from_user1"
@@ -54,6 +55,7 @@ Feature: accept/decline shares coming from internal users
 
   Scenario: receive shares with same name from different users
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been disabled
+    And user "user3" has been created with default attributes
     And user "user2" has shared folder "/simple-folder" with user "user3"
     And user "user1" has shared folder "/simple-folder" with user "user3"
     When user "user3" logs in using the webUI
diff --git a/tests/acceptance/features/webUITags/createTags.feature b/tests/acceptance/features/webUITags/createTags.feature
index 1b8fef9664d6..6add25f01558 100644
--- a/tests/acceptance/features/webUITags/createTags.feature
+++ b/tests/acceptance/features/webUITags/createTags.feature
@@ -8,7 +8,6 @@ Feature: Creation of tags for the files and folders
     Given these users have been created with default attributes:
       | username |
       | user1    |
-      | user2    |
     And the user has browsed to the login page
     And the user has logged in with username "user1" and password "%alt1%" using the webUI
 
@@ -40,6 +39,7 @@ Feature: Creation of tags for the files and folders
 
   @skipOnFIREFOX
   Scenario: Create and add tag on a shared file
+    Given user "user2" has been created with default attributes
     When the user renames file "lorem.txt" to "coolnewfile.txt" using the webUI
     And the user browses directly to display the details of file "coolnewfile.txt" in folder ""
     And the user adds a tag "tag1" to the file using the webUI
diff --git a/tests/acceptance/features/webUITags/deleteTags.feature b/tests/acceptance/features/webUITags/deleteTags.feature
index a4cba9c9de06..8255c805927f 100644
--- a/tests/acceptance/features/webUITags/deleteTags.feature
+++ b/tests/acceptance/features/webUITags/deleteTags.feature
@@ -8,12 +8,12 @@ Feature: Deletion of existing tags from files and folders
     Given these users have been created with default attributes:
       | username |
       | user1    |
-      | user2    |
     And the user has browsed to the login page
     And the user has logged in with username "user1" and password "%alt1%" using the webUI
 
 @skipOnFIREFOX
   Scenario: Delete a tag in a shared file
+    Given user "user2" has been created with default attributes
     When the user renames file "lorem.txt" to "coolnewfile.txt" using the webUI
     And the user browses directly to display the details of file "coolnewfile.txt" in folder ""
     And the user adds a tag "tag1" to the file using the webUI
diff --git a/tests/acceptance/features/webUITags/removeTags.feature b/tests/acceptance/features/webUITags/removeTags.feature
index 230c7a91ae74..4260633a6156 100644
--- a/tests/acceptance/features/webUITags/removeTags.feature
+++ b/tests/acceptance/features/webUITags/removeTags.feature
@@ -8,7 +8,6 @@ Feature: Removal of already existing tags from files and folders
     Given these users have been created with default attributes:
       | username |
       | user1    |
-      | user2    |
     And the user has browsed to the login page
     And the user has logged in with username "user1" and password "%alt1%" using the webUI
 

From 48aa635eccdd634b30bae07d00fa6d50c5b630a0 Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Wed, 8 May 2019 13:23:50 +0545
Subject: [PATCH 052/131] feature test for public link share expiration date
 deletion

---
 .../updateShare.feature                       |  2 +-
 .../acceptance/features/bootstrap/Sharing.php |  9 ++---
 .../bootstrap/WebUISharingContext.php         | 21 +++++++++++-
 .../EditPublicLinkPopup.php                   | 22 +++++++++++-
 .../SharingDialogElement/PublicLinkTab.php    |  1 +
 .../shareByPublicLink.feature                 | 34 +++++++++++++++++--
 6 files changed, 79 insertions(+), 10 deletions(-)

diff --git a/tests/acceptance/features/apiShareManagementBasic/updateShare.feature b/tests/acceptance/features/apiShareManagementBasic/updateShare.feature
index c37597cf0ea7..d6bf0b022542 100644
--- a/tests/acceptance/features/apiShareManagementBasic/updateShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/updateShare.feature
@@ -35,7 +35,7 @@ Feature: sharing
     And the user gets the info of the last share using the sharing API
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
-    And the fields of the last response should include
+    And the fields of the last share response should include
       | id                | A_NUMBER             |
       | item_type         | folder               |
       | item_source       | A_NUMBER             |
diff --git a/tests/acceptance/features/bootstrap/Sharing.php b/tests/acceptance/features/bootstrap/Sharing.php
index 7a7e77a0d5a4..2673c0b2a481 100644
--- a/tests/acceptance/features/bootstrap/Sharing.php
+++ b/tests/acceptance/features/bootstrap/Sharing.php
@@ -110,7 +110,7 @@ private function waitToCreateShare() {
 	 *       | password        | The password to protect the public link share with. |
 	 *       | expireDate      | An expire date for public link shares.              |
 	 *       |                 | This argument expects a date string.                |
-	 *       |                 | in the format 'YYYY-MM-DD'.                         |
+	 *       |                 | in the format 'YYYY-MM-DD' or '+ x days'.            |
 	 *       | permissions     | The permissions to set on the share.                |
 	 *       |                 |     1 = read; 2 = update; 4 = create;               |
 	 *       |                 |     8 = delete; 16 = share; 31 = all                |
@@ -647,7 +647,8 @@ public function isFieldInResponse($field, $contentExpected, $data = null) {
 		if ($data === null) {
 			$data = $this->getResponseXml()->data[0];
 		}
-		if ((string) $field === 'expiration') {
+		//do not try to convert empty date
+		if ((string) $field === 'expiration' && !empty($contentExpected)) {
 			$contentExpected
 				= \date(
 					'Y-m-d',
@@ -673,7 +674,6 @@ public function isFieldInResponse($field, $contentExpected, $data = null) {
 					print($element->$field);
 				}
 			}
-
 			return false;
 		} else {
 			if ($contentExpected == "A_TOKEN") {
@@ -1299,6 +1299,7 @@ public function checkingTheResponseEntriesCount($count) {
 	}
 
 	/**
+
 	 * @Then the fields of the last response should include
 	 *
 	 * @param TableNode|null $body
@@ -1311,7 +1312,7 @@ public function checkFields($body) {
 
 			foreach ($fd as $field => $value) {
 				$value = $this->replaceValuesFromTable($field, $value);
-				if (!$this->isFieldInResponse($field, $value)) {
+				if (!$this->isFieldInShareResponse($field, $value)) {
 					PHPUnit\Framework\Assert::fail(
 						"$field doesn't have value $value"
 					);
diff --git a/tests/acceptance/features/bootstrap/WebUISharingContext.php b/tests/acceptance/features/bootstrap/WebUISharingContext.php
index b23731cada47..96eedde593a9 100644
--- a/tests/acceptance/features/bootstrap/WebUISharingContext.php
+++ b/tests/acceptance/features/bootstrap/WebUISharingContext.php
@@ -352,7 +352,14 @@ public function theUserChangeTheExpirationOfThePublicLinkNamedForTo($linkName, $
 		$session = $this->getSession();
 		$this->theUserOpensTheShareDialogForFileFolder($name);
 		$this->theUserHasOpenedThePublicLinkShareTab();
-		$this->publicShareTab->editLink($session, $linkName, null, null, null, $date);
+		$this->publicSharingPopup = $this->publicShareTab->editLink(
+			$session,
+			$linkName,
+			null,
+			null,
+			null,
+			$date
+		);
 		$this->publicShareTab->waitForAjaxCallsToStartAndFinish($session);
 	}
 
@@ -479,6 +486,18 @@ public function theUserShouldSeeAnErrorMessageOnThePublicLinkShareDialogSaying(
 		PHPUnit\Framework\Assert::assertEquals($expectedWarningMessage, $warningMessage);
 	}
 
+	/**
+	 * @Then the user should see an error message on the public link popup saying :message
+	 *
+	 * @param string $message
+	 *
+	 * @return void
+	 */
+	public function theUserShouldSeeAnErrorMessageOnThPublicLinkPopupSaying($message) {
+		$errormessage = $this->publicSharingPopup->getErrorMessage();
+		PHPUnit\Framework\Assert::assertEquals($message, $errormessage);
+	}
+
 	/**
 	 * @Then the public link should not have been generated
 	 *
diff --git a/tests/acceptance/features/lib/FilesPageElement/SharingDialogElement/EditPublicLinkPopup.php b/tests/acceptance/features/lib/FilesPageElement/SharingDialogElement/EditPublicLinkPopup.php
index 4cf0a29a6020..dabdfb04f5ed 100644
--- a/tests/acceptance/features/lib/FilesPageElement/SharingDialogElement/EditPublicLinkPopup.php
+++ b/tests/acceptance/features/lib/FilesPageElement/SharingDialogElement/EditPublicLinkPopup.php
@@ -54,6 +54,7 @@ class EditPublicLinkPopup extends OwncloudPage {
 		'upload' => ".//label[contains(@for, 'sharingDialogAllowPublicUpload')]"
 	];
 	private $popupCloseButton = "//a[@class='oc-dialog-close']";
+	private $expirationDateRequiredErrorMessageXpath = './/*[@id="shareDialogExpirationView"]//span[@class="error-message"]';
 
 	/**
 	 * sets the NodeElement for the current popup
@@ -171,7 +172,7 @@ public function setLinkExpirationDate($date) {
 			" could not find input field for the expiration date of the public link"
 		);
 		$expirationDateInput->setValue($date);
-		
+
 		//try to close the date picker by clicking the label
 		//because that date picker might overlap the email field
 		//but do not panic if the label is not found, maybe we still can
@@ -334,4 +335,23 @@ public function waitTillPageIsLoaded(
 		$popupElement = $this->waitTillXpathIsVisible($xpath, $timeout_msec);
 		$this->setElement($popupElement);
 	}
+
+	/**
+	 *
+	 * @return $errorMessage
+	 * @throws ElementNotFoundException
+	 */
+	public function getErrorMessage() {
+		$errorMessageElement = $this->popupElement->find(
+			"xpath",
+			$this->expirationDateRequiredErrorMessageXpath
+		);
+		$this->assertElementNotNull(
+			$errorMessageElement,
+			__METHOD__ .
+			" xpath $this->expirationDateRequiredErrorMessageXpath" .
+			" could not find expiration date required error message"
+		);
+		return $errorMessageElement->getText();
+	}
 }
diff --git a/tests/acceptance/features/lib/FilesPageElement/SharingDialogElement/PublicLinkTab.php b/tests/acceptance/features/lib/FilesPageElement/SharingDialogElement/PublicLinkTab.php
index 89a8e6880442..d2bf1ec0932a 100644
--- a/tests/acceptance/features/lib/FilesPageElement/SharingDialogElement/PublicLinkTab.php
+++ b/tests/acceptance/features/lib/FilesPageElement/SharingDialogElement/PublicLinkTab.php
@@ -233,6 +233,7 @@ public function editLink(
 		} else {
 			$this->editPublicLinkPopupPageObject->cancel();
 		}
+		return $this->editPublicLinkPopupPageObject;
 	}
 
 	/**
diff --git a/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature b/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
index 6d3f2f17acc2..90258f72d8c5 100644
--- a/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
+++ b/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
@@ -299,7 +299,7 @@ Feature: Share by public link
       | shareType  | 3           |
     When the user changes the expiration of the public link named "Public link" of file "lorem.txt" to "21-07-2038"
     And the user gets the info of the last share using the sharing API
-    Then the fields of the last response should include
+    Then the share fields of the last share should include
       | expiration | 21-07-2038 |
 
   Scenario: user tries to change the expiration date of the public link to past date using webUI
@@ -311,7 +311,7 @@ Feature: Share by public link
     When the user changes the expiration of the public link named "Public link" of file "lorem.txt" to "14-09-2017"
     And the user gets the info of the last share using the sharing API
     Then the user should see an error message on the public link share dialog saying "Expiration date is in the past"
-    And the fields of the last response should include
+    And the share fields of the last share should include
       | expiration | 14-10-2038 |
 
   Scenario: share two file with same name but different paths by public link
@@ -480,4 +480,32 @@ Feature: Share by public link
     And the user opens the public link share tab
     And the user changes the permission of the public link named "Public link" to "read-write"
     And the public accesses the last created public link using the webUI
-    Then it should be possible to delete file "lorem-big.txt" using the webUI
\ No newline at end of file
+    Then it should be possible to delete file "lorem-big.txt" using the webUI
+
+  Scenario: user tries to deletes the expiration date of already existing public link using webUI when expiration date is enforced
+    Given parameter "shareapi_default_expire_date" of app "core" has been set to "yes"
+    And parameter "shareapi_enforce_expire_date" of app "core" has been set to "yes"
+    And user "user1" has created a share with settings
+      | path       | lorem.txt   |
+      | name       | Public link |
+      | expireDate | + 5 days    |
+      | shareType  | 3           |
+    When the user reloads the current page of the webUI
+    And the user changes the expiration of the public link named "Public link" of file "lorem.txt" to " "
+    Then the user should see an error message on the public link popup saying "Expiration date is required"
+    And the user gets the info of the last share using the sharing API
+    And the share fields of the last share should include
+      | expiration | + 5 days   |
+
+  Scenario: user deletes the expiration date of already existing public link using webUI when expiration date is set but not enforced
+    Given parameter "shareapi_default_expire_date" of app "core" has been set to "yes"
+    And user "user1" has created a share with settings
+      | path       | lorem.txt   |
+      | name       | Public link |
+      | expireDate |  + 5 days   |
+      | shareType  | 3           |
+    When the user reloads the current page of the webUI
+    And the user changes the expiration of the public link named "Public link" of file "lorem.txt" to " "
+    And the user gets the info of the last share using the sharing API
+    And the share fields of the last share should include
+      | expiration | |
\ No newline at end of file

From 9e0014068de251895dc21a27c86bbfc20959ca91 Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Wed, 22 May 2019 15:27:02 +0545
Subject: [PATCH 053/131] fix1

---
 tests/acceptance/features/bootstrap/Sharing.php        |  6 ++++--
 .../webUISharingPublic/shareByPublicLink.feature       | 10 +++++-----
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/tests/acceptance/features/bootstrap/Sharing.php b/tests/acceptance/features/bootstrap/Sharing.php
index 2673c0b2a481..3d422123e032 100644
--- a/tests/acceptance/features/bootstrap/Sharing.php
+++ b/tests/acceptance/features/bootstrap/Sharing.php
@@ -660,6 +660,9 @@ public function isFieldInResponse($field, $contentExpected, $data = null) {
 		}
 		if (\count($data->element) > 0) {
 			foreach ($data as $element) {
+				if (!isset($element->$field)) {
+					continue;
+				}
 				if ($contentExpected == "A_TOKEN") {
 					return (\strlen((string)$element->$field) == 15);
 				} elseif ($contentExpected == "A_NUMBER") {
@@ -1299,7 +1302,6 @@ public function checkingTheResponseEntriesCount($count) {
 	}
 
 	/**
-
 	 * @Then the fields of the last response should include
 	 *
 	 * @param TableNode|null $body
@@ -1312,7 +1314,7 @@ public function checkFields($body) {
 
 			foreach ($fd as $field => $value) {
 				$value = $this->replaceValuesFromTable($field, $value);
-				if (!$this->isFieldInShareResponse($field, $value)) {
+				if (!$this->isFieldInResponse($field, $value)) {
 					PHPUnit\Framework\Assert::fail(
 						"$field doesn't have value $value"
 					);
diff --git a/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature b/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
index 90258f72d8c5..e39e154bd957 100644
--- a/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
+++ b/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
@@ -299,7 +299,7 @@ Feature: Share by public link
       | shareType  | 3           |
     When the user changes the expiration of the public link named "Public link" of file "lorem.txt" to "21-07-2038"
     And the user gets the info of the last share using the sharing API
-    Then the share fields of the last share should include
+    Then the fields of the last response should include
       | expiration | 21-07-2038 |
 
   Scenario: user tries to change the expiration date of the public link to past date using webUI
@@ -311,7 +311,7 @@ Feature: Share by public link
     When the user changes the expiration of the public link named "Public link" of file "lorem.txt" to "14-09-2017"
     And the user gets the info of the last share using the sharing API
     Then the user should see an error message on the public link share dialog saying "Expiration date is in the past"
-    And the share fields of the last share should include
+    And the fields of the last response should include
       | expiration | 14-10-2038 |
 
   Scenario: share two file with same name but different paths by public link
@@ -494,7 +494,7 @@ Feature: Share by public link
     And the user changes the expiration of the public link named "Public link" of file "lorem.txt" to " "
     Then the user should see an error message on the public link popup saying "Expiration date is required"
     And the user gets the info of the last share using the sharing API
-    And the share fields of the last share should include
+    And the fields of the last response should include
       | expiration | + 5 days   |
 
   Scenario: user deletes the expiration date of already existing public link using webUI when expiration date is set but not enforced
@@ -507,5 +507,5 @@ Feature: Share by public link
     When the user reloads the current page of the webUI
     And the user changes the expiration of the public link named "Public link" of file "lorem.txt" to " "
     And the user gets the info of the last share using the sharing API
-    And the share fields of the last share should include
-      | expiration | |
\ No newline at end of file
+    And the fields of the last response should include
+      | expiration   | |
\ No newline at end of file

From b2a54df454b5fab5d39bb5b2f23c3de15acf4b3c Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Thu, 23 May 2019 12:39:09 +0545
Subject: [PATCH 054/131] fix2

---
 .../features/apiShareManagementBasic/updateShare.feature        | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/acceptance/features/apiShareManagementBasic/updateShare.feature b/tests/acceptance/features/apiShareManagementBasic/updateShare.feature
index d6bf0b022542..c37597cf0ea7 100644
--- a/tests/acceptance/features/apiShareManagementBasic/updateShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/updateShare.feature
@@ -35,7 +35,7 @@ Feature: sharing
     And the user gets the info of the last share using the sharing API
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
-    And the fields of the last share response should include
+    And the fields of the last response should include
       | id                | A_NUMBER             |
       | item_type         | folder               |
       | item_source       | A_NUMBER             |

From 18d2de512dd890881108044f214d9ab72a93da53 Mon Sep 17 00:00:00 2001
From: Dipak Acharya <dpakach@gmail.com>
Date: Thu, 30 May 2019 12:19:39 +0545
Subject: [PATCH 055/131] Fix suite name to match the suites in encrypion

---
 .drone.yml                                    |  2 +-
 tests/acceptance/config/behat.yml             | 27 ++++++++++---------
 .../userKeys.feature                          |  0
 3 files changed, 15 insertions(+), 14 deletions(-)
 rename tests/acceptance/features/{webUIEncryptionUserKeysType => webUIUserKeysType}/userKeys.feature (100%)

diff --git a/.drone.yml b/.drone.yml
index d60af56f196c..cc2fa841cd0c 100644
--- a/.drone.yml
+++ b/.drone.yml
@@ -1172,7 +1172,7 @@ matrix:
     - PHP_VERSION: 7.1
       TEST_SUITE: selenium
       BROWSER: chrome
-      BEHAT_SUITE: webUIEncryptionUserKeysType
+      BEHAT_SUITE: webUIUserKeysType
       DB_TYPE: mariadb
       USE_SERVER: true
       SERVER_PROTOCOL: https
diff --git a/tests/acceptance/config/behat.yml b/tests/acceptance/config/behat.yml
index 88a01ea4fbb5..c2e35959222f 100644
--- a/tests/acceptance/config/behat.yml
+++ b/tests/acceptance/config/behat.yml
@@ -293,19 +293,6 @@ default:
         - WebUILoginContext:
         - WebUISharingContext:
 
-    webUIEncryptionUserKeysType:
-      paths:
-        - '%paths.base%/../features/webUIEncryptionUserKeysType'
-      contexts:
-        - WebUIAdminEncryptionSettingsContext:
-        - WebUIPersonalEncryptionSettingsContext:
-        - WebUIGeneralContext:
-        - WebUILoginContext:
-        - FeatureContext: *common_feature_context_params
-        - EncryptionContext:
-        - OccContext:
-        - WebDavPropertiesContext:
-
     webUIFavorites:
       paths:
         - '%paths.base%/../features/webUIFavorites'
@@ -504,6 +491,20 @@ default:
         - WebUISharingContext:
         - PublicWebDavContext:
 
+    # This suite is part of the encryption app in later core versions
+    webUIUserKeysType:
+      paths:
+        - '%paths.base%/../features/webUIUserKeysType'
+      contexts:
+        - WebUIAdminEncryptionSettingsContext:
+        - WebUIPersonalEncryptionSettingsContext:
+        - WebUIGeneralContext:
+        - WebUILoginContext:
+        - FeatureContext: *common_feature_context_params
+        - EncryptionContext:
+        - OccContext:
+        - WebDavPropertiesContext:
+
     # This suite is part of the user_management app in later core versions
     webUIManageQuota:
       paths:
diff --git a/tests/acceptance/features/webUIEncryptionUserKeysType/userKeys.feature b/tests/acceptance/features/webUIUserKeysType/userKeys.feature
similarity index 100%
rename from tests/acceptance/features/webUIEncryptionUserKeysType/userKeys.feature
rename to tests/acceptance/features/webUIUserKeysType/userKeys.feature

From 8b784a146148018208b5b52112295780ccd16eb2 Mon Sep 17 00:00:00 2001
From: Dipak Acharya <dpakach@gmail.com>
Date: Wed, 29 May 2019 11:25:30 +0545
Subject: [PATCH 056/131] Get enabled and disabled apps from same request in
 acceptance tests

---
 .../features/bootstrap/Provisioning.php        | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/tests/acceptance/features/bootstrap/Provisioning.php b/tests/acceptance/features/bootstrap/Provisioning.php
index 6f6d2964c579..080a1825371d 100644
--- a/tests/acceptance/features/bootstrap/Provisioning.php
+++ b/tests/acceptance/features/bootstrap/Provisioning.php
@@ -2816,8 +2816,16 @@ public function cleanupGroups() {
 	 * @return void
 	 */
 	public function rememberAppEnabledDisabledState() {
-		$this->enabledApps = $this->getEnabledApps();
-		$this->disabledApps = $this->getDisabledApps();
+		SetupHelper::init(
+			$this->getAdminUsername(),
+			$this->getAdminPassword(),
+			$this->getBaseUrl(),
+			$this->getOcPath()
+		);
+		$this->runOcc(['app:list', '--output json']);
+		$apps = \json_decode($this->getStdOutOfOccCommand(), true);
+		$this->enabledApps = \array_keys($apps["enabled"]);
+		$this->disabledApps = \array_keys($apps["disabled"]);
 	}
 
 	/**
@@ -2826,8 +2834,10 @@ public function rememberAppEnabledDisabledState() {
 	 * @return void
 	 */
 	public function restoreAppEnabledDisabledState() {
-		$currentlyDisabledApps = $this->getDisabledApps();
-		$currentlyEnabledApps = $this->getEnabledApps();
+		$this->runOcc(['app:list', '--output json']);
+		$apps = \json_decode($this->getStdOutOfOccCommand(), true);
+		$currentlyEnabledApps = \array_keys($apps["enabled"]);
+		$currentlyDisabledApps = \array_keys($apps["disabled"]);
 
 		foreach ($currentlyDisabledApps as $disabledApp) {
 			if (\in_array($disabledApp, $this->enabledApps)) {

From 153b6e50546695865f0965c8b418bf59c8098d65 Mon Sep 17 00:00:00 2001
From: paurakhsharma <paurakh011@gmail.com>
Date: Thu, 30 May 2019 12:11:48 +0545
Subject: [PATCH 057/131] Fix feature context undefined on provisioning.php

---
 tests/acceptance/features/bootstrap/Provisioning.php | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tests/acceptance/features/bootstrap/Provisioning.php b/tests/acceptance/features/bootstrap/Provisioning.php
index 080a1825371d..511d6e4b0203 100644
--- a/tests/acceptance/features/bootstrap/Provisioning.php
+++ b/tests/acceptance/features/bootstrap/Provisioning.php
@@ -279,14 +279,14 @@ public function userHasBeenCreatedWithDefaultAttributes($user) {
 	 * @return void
 	 */
 	public function userHasBeenCreatedWithDefaultAttributesAndWithoutSkeletonFiles($user) {
-		$this->featureContext->runOcc(["config:system:get skeletondirectory"]);
-		$path = \trim($this->featureContext->getStdOutOfOccCommand());
-		$this->featureContext->runOcc(["config:system:delete skeletondirectory"]);
+		$this->runOcc(["config:system:get skeletondirectory"]);
+		$path = \trim($this->getStdOutOfOccCommand());
+		$this->runOcc(["config:system:delete skeletondirectory"]);
 		try {
-			$this->featureContext->userHasBeenCreatedWithDefaultAttributes($user);
+			$this->userHasBeenCreatedWithDefaultAttributes($user);
 		} finally {
 			// restore skeletondirectory even if user creation failed
-			$this->featureContext->runOcc(["config:system:set skeletondirectory --value $path"]);
+			$this->runOcc(["config:system:set skeletondirectory --value $path"]);
 		}
 	}
 

From 6923a2d164f7f7d4a64f53a08cfbe7b362bcccd3 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Thu, 30 May 2019 12:41:05 +0545
Subject: [PATCH 058/131] Change 'in the webUI' to 'on  the webUI'

---
 .../features/bootstrap/WebUIFilesContext.php  | 30 ++++++++--------
 .../bootstrap/WebUIHelpAndTipsContext.php     |  4 +--
 .../WebUIPersonalGeneralSettingsContext.php   | 18 +++++-----
 .../WebUIPersonalSharingSettingsContext.php   |  8 ++---
 .../features/bootstrap/WebUITagsContext.php   |  2 +-
 .../features/lib/FilesPageBasic.php           |  2 +-
 .../lib/FilesPageElement/DetailsDialog.php    |  8 ++---
 .../lib/PersonalGeneralSettingsPage.php       |  2 +-
 .../lib/PersonalSharingSettingsPage.php       |  6 ++--
 .../webUIAdminSettings/helpAndTips.feature    |  2 +-
 .../features/webUIFiles/fileDetails.feature   | 36 +++++++++----------
 .../features/webUIFiles/versions.feature      |  6 ++--
 .../personalGeneralSettings.feature           | 32 ++++++++---------
 .../acceptShares.feature                      |  2 +-
 .../federationSharing.feature                 |  2 +-
 .../shareByPublicLink.feature                 | 16 ++++-----
 16 files changed, 88 insertions(+), 88 deletions(-)

diff --git a/tests/acceptance/features/bootstrap/WebUIFilesContext.php b/tests/acceptance/features/bootstrap/WebUIFilesContext.php
index e44025175e04..6402f78ddd86 100644
--- a/tests/acceptance/features/bootstrap/WebUIFilesContext.php
+++ b/tests/acceptance/features/bootstrap/WebUIFilesContext.php
@@ -1118,8 +1118,8 @@ public function theDeletedMovedElementsShouldBeListedOnTheWebUIAfterPageReload(
 	 * @return void
 	 */
 	public function theUserOpensTheSharingTabFromTheActionMenuOfFileUsingTheWebui($entryName) {
-		$this->theUserOpensTheFileActionMenuOfFileFolderInTheWebui($entryName);
-		$this->theUserClicksTheFileActionInTheWebui("details");
+		$this->theUserOpensTheFileActionMenuOfFileFolderOnTheWebui($entryName);
+		$this->theUserClicksTheFileActionOnTheWebui("details");
 		$this->theUserSwitchesToTabInDetailsPanelUsingTheWebui("sharing");
 		$this->filesPage->waitForAjaxCallsToStartAndFinish($this->getSession());
 	}
@@ -1411,7 +1411,7 @@ public function fileFolderShouldBeListedOnTheWebUI(
 	 * @param string $shouldOrNot
 	 * @param string $typeOfFilesPage
 	 * @param string $folder
-	 * @param string $path if set, name and path (shown in the webUI) of the file need match
+	 * @param string $path if set, name and path (shown on the webUI) of the file to match
 	 *
 	 * @return void
 	 * @throws \Exception
@@ -1699,7 +1699,7 @@ public function itShouldBePossibleToDeleteFileFolderUsingTheWebUI($name) {
 	}
 
 	/**
-	 * @Then /^the option to (delete|rename|download)\s?(?:file|folder) "([^"]*)" should (not|)\s?be available in the webUI$/
+	 * @Then /^the option to (delete|rename|download)\s?(?:file|folder) "([^"]*)" should (not|)\s?be available on the webUI$/
 	 *
 	 * @param string $action
 	 * @param string $name
@@ -1724,7 +1724,7 @@ public function optionShouldNotBeAvailable($action, $name, $shouldOrNot) {
 	}
 
 	/**
-	 * @Then /^the option to upload file should (not|)\s?be available in the webUI$/
+	 * @Then /^the option to upload file should (not|)\s?be available on the webUI$/
 	 *
 	 * @param string $shouldOrNot
 	 *
@@ -2031,27 +2031,27 @@ public function theUserEnablesTheSettingToViewHiddenFoldersOnTheWebUI() {
 	}
 
 	/**
-	 * @When the user opens the file action menu of file/folder :name in the webUI
+	 * @When the user opens the file action menu of file/folder :name on the webUI
 	 *
 	 * @param string $name Name of the file/Folder
 	 *
 	 * @return void
 	 */
-	public function theUserOpensTheFileActionMenuOfFileFolderInTheWebui($name) {
+	public function theUserOpensTheFileActionMenuOfFileFolderOnTheWebui($name) {
 		$session = $this->getSession();
 		$this->selectedFileRow = $this->getCurrentPageObject()->findFileRowByName($name, $session);
 		$this->openedFileActionMenu = $this->selectedFileRow->openFileActionsMenu($session);
 	}
 
 	/**
-	 * @Then the user should see :action_label file action translated to :translated_label in the webUI
+	 * @Then the user should see :action_label file action translated to :translated_label on the webUI
 	 *
 	 * @param string $action_label
 	 * @param string $translated_label
 	 *
 	 * @return void
 	 */
-	public function theUserShouldSeeFileActionTranslatedToInTheWebui($action_label, $translated_label) {
+	public function theUserShouldSeeFileActionTranslatedToOnTheWebui($action_label, $translated_label) {
 		PHPUnit\Framework\Assert::assertSame(
 			$translated_label,
 			$this->openedFileActionMenu->getActionLabelLocalized($action_label)
@@ -2059,14 +2059,14 @@ public function theUserShouldSeeFileActionTranslatedToInTheWebui($action_label,
 	}
 
 	/**
-	 * @When the user clicks the :action_label file action in the webUI
+	 * @When the user clicks the :action_label file action on the webUI
 	 *
 	 * @param string $action_label
 	 *
 	 * @throws \Exception
 	 * @return void
 	 */
-	public function theUserClicksTheFileActionInTheWebui($action_label) {
+	public function theUserClicksTheFileActionOnTheWebui($action_label) {
 		switch ($action_label) {
 			case "details":
 				$this->openedFileActionMenu->openDetails();
@@ -2087,11 +2087,11 @@ public function theUserClicksTheFileActionInTheWebui($action_label) {
 	}
 
 	/**
-	 * @Then the details dialog should be visible in the webUI
+	 * @Then the details dialog should be visible on the webUI
 	 *
 	 * @return void
 	 */
-	public function theDetailsDialogShouldBeVisibleInTheWebui() {
+	public function theDetailsDialogShouldBeVisibleOnTheWebui() {
 		PHPUnit\Framework\Assert::assertTrue($this->filesPage->getDetailsDialog()->isDialogVisible());
 	}
 
@@ -2152,12 +2152,12 @@ public function theCommentShouldBeListedInTheCommentsTabInDetailsDialog($text, $
 		if ($should) {
 			PHPUnit\Framework\Assert::assertTrue(
 				$detailsDialog->isCommentOnUI($text),
-				"Failed to find comment with text $text in the webUI"
+				"Failed to find comment with text $text on the webUI"
 			);
 		} else {
 			PHPUnit\Framework\Assert::assertFalse(
 				$detailsDialog->isCommentOnUI($text),
-				"The comment with text $text exists in the webUI"
+				"The comment with text $text exists on the webUI"
 			);
 		}
 	}
diff --git a/tests/acceptance/features/bootstrap/WebUIHelpAndTipsContext.php b/tests/acceptance/features/bootstrap/WebUIHelpAndTipsContext.php
index 08952209236a..c890adbdaeac 100644
--- a/tests/acceptance/features/bootstrap/WebUIHelpAndTipsContext.php
+++ b/tests/acceptance/features/bootstrap/WebUIHelpAndTipsContext.php
@@ -108,13 +108,13 @@ public function theAdministratorHasBrowsedToTheHelpAndTipsPage() {
 	}
 
 	/**
-	 * @Then the link for :linkTitle should be shown in the webUI
+	 * @Then the link for :linkTitle should be shown on the webUI
 	 *
 	 * @param string $linkTitle
 	 *
 	 * @return void
 	 */
-	public function theLinkForShouldBeShownInTheWebui($linkTitle) {
+	public function theLinkForShouldBeShownOnTheWebui($linkTitle) {
 		$link = $this->helpAndTipsPage->getLinkByTitle($linkTitle);
 		$this->helpAndTipsPage->assertElementNotNull(
 			$link,
diff --git a/tests/acceptance/features/bootstrap/WebUIPersonalGeneralSettingsContext.php b/tests/acceptance/features/bootstrap/WebUIPersonalGeneralSettingsContext.php
index daf23dc045d8..5a4e6c9e8ea6 100644
--- a/tests/acceptance/features/bootstrap/WebUIPersonalGeneralSettingsContext.php
+++ b/tests/acceptance/features/bootstrap/WebUIPersonalGeneralSettingsContext.php
@@ -188,34 +188,34 @@ public function theUserChangesTheEmailAddressToUsingTheWebUI($emailAddress) {
 	}
 
 	/**
-	 * @Then the owncloud version should be displayed on the personal general settings page in the webUI
+	 * @Then the owncloud version should be displayed on the personal general settings page on the webUI
 	 *
 	 * @return void
 	 */
-	public function theOwncloudVersionShouldBeDisplayedOnThePersonalGeneralSettingsPageInTheWebui() {
+	public function theOwncloudVersionShouldBeDisplayedOnThePersonalGeneralSettingsPageOnTheWebui() {
 		PHPUnit\Framework\Assert::assertTrue($this->personalGeneralSettingsPage->isVersionDisplayed());
 	}
 
 	/**
-	 * @Then the federated cloud id for user :user should be displayed on the personal general settings page in the webUI
+	 * @Then the federated cloud id for user :user should be displayed on the personal general settings page on the webUI
 	 *
 	 * @param string $user
 	 *
 	 * @return void
 	 */
-	public function theFederatedCloudIdForUserShouldBeDisplayedOnThePersonalGeneralSettingsPageInTheWebui($user) {
+	public function theFederatedCloudIdForUserShouldBeDisplayedOnThePersonalGeneralSettingsPageOnTheWebui($user) {
 		$userFederatedCloudId = $user . "@" . $this->featureContext->getLocalBaseUrlWithoutScheme();
 		PHPUnit\Framework\Assert::assertEquals($this->personalGeneralSettingsPage->getFederatedCloudID(), $userFederatedCloudId);
 	}
 
 	/**
-	 * @Then group :groupName should be displayed on the personal general settings page in the webUI
+	 * @Then group :groupName should be displayed on the personal general settings page on the webUI
 	 *
 	 * @param string $groupName
 	 *
 	 * @return void
 	 */
-	public function groupShouldBeDisplayedOnThePersonalGeneralSettingsPageInTheWebui($groupName) {
+	public function groupShouldBeDisplayedOnThePersonalGeneralSettingsPageOnTheWebui($groupName) {
 		PHPUnit\Framework\Assert::assertTrue($this->personalGeneralSettingsPage->isGroupNameDisplayed($groupName));
 	}
 
@@ -280,17 +280,17 @@ public function theUserSetsProfilePictureToFromTheirCloudFiles($filename) {
 	 */
 	public function theUserHasSetProfilePictureToFromTheirCloudFiles($filename) {
 		$this->theUserSetsProfilePictureToFromTheirCloudFiles($filename);
-		$this->thePreviewOfTheProfilePictureShouldBeShownInTheWebui("");
+		$this->thePreviewOfTheProfilePictureShouldBeShownOnTheWebui("");
 	}
 
 	/**
-	 * @Then /^the preview of the profile picture should (not|)\s?be shown in the webUI$/
+	 * @Then /^the preview of the profile picture should (not|)\s?be shown on the webUI$/
 	 *
 	 * @param string $shouldOrNot
 	 *
 	 * @return void
 	 */
-	public function thePreviewOfTheProfilePictureShouldBeShownInTheWebui($shouldOrNot) {
+	public function thePreviewOfTheProfilePictureShouldBeShownOnTheWebui($shouldOrNot) {
 		if ($shouldOrNot !== "not") {
 			PHPUnit\Framework\Assert::assertTrue(
 				$this->personalGeneralSettingsPage->isProfilePicturePreviewDisplayed()
diff --git a/tests/acceptance/features/bootstrap/WebUIPersonalSharingSettingsContext.php b/tests/acceptance/features/bootstrap/WebUIPersonalSharingSettingsContext.php
index 72ba17015215..dee5da27758f 100644
--- a/tests/acceptance/features/bootstrap/WebUIPersonalSharingSettingsContext.php
+++ b/tests/acceptance/features/bootstrap/WebUIPersonalSharingSettingsContext.php
@@ -95,22 +95,22 @@ public function switchAllowFindingYouViaAutocompleteInShareDialog($action) {
 	}
 
 	/**
-	 * @Then User-based auto accepting checkbox should not be displayed on the personal sharing settings page in the webUI
+	 * @Then User-based auto accepting checkbox should not be displayed on the personal sharing settings page on the webUI
 	 *
 	 * @return void
 	 */
-	public function autoAcceptingCheckboxShouldNotBeDisplayedOnThePersonalSharingSettingsPageInTheWebui() {
+	public function autoAcceptingCheckboxShouldNotBeDisplayedOnThePersonalSharingSettingsPageOnTheWebui() {
 		PHPUnit\Framework\Assert::assertFalse(
 			$this->personalSharingSettingsPage->isAutoAcceptLocalSharesCheckboxDisplayed()
 		);
 	}
 
 	/**
-	 * @Then User-based auto accepting from trusted servers checkbox should not be displayed on the personal sharing settings page in the webUI
+	 * @Then User-based auto accepting from trusted servers checkbox should not be displayed on the personal sharing settings page on the webUI
 	 *
 	 * @return void
 	 */
-	public function autoAcceptingFederatedCheckboxShouldNotBeDisplayedOnThePersonalSharingSettingsPageInTheWebui() {
+	public function autoAcceptingFederatedCheckboxShouldNotBeDisplayedOnThePersonalSharingSettingsPageOnTheWebui() {
 		PHPUnit\Framework\Assert::assertFalse(
 			$this->personalSharingSettingsPage->isAutoAcceptFederatedSharesCheckboxDisplayed()
 		);
diff --git a/tests/acceptance/features/bootstrap/WebUITagsContext.php b/tests/acceptance/features/bootstrap/WebUITagsContext.php
index 2aafa67d46d2..82e2e6ba2d90 100644
--- a/tests/acceptance/features/bootstrap/WebUITagsContext.php
+++ b/tests/acceptance/features/bootstrap/WebUITagsContext.php
@@ -81,7 +81,7 @@ public function theUserAddsATagToTheFileUsingTheWebUI($tagName) {
 		$this->filesPage->getDetailsDialog()->addTag($tagName);
 
 		// For tags to be created, OC checks (|for the permission) if the tag could be created
-		// and if it can, then only it creates a tag. So, in the webUI, it does two
+		// and if it can, then only it creates a tag. So, on the webUI, it does two
 		// requests before the tags are created.
 		// If we use a single wait, it returns after it has checked for the permission.
 		// Locally that passes but sometimes fail on the ci. So, we need two waits for each requests.
diff --git a/tests/acceptance/features/lib/FilesPageBasic.php b/tests/acceptance/features/lib/FilesPageBasic.php
index eb14fd07297e..b599a68b85f2 100644
--- a/tests/acceptance/features/lib/FilesPageBasic.php
+++ b/tests/acceptance/features/lib/FilesPageBasic.php
@@ -652,7 +652,7 @@ public function enableShowHiddenFilesSettings() {
 	}
 
 	/**
-	 * Return is New File/folder button is available in the webUI
+	 * Return is New File/folder button is available on the webUI
 	 *
 	 * @return boolean
 	 */
diff --git a/tests/acceptance/features/lib/FilesPageElement/DetailsDialog.php b/tests/acceptance/features/lib/FilesPageElement/DetailsDialog.php
index 2a9e1c220b98..4a7a857ef9db 100644
--- a/tests/acceptance/features/lib/FilesPageElement/DetailsDialog.php
+++ b/tests/acceptance/features/lib/FilesPageElement/DetailsDialog.php
@@ -223,7 +223,7 @@ public function isDialogVisible() {
 	}
 
 	/**
-	 * get the list of comments listed in the webUI
+	 * get the list of comments listed on the webUI
 	 *
 	 * @return NodeElement[]
 	 */
@@ -233,7 +233,7 @@ public function getCommentList() {
 		);
 	}
 	/**
-	 * check if a comment with given text is listed in the webUI
+	 * check if a comment with given text is listed on the webUI
 	 *
 	 * @param string $text
 	 *
@@ -254,7 +254,7 @@ public function isCommentOnUI($text) {
 	}
 
 	/**
-	 * add a comment in a file whose details dialog is shown in the webUI
+	 * add a comment in a file whose details dialog is shown on the webUI
 	 *
 	 * @param Session $session
 	 * @param string $content
@@ -290,7 +290,7 @@ public function addComment(Session $session, $content) {
 	}
 
 	/**
-	 * delete the comment in a file whose details dialog is shown in the webUI with given content
+	 * delete the comment in a file whose details dialog is shown on the webUI with given content
 	 *
 	 * @param string $content
 	 *
diff --git a/tests/acceptance/features/lib/PersonalGeneralSettingsPage.php b/tests/acceptance/features/lib/PersonalGeneralSettingsPage.php
index 799daff67821..f885e9b23e60 100644
--- a/tests/acceptance/features/lib/PersonalGeneralSettingsPage.php
+++ b/tests/acceptance/features/lib/PersonalGeneralSettingsPage.php
@@ -260,7 +260,7 @@ public function setProfilePicture($fileName, Session $session) {
 	}
 
 	/**
-	 * Check if the preview of the profile pic is shown in the webui
+	 * Check if the preview of the profile pic is shown on the webui
 	 *
 	 * @return boolean
 	 */
diff --git a/tests/acceptance/features/lib/PersonalSharingSettingsPage.php b/tests/acceptance/features/lib/PersonalSharingSettingsPage.php
index 098dddbd203c..5a85dc28f52f 100644
--- a/tests/acceptance/features/lib/PersonalSharingSettingsPage.php
+++ b/tests/acceptance/features/lib/PersonalSharingSettingsPage.php
@@ -114,7 +114,7 @@ public function waitTillPageIsLoaded(
 	}
 
 	/**
-	 * Check if the auto accept local shares checkbox is shown in the webui
+	 * Check if the auto accept local shares checkbox is shown on the webui
 	 *
 	 * @return boolean
 	 */
@@ -127,7 +127,7 @@ public function isAutoAcceptLocalSharesCheckboxDisplayed() {
 	}
 
 	/**
-	 * Check if the auto accept local shares checkbox is shown in the webui
+	 * Check if the auto accept local shares checkbox is shown on the webui
 	 *
 	 * @return boolean
 	 */
@@ -140,7 +140,7 @@ public function isAutoAcceptFederatedSharesCheckboxDisplayed() {
 	}
 
 	/**
-	 * Check if the allow finding you via autocomplete checkbox is shown in the webui
+	 * Check if the allow finding you via autocomplete checkbox is shown on the webui
 	 *
 	 * @return boolean
 	 */
diff --git a/tests/acceptance/features/webUIAdminSettings/helpAndTips.feature b/tests/acceptance/features/webUIAdminSettings/helpAndTips.feature
index 8e913297b6dc..94dad7590c0d 100644
--- a/tests/acceptance/features/webUIAdminSettings/helpAndTips.feature
+++ b/tests/acceptance/features/webUIAdminSettings/helpAndTips.feature
@@ -8,7 +8,7 @@ Feature: Help and tips page
     Given the administrator has browsed to the help and tips page
 
   Scenario Outline: Admin can view links in help and tips page
-    Then the link for "<linkName>" should be shown in the webUI
+    Then the link for "<linkName>" should be shown on the webUI
     And the link for "<linkName>" should be valid
     Examples:
       | linkName                        |
diff --git a/tests/acceptance/features/webUIFiles/fileDetails.feature b/tests/acceptance/features/webUIFiles/fileDetails.feature
index 4d8d0f35e42a..00a38d72d804 100644
--- a/tests/acceptance/features/webUIFiles/fileDetails.feature
+++ b/tests/acceptance/features/webUIFiles/fileDetails.feature
@@ -13,9 +13,9 @@ Feature: User can open the details panel for any file or folder
 
   @comments-app-required @files_versions-app-required
   Scenario: View different areas of the details panel in files page
-    When the user opens the file action menu of file "lorem.txt" in the webUI
-    And the user clicks the details file action in the webUI
-    Then the details dialog should be visible in the webUI
+    When the user opens the file action menu of file "lorem.txt" on the webUI
+    And the user clicks the details file action on the webUI
+    Then the details dialog should be visible on the webUI
     And the thumbnail should be visible in the details panel
     When the user switches to "sharing" tab in details panel using the webUI
     Then the "sharing" details panel should be visible
@@ -28,9 +28,9 @@ Feature: User can open the details panel for any file or folder
   Scenario: View different areas of the details panel in favorites page
     When the user marks file "lorem.txt" as favorite using the webUI
     And the user browses to the favorites page
-    And the user opens the file action menu of file "lorem.txt" in the webUI
-    And the user clicks the details file action in the webUI
-    Then the details dialog should be visible in the webUI
+    And the user opens the file action menu of file "lorem.txt" on the webUI
+    And the user clicks the details file action on the webUI
+    Then the details dialog should be visible on the webUI
     And the thumbnail should be visible in the details panel
     When the user switches to "sharing" tab in details panel using the webUI
     Then the "sharing" details panel should be visible
@@ -44,9 +44,9 @@ Feature: User can open the details panel for any file or folder
     Given the user has created a new public link for folder "simple-folder" using the webUI
     When the user browses to the shared-by-link page
     Then folder "simple-folder" should be listed on the webUI
-    When the user opens the file action menu of folder "simple-folder" in the webUI
-    And the user clicks the details file action in the webUI
-    Then the details dialog should be visible in the webUI
+    When the user opens the file action menu of folder "simple-folder" on the webUI
+    And the user clicks the details file action on the webUI
+    Then the details dialog should be visible on the webUI
     And the thumbnail should be visible in the details panel
     When the user switches to "sharing" tab in details panel using the webUI
     Then the "sharing" details panel should be visible
@@ -59,9 +59,9 @@ Feature: User can open the details panel for any file or folder
     And the user has shared folder "simple-folder" with user "User Two" using the webUI
     When the user browses to the shared-with-others page
     Then folder "simple-folder" should be listed on the webUI
-    When the user opens the file action menu of folder "simple-folder" in the webUI
-    And the user clicks the details file action in the webUI
-    Then the details dialog should be visible in the webUI
+    When the user opens the file action menu of folder "simple-folder" on the webUI
+    And the user clicks the details file action on the webUI
+    Then the details dialog should be visible on the webUI
     And the thumbnail should be visible in the details panel
     When the user switches to "sharing" tab in details panel using the webUI
     Then the "sharing" details panel should be visible
@@ -75,9 +75,9 @@ Feature: User can open the details panel for any file or folder
     And the user re-logs in as "user2" using the webUI
     When the user browses to the shared-with-you page
     Then folder "simple-folder (2)" should be listed on the webUI
-    When the user opens the file action menu of folder "simple-folder (2)" in the webUI
-    And the user clicks the details file action in the webUI
-    Then the details dialog should be visible in the webUI
+    When the user opens the file action menu of folder "simple-folder (2)" on the webUI
+    And the user clicks the details file action on the webUI
+    Then the details dialog should be visible on the webUI
     And the thumbnail should be visible in the details panel
     When the user switches to "sharing" tab in details panel using the webUI
     Then the "sharing" details panel should be visible
@@ -91,9 +91,9 @@ Feature: User can open the details panel for any file or folder
     When the user browses to the tags page
     And the user searches for tag "simple" using the webUI
     Then folder "simple-folder" should be listed on the webUI
-    When the user opens the file action menu of folder "simple-folder" in the webUI
-    And the user clicks the details file action in the webUI
-    Then the details dialog should be visible in the webUI
+    When the user opens the file action menu of folder "simple-folder" on the webUI
+    And the user clicks the details file action on the webUI
+    Then the details dialog should be visible on the webUI
     And the thumbnail should be visible in the details panel
     When the user switches to "sharing" tab in details panel using the webUI
     Then the "sharing" details panel should be visible
diff --git a/tests/acceptance/features/webUIFiles/versions.feature b/tests/acceptance/features/webUIFiles/versions.feature
index 1c4b93642bb7..55aa77644bf0 100644
--- a/tests/acceptance/features/webUIFiles/versions.feature
+++ b/tests/acceptance/features/webUIFiles/versions.feature
@@ -43,7 +43,7 @@ Feature: Versions of a file
     And the versions list should contain 2 entries
 
   @skipOnStorage:ceph @files_primary_s3-issue-155
-  Scenario: file versions cannot be seen in the webUI after deleting versions
+  Scenario: file versions cannot be seen on the webUI after deleting versions
     Given user "user0" has uploaded file with content "lorem content" to "/lorem-file.txt"
     And user "user0" has uploaded file with content "lorem" to "/lorem-file.txt"
     And user "user0" has uploaded file with content "new lorem content" to "/lorem-file.txt"
@@ -54,7 +54,7 @@ Feature: Versions of a file
     And the versions list should contain 0 entries
 
   @skipOnStorage:ceph @files_primary_s3-issue-155
-  Scenario: file versions cannot be seen in the webUI only for user whose versions is deleted
+  Scenario: file versions cannot be seen on the webUI only for user whose versions is deleted
     Given user "user1" has been created with default attributes
     And user "user0" has uploaded file with content "lorem content" to "/lorem-file.txt"
     And user "user0" has uploaded file with content "lorem" to "/lorem-file.txt"
@@ -72,7 +72,7 @@ Feature: Versions of a file
     Then the versions list should contain 1 entries
 
   @skipOnStorage:ceph @files_primary_s3-issue-155
-  Scenario: file versions cannot be seen in the webUI for all users after deleting versions for all users
+  Scenario: file versions cannot be seen on the webUI for all users after deleting versions for all users
     Given user "user1" has been created with default attributes
     And user "user0" has uploaded file with content "lorem content" to "/lorem-file.txt"
     And user "user0" has uploaded file with content "lorem" to "/lorem-file.txt"
diff --git a/tests/acceptance/features/webUIPersonalSettings/personalGeneralSettings.feature b/tests/acceptance/features/webUIPersonalSettings/personalGeneralSettings.feature
index 300d60d40455..7c8b99e21137 100644
--- a/tests/acceptance/features/webUIPersonalSettings/personalGeneralSettings.feature
+++ b/tests/acceptance/features/webUIPersonalSettings/personalGeneralSettings.feature
@@ -17,23 +17,23 @@ Feature: personal general settings
   Scenario: change language and check that file actions menu have been translated
     When the user changes the language to "हिन्दी" using the webUI
     And the user browses to the files page
-    And the user opens the file action menu of folder "simple-folder" in the webUI
-    Then the user should see "Details" file action translated to "विवरण" in the webUI
-    And the user should see "Delete" file action translated to "हटाना" in the webUI
+    And the user opens the file action menu of folder "simple-folder" on the webUI
+    Then the user should see "Details" file action translated to "विवरण" on the webUI
+    And the user should see "Delete" file action translated to "हटाना" on the webUI
 
   Scenario: change language using the occ command and check that file actions menu have been translated
     When the administrator changes the language of user "user1" to "fr" using the occ command
     And the user browses to the files page
-    And the user opens the file action menu of folder "simple-folder" in the webUI
-    Then the user should see "Details" file action translated to "Détails" in the webUI
-    And the user should see "Delete" file action translated to "Supprimer" in the webUI
+    And the user opens the file action menu of folder "simple-folder" on the webUI
+    Then the user should see "Details" file action translated to "Détails" on the webUI
+    And the user should see "Delete" file action translated to "Supprimer" on the webUI
 
   Scenario: change language to invalid language using the occ command and check that the language defaults back to english
     When the administrator changes the language of user "user1" to "not-valid-lan" using the occ command
     And the user browses to the files page
-    And the user opens the file action menu of folder "simple-folder" in the webUI
-    Then the user should see "Details" file action translated to "Details" in the webUI
-    And the user should see "Delete" file action translated to "Delete" in the webUI
+    And the user opens the file action menu of folder "simple-folder" on the webUI
+    Then the user should see "Details" file action translated to "Details" on the webUI
+    And the user should see "Delete" file action translated to "Delete" on the webUI
 
   Scenario: user sees displayed version number, groupnames and federated cloud ID on the personal general settings page
     Given group "new-group" has been created
@@ -41,25 +41,25 @@ Feature: personal general settings
     And user "user1" has been added to group "new-group"
     And user "user1" has been added to group "another-group"
     And the user has reloaded the current page of the webUI
-    Then the owncloud version should be displayed on the personal general settings page in the webUI
-    And the federated cloud id for user "user1" should be displayed on the personal general settings page in the webUI
-    And group "new-group" should be displayed on the personal general settings page in the webUI
-    And group "another-group" should be displayed on the personal general settings page in the webUI
+    Then the owncloud version should be displayed on the personal general settings page on the webUI
+    And the federated cloud id for user "user1" should be displayed on the personal general settings page on the webUI
+    And group "new-group" should be displayed on the personal general settings page on the webUI
+    And group "another-group" should be displayed on the personal general settings page on the webUI
 
   Scenario: User sets profile picture from their existing cloud file
     Given the user has deleted any existing profile picture
     When the user sets profile picture to "testimage.jpg" from their cloud files using the webUI
-    Then the preview of the profile picture should be shown in the webUI
+    Then the preview of the profile picture should be shown on the webUI
 
   Scenario: User deletes the existing profile picture
     Given the user has set profile picture to "testimage.jpg" from their cloud files
     When the user deletes the existing profile picture
-    Then the preview of the profile picture should not be shown in the webUI
+    Then the preview of the profile picture should not be shown on the webUI
 
   Scenario: User uploads new profile picture
     Given the user has deleted any existing profile picture
     When the user uploads "testavatar.png" as a new profile picture using the webUI
-    Then the preview of the profile picture should be shown in the webUI
+    Then the preview of the profile picture should be shown on the webUI
 
   Scenario Outline: User tries to upload different files as profile picture
     Given the user has deleted any existing profile picture
diff --git a/tests/acceptance/features/webUISharingAcceptShares/acceptShares.feature b/tests/acceptance/features/webUISharingAcceptShares/acceptShares.feature
index 8aa19eff1144..8b647feda276 100644
--- a/tests/acceptance/features/webUISharingAcceptShares/acceptShares.feature
+++ b/tests/acceptance/features/webUISharingAcceptShares/acceptShares.feature
@@ -274,7 +274,7 @@ Feature: accept/decline shares coming from internal users
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been disabled
     And user "user1" has logged in using the webUI
     And the user has browsed to the personal sharing settings page
-    Then User-based auto accepting checkbox should not be displayed on the personal sharing settings page in the webUI
+    Then User-based auto accepting checkbox should not be displayed on the personal sharing settings page on the webUI
 
   Scenario: Admin disables auto-accept setting again after user enabled personal auto-accept setting
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been enabled
diff --git a/tests/acceptance/features/webUISharingExternal/federationSharing.feature b/tests/acceptance/features/webUISharingExternal/federationSharing.feature
index d3a2b7580b95..999a137c3f28 100644
--- a/tests/acceptance/features/webUISharingExternal/federationSharing.feature
+++ b/tests/acceptance/features/webUISharingExternal/federationSharing.feature
@@ -100,7 +100,7 @@ Feature: Federation Sharing - sharing with users on other cloud storages
     And parameter "auto_accept_trusted" of app "federatedfilesharing" has been set to "no"
     And parameter "autoAddServers" of app "federation" has been set to "0"
     And the user has browsed to the personal sharing settings page
-    Then User-based auto accepting from trusted servers checkbox should not be displayed on the personal sharing settings page in the webUI
+    Then User-based auto accepting from trusted servers checkbox should not be displayed on the personal sharing settings page on the webUI
 
   @skip @issue-34742
   Scenario: User-based & global auto accepting is enabled but remote server is not trusted
diff --git a/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature b/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
index e39e154bd957..809bb6e08144 100644
--- a/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
+++ b/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
@@ -429,17 +429,17 @@ Feature: Share by public link
     Given the user has created a new public link for folder "simple-folder" using the webUI with
       | permission | upload-write-without-modify |
     When the public accesses the last created public link using the webUI
-    Then the option to rename file "lorem.txt" should not be available in the webUI
-    And the option to delete file "lorem.txt" should not be available in the webUI
-    And the option to upload file should be available in the webUI
+    Then the option to rename file "lorem.txt" should not be available on the webUI
+    And the option to delete file "lorem.txt" should not be available on the webUI
+    And the option to upload file should be available on the webUI
 
   Scenario: Permissions work correctly on public link share with read-write
     Given the user has created a new public link for folder "simple-folder" using the webUI with
       | permission | read-write |
     When the public accesses the last created public link using the webUI
-    Then the option to rename file "lorem.txt" should be available in the webUI
-    And the option to delete file "lorem.txt" should be available in the webUI
-    And the option to upload file should be available in the webUI
+    Then the option to rename file "lorem.txt" should be available on the webUI
+    And the option to delete file "lorem.txt" should be available on the webUI
+    And the option to upload file should be available on the webUI
 
   Scenario: User tries to upload existing file in public link share with permissions upload-write-without-modify
     Given the user has created a new public link for folder "simple-folder" using the webUI with
@@ -468,13 +468,13 @@ Feature: Share by public link
     And the user opens the public link share tab
     And the user changes the permission of the public link named "Public link" to "upload-write-without-modify"
     And the public accesses the last created public link using the webUI
-    Then the option to delete file "lorem-big.txt" should not be available in the webUI
+    Then the option to delete file "lorem-big.txt" should not be available on the webUI
 
   Scenario: Editing the permission on a existing share from upload-write-without-modify to read-write works correctly
     Given the user has created a new public link for folder "simple-folder" using the webUI with
       | permission | upload-write-without-modify |
     And the public accesses the last created public link using the webUI
-    Then the option to delete file "lorem.txt" should not be available in the webUI
+    Then the option to delete file "lorem.txt" should not be available on the webUI
     When the user browses to the files page
     And the user opens the share dialog for folder "simple-folder"
     And the user opens the public link share tab

From f4af729e97773a73d4078e7c1132a3eefee15629 Mon Sep 17 00:00:00 2001
From: Artur Neumann <artur@jankaritech.com>
Date: Thu, 30 May 2019 11:01:26 +0545
Subject: [PATCH 059/131] make search tests more flexible

---
 .../features/apiWebdavOperations/search.feature       | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/tests/acceptance/features/apiWebdavOperations/search.feature b/tests/acceptance/features/apiWebdavOperations/search.feature
index 7d4d3ab0a3e2..cc9f02c609cf 100644
--- a/tests/acceptance/features/apiWebdavOperations/search.feature
+++ b/tests/acceptance/features/apiWebdavOperations/search.feature
@@ -96,9 +96,14 @@ Feature: Search
     Given using <dav_version> DAV path
     When user "user0" searches for "upload" and limits the results to "1" items using the WebDAV API
     Then the HTTP status code should be "207"
-    And the search result should contain "1" entries
-    And the search result should contain these entries:
-      | /upload folder |
+    And the search result should contain any "1" of these entries:
+      | /just-a-folder/upload.txt     |
+      | /just-a-folder/uploadÜठिF.txt |
+      | /upload folder                |
+      | /upload.txt                   |
+      | /फनी näme/upload.txt          |
+      | /upload😀 😁                  |
+      | /upload😀 😁/upload😀 😁.txt  |
     Examples:
       | dav_version |
       | old         |

From 74671b1078fa535e76c7002b2854bfcac00d12b8 Mon Sep 17 00:00:00 2001
From: bhawana <bhawana.prs@gmail.com>
Date: Thu, 23 May 2019 16:48:05 +0545
Subject: [PATCH 060/131] Acceptance test for searching names of files and
 folders containing  emoji

---
 .../apiWebdavOperations/search.feature        | 33 +++++++++++++++++--
 1 file changed, 30 insertions(+), 3 deletions(-)

diff --git a/tests/acceptance/features/apiWebdavOperations/search.feature b/tests/acceptance/features/apiWebdavOperations/search.feature
index cc9f02c609cf..1e8ebe54ce13 100644
--- a/tests/acceptance/features/apiWebdavOperations/search.feature
+++ b/tests/acceptance/features/apiWebdavOperations/search.feature
@@ -9,6 +9,7 @@ Feature: Search
     And user "user0" has created folder "/just-a-folder"
     And user "user0" has created folder "/फनी näme"
     And user "user0" has created folder "/upload folder"
+    And user "user0" has created folder "/upload😀 😁"
     And user "user0" has uploaded file with content "does-not-matter" to "/upload.txt"
     And user "user0" has uploaded file with content "does-not-matter" to "/a-image.png"
     And user "user0" has uploaded file with content "does-not-matter" to "/just-a-folder/upload.txt"
@@ -17,6 +18,7 @@ Feature: Search
     And user "user0" has uploaded file with content "does-not-matter" to "/just-a-folder/uploadÜठिF.txt"
     And user "user0" has uploaded file with content "does-not-matter" to "/फनी näme/upload.txt"
     And user "user0" has uploaded file with content "does-not-matter" to "/फनी näme/a-image.png"
+    And user "user0" has uploaded file with content "does-not-matter" to "/upload😀 😁/upload😀 😁.txt"
 
   @smokeTest
   Scenario Outline: search for entry by pattern
@@ -29,8 +31,10 @@ Feature: Search
       | /upload folder                |
       | /just-a-folder/uploadÜठिF.txt |
       | /फनी näme/upload.txt          |
+      | /upload😀 😁                  |
+      | /upload😀 😁/upload😀 😁.txt  |
     But the search result should not contain these entries:
-      | /a-image.png |
+      | /a-image.png             |
     Examples:
       | dav_version |
       | old         |
@@ -87,6 +91,8 @@ Feature: Search
       | /upload folder                |
       | /upload.txt                   |
       | /फनी näme/upload.txt          |
+      | /upload😀 😁                  |
+      | /upload😀 😁/upload😀 😁.txt  |
     Examples:
       | dav_version |
       | old         |
@@ -113,13 +119,15 @@ Feature: Search
     Given using <dav_version> DAV path
     When user "user0" searches for "upload" and limits the results to "100" items using the WebDAV API
     Then the HTTP status code should be "207"
-    And the search result should contain "5" entries
+    And the search result should contain "7" entries
     And the search result should contain these entries:
       | /upload.txt                   |
       | /just-a-folder/upload.txt     |
       | /upload folder                |
       | /just-a-folder/uploadÜठिF.txt |
       | /फनी näme/upload.txt          |
+      | /upload😀 😁                  |
+      | /upload😀 😁/upload😀 😁.txt  |
     Examples:
       | dav_version |
       | old         |
@@ -178,4 +186,23 @@ Feature: Search
     Examples:
       | dav_version |
       | old         |
-      | new         |
\ No newline at end of file
+      | new         |
+
+  Scenario Outline: search for entry with emoji by pattern
+    Given using <dav_version> DAV path
+    When user "user0" searches for "😀 😁" using the WebDAV API
+    Then the HTTP status code should be "207"
+    And the search result should contain these entries:
+      | /upload😀 😁                 |
+      | /upload😀 😁/upload😀 😁.txt |
+    But the search result should not contain these entries:
+      | /a-image.png                  |
+      | /upload.txt                   |
+      | /just-a-folder/upload.txt     |
+      | /upload folder                |
+      | /just-a-folder/uploadÜठिF.txt |
+      | /फनी näme/upload.txt          |
+    Examples:
+      | dav_version |
+      | old         |
+      | new         |

From 443f2b42f6820a6e18789e7a910402753e2f9ea7 Mon Sep 17 00:00:00 2001
From: Artur Neumann <artur@jankaritech.com>
Date: Tue, 21 May 2019 15:25:08 +0545
Subject: [PATCH 061/131] sharing autocomplete medial search tests for groups
 and accounts

---
 tests/acceptance/config/behat.yml             |   1 +
 .../features/bootstrap/OccContext.php         |   1 +
 .../bootstrap/WebUISharingContext.php         |  17 ++
 .../shareAutocompletion.feature               | 201 +++++++++++++++++-
 4 files changed, 216 insertions(+), 4 deletions(-)

diff --git a/tests/acceptance/config/behat.yml b/tests/acceptance/config/behat.yml
index c2e35959222f..40f37d4c680d 100644
--- a/tests/acceptance/config/behat.yml
+++ b/tests/acceptance/config/behat.yml
@@ -433,6 +433,7 @@ default:
         - EmailContext:
         - WebUIAdminSharingSettingsContext:
         - WebUIPersonalSharingSettingsContext:
+        - OccContext:
 
     webUISharingNotifications:
       paths:
diff --git a/tests/acceptance/features/bootstrap/OccContext.php b/tests/acceptance/features/bootstrap/OccContext.php
index 7987eab2edbd..8f5a4f30c0d4 100644
--- a/tests/acceptance/features/bootstrap/OccContext.php
+++ b/tests/acceptance/features/bootstrap/OccContext.php
@@ -554,6 +554,7 @@ public function theAdministratorDeletesConfigKeyOfAppUsingTheOccCommand($key, $a
 
 	/**
 	 * @Given the administrator has added system config key :key with value :value
+	 * @Given the administrator has added system config key :key with value :value and type :type
 	 * @When the administrator adds/updates system config key :key with value :value using the occ command
 	 * @When the administrator adds/updates system config key :key with value :value and type :type using the occ command
 	 *
diff --git a/tests/acceptance/features/bootstrap/WebUISharingContext.php b/tests/acceptance/features/bootstrap/WebUISharingContext.php
index 96eedde593a9..dfe779def359 100644
--- a/tests/acceptance/features/bootstrap/WebUISharingContext.php
+++ b/tests/acceptance/features/bootstrap/WebUISharingContext.php
@@ -981,6 +981,23 @@ public function userShouldNotBeListedInTheAutocompleteListOnTheWebui($username)
 		}
 	}
 
+	/**
+	 * @Then group :groupName should not be listed in the autocomplete list on the webUI
+	 *
+	 * @param string $groupName
+	 *
+	 * @return void
+	 */
+	public function groupShouldNotBeListedInTheAutocompleteListOnTheWebui($groupName) {
+		$names = $this->sharingDialog->getAutocompleteItemsList();
+		$groupName = $this->sharingDialog->groupStringsToMatchAutoComplete($groupName);
+		PHPUnit\Framework\Assert::assertNotContains(
+			$groupName,
+			$names,
+			"$groupName found in autocomplete list but not expected"
+		);
+	}
+
 	/**
 	 * @Then a tooltip with the text :text should be shown near the share-with-field on the webUI
 	 *
diff --git a/tests/acceptance/features/webUISharingInternalUsers/shareAutocompletion.feature b/tests/acceptance/features/webUISharingInternalUsers/shareAutocompletion.feature
index f34c39605569..3d30e0e05bea 100644
--- a/tests/acceptance/features/webUISharingInternalUsers/shareAutocompletion.feature
+++ b/tests/acceptance/features/webUISharingInternalUsers/shareAutocompletion.feature
@@ -17,8 +17,8 @@ Feature: Autocompletion of share-with names
       | username  | password  | displayname     | email          |
       | two       | %regular% | User Two        | u2@oc.com.np   |
       | u444      | %regular% | Four            | u3@oc.com.np   |
-      | five      | %regular% | User Group      | five@oc.com.np |
-      | usersmith | %regular% | John Finn Smith | js@oc.com.np   |
+      | five      | %regular% | User Group      | five@oc.net.np |
+      | usersmith | %regular% | John Finn Smith | js@oc.com.de   |
     And these groups have been created:
       | groupname     |
       | finance1      |
@@ -158,7 +158,7 @@ Feature: Autocompletion of share-with names
     And user "Four" should not be listed in the autocomplete list on the webUI
 
   @skipOnLDAP
-  Scenario: autocompletion of a pattern where the name of existing users contain the pattern somewhere in the middle
+  Scenario: autocompletion of a pattern where the name of existing users contains the pattern somewhere in the middle
     Given user "user1" has logged in using the webUI
     And the user has browsed to the files page
     And the user has opened the share dialog for folder "simple-folder"
@@ -168,7 +168,7 @@ Feature: Autocompletion of share-with names
     And user "Four" should not be listed in the autocomplete list on the webUI
 
   @skipOnLDAP
-  Scenario: autocompletion of a pattern where the name of existing users contain the pattern at the end
+  Scenario: autocompletion of a pattern where the name of existing users contains the pattern at the end
     Given user "usergrp" has logged in using the webUI
     And the user has browsed to the files page
     And the user has opened the share dialog for folder "simple-folder"
@@ -177,6 +177,199 @@ Feature: Autocompletion of share-with names
     And the users own name should not be listed in the autocomplete list on the webUI
     And user "User One" should not be listed in the autocomplete list on the webUI
 
+  @skipOnLDAP
+  Scenario: autocompletion of a pattern where the username of existing user contains the pattern somewhere in the middle
+    Given user "ivan" has been created with default attributes
+    And user "user1" has logged in using the webUI
+    And the user has browsed to the files page
+    And the user has opened the share dialog for folder "simple-folder"
+    When the user types "iv" in the share-with-field
+    Then all users and groups that contain the string "iv" in their name should be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: autocompletion of a pattern where the name of existing group contains the pattern somewhere in the middle
+    Given user "user1" has logged in using the webUI
+    And the user has browsed to the files page
+    And the user has opened the share dialog for folder "simple-folder"
+    When the user types "anc" in the share-with-field
+    Then all users and groups that contain the string "finance" in their name should be listed in the autocomplete list on the webUI
+    But group "other" should not be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: autocompletion of a pattern where the username of the existing user contains the pattern somewhere in the end
+    Given these users have been created with default attributes but not initialized:
+      | username     | displayname   |
+      | regularuser3 | Guest User |
+    And user "user1" has logged in using the webUI
+    And the user has browsed to the files page
+    And the user has opened the share dialog for folder "simple-folder"
+    When the user types "user3" in the share-with-field
+    Then all users and groups that contain the string "user3" in their name should be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: autocompletion of a pattern where the name of existing group contains the pattern at the end
+    Given user "user1" has logged in using the webUI
+    And the user has browsed to the files page
+    And the user has opened the share dialog for folder "simple-folder"
+    When the user types "ce2" in the share-with-field
+    Then all users and groups that contain the string "ce2" in their name should be listed in the autocomplete list on the webUI
+    But group "finance1" should not be listed in the autocomplete list on the webUI
+    And group "finance3" should not be listed in the autocomplete list on the webUI
+    And group "users-finance" should not be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: autocompletion of a pattern where the name of existing user contains the pattern somewhere in the middle
+    Given user "user1" has logged in using the webUI
+    And the user has browsed to the files page
+    And the user has opened the share dialog for folder "simple-folder"
+    When the user types "finn" in the share-with-field
+    Then only "John Finn Smith" should be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: autocompletion of a pattern where the name of existing user contains the pattern somewhere at the end
+    Given user "user1" has logged in using the webUI
+    And the user has browsed to the files page
+    And the user has opened the share dialog for folder "simple-folder"
+    When the user types "group" in the share-with-field
+    Then only "User Group" should be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: autocompletion of a pattern where the email of the existing user contains the pattern somewhere at the beginning
+    Given user "user1" has logged in using the webUI
+    And the user has browsed to the files page
+    And the user has opened the share dialog for folder "simple-folder"
+    When the user types "u2" in the share-with-field
+    Then only "User Two" should be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: autocompletion of a pattern where the email of the existing user contains the pattern somewhere at the middle
+    Given user "user1" has logged in using the webUI
+    And the user has browsed to the files page
+    And the user has opened the share dialog for folder "simple-folder"
+    When the user types "net" in the share-with-field
+    Then only "User Group" should be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: autocompletion of a pattern where the email of the existing user contains the pattern somewhere at the end
+    Given user "user1" has logged in using the webUI
+    And the user has browsed to the files page
+    And the user has opened the share dialog for folder "simple-folder"
+    When the user types "de" in the share-with-field
+    Then only "John Finn Smith" should be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: autocompletion of a pattern where the name of existing group contains the pattern somewhere in the middle but group medial search is disabled
+    Given these groups have been created:
+      | groupname |
+      | nanumber  |
+    And user "user1" has logged in using the webUI
+    And the administrator has added system config key "groups.enable_medial_search" with value "false" and type "boolean"
+    And the user has browsed to the files page
+    And the user has opened the share dialog for folder "simple-folder"
+    When the user types "nan" in the share-with-field
+    Then all users and groups that contain the string "nanumber" in their name should be listed in the autocomplete list on the webUI
+    But group "finance1" should not be listed in the autocomplete list on the webUI
+    And group "finance2" should not be listed in the autocomplete list on the webUI
+    And group "users-finance" should not be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: autocompletion of a pattern where the name of existing group contains the pattern somewhere in the end but group medial search is disabled
+    Given these groups have been created:
+      | groupname         |
+      | ncell-customers   |
+      | customers-finance |
+    And user "user1" has logged in using the webUI
+    And the administrator has added system config key "groups.enable_medial_search" with value "false" and type "boolean"
+    And the user has browsed to the files page
+    And the user has opened the share dialog for folder "simple-folder"
+    When the user types "customers" in the share-with-field
+    Then all users and groups that contain the string "customers-finance" in their name should be listed in the autocomplete list on the webUI
+    And group "ncell-customers" should not be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: autocompletion of a pattern where the user name contains the pattern somewhere in the middle but accounts medial search is disabled
+    Given these users have been created with default attributes but not initialized:
+      | username | displayname |
+      | ivan     | Ivan         |
+    And user "user1" has logged in using the webUI
+    And the administrator has added system config key "accounts.enable_medial_search" with value "false" and type "boolean"
+    And the user has browsed to the files page
+    And the user has opened the share dialog for folder "simple-folder"
+    When the user types "iv" in the share-with-field
+    Then only "Ivan" should be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: autocompletion of a pattern where the user name contains the pattern somewhere in the end but accounts medial search is disabled
+    Given these users have been created with default attributes but not initialized:
+      | username     | displayname   |
+      | regularuser3 | Guest User |
+    And user "user1" has logged in using the webUI
+    And the administrator has added system config key "accounts.enable_medial_search" with value "false" and type "boolean"
+    And the user has browsed to the files page
+    And the user has opened the share dialog for folder "simple-folder"
+    When the user types "user3" in the share-with-field
+    Then only "User Three" should be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: autocompletion of a pattern where the name of existing user contains the pattern somewhere in the middle but accounts medial search is disabled
+    Given these users have been created with default attributes but not initialized:
+      | username | displayname   |
+      | user2    | finnance typo |
+    And user "user1" has logged in using the webUI
+    And the user has browsed to the files page
+    And the administrator has added system config key "accounts.enable_medial_search" with value "false" and type "boolean"
+    And the user has opened the share dialog for folder "simple-folder"
+    When the user types "finn" in the share-with-field
+    Then only "finnance typo" should be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: autocompletion of a pattern where the display name of existing user contains the pattern somewhere in the end but accounts medial search is disabled
+    Given these users have been created with default attributes but not initialized:
+      | username | displayname   |
+      | user2    | Group User |
+    And user "user1" has logged in using the webUI
+    And the administrator has added system config key "accounts.enable_medial_search" with value "false" and type "boolean"
+    And the user has browsed to the files page
+    And the user has opened the share dialog for folder "simple-folder"
+    When the user types "group" in the share-with-field
+    Then only "Group User" should be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: autocompletion of a pattern where the email of the existing user contains the pattern somewhere at the beginning but accounts medial search is disabled
+    Given these users have been created with default attributes but not initialized:
+      | username | displayname | email              |
+      | user2    | User2       | hello2u2@oc.com.np |
+    And user "user1" has logged in using the webUI
+    And the administrator has added system config key "accounts.enable_medial_search" with value "false" and type "boolean"
+    And the user has browsed to the files page
+    And the user has opened the share dialog for folder "simple-folder"
+    When the user types "u2" in the share-with-field
+    Then only "User Two" should be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: autocompletion of a pattern where the email of the existing user contains the pattern somewhere at the middle but accounts medial search is disabled
+    Given these users have been created with default attributes but not initialized:
+      | username | displayname | email              |
+      | user2    | User2       | net@oc.com.np |
+    And user "user1" has logged in using the webUI
+    And the administrator has added system config key "accounts.enable_medial_search" with value "false" and type "boolean"
+    And the user has browsed to the files page
+    And the user has opened the share dialog for folder "simple-folder"
+    When the user types "net" in the share-with-field
+    Then only "User2" should be listed in the autocomplete list on the webUI
+
+  @skipOnLDAP
+  Scenario: autocompletion of a pattern where the email of the existing user contains the pattern somewhere at the end but accounts medial search is disabled
+    Given these users have been created with default attributes but not initialized:
+      | username | displayname | email        |
+      | user2    | User2       | de@oc.com.np |
+    And user "user1" has logged in using the webUI
+    And the administrator has added system config key "accounts.enable_medial_search" with value "false" and type "boolean"
+    And the user has browsed to the files page
+    And the user has opened the share dialog for folder "simple-folder"
+    When the user types "de" in the share-with-field
+    Then only "User2" should be listed in the autocomplete list on the webUI
+
   @skipOnLDAP
   Scenario: allow user to disable autocomplete in sharing dialog
     Given user "regularuser" has logged in using the webUI

From c996fd4be00a2ba6dc8b593648a631ac7e20a827 Mon Sep 17 00:00:00 2001
From: Dipak Acharya <dpakach@gmail.com>
Date: Thu, 30 May 2019 12:10:29 +0545
Subject: [PATCH 062/131] Add acceptance test for checking file access after
 recreating master key in encryption

---
 .drone.yml                                    | 14 ++++++++++
 tests/acceptance/config/behat.yml             | 14 ++++++++++
 .../webUIMasterKeys.feature                   | 28 +++++++++++++++++++
 3 files changed, 56 insertions(+)
 create mode 100644 tests/acceptance/features/webUIMasterKeyType/webUIMasterKeys.feature

diff --git a/.drone.yml b/.drone.yml
index cc2fa841cd0c..08f4aeca5b10 100644
--- a/.drone.yml
+++ b/.drone.yml
@@ -1581,3 +1581,17 @@ matrix:
       CONFIGURE_ENCRYPTION: true
       ENCRYPTION_TYPE: masterkey
       INSTALL_TESTING_APP: true
+
+    ## encryption WebUI acceptance tests master-keys encryption
+    - PHP_VERSION: 7.1
+      TEST_SUITE: webui
+      BEHAT_SUITE: webUIMasterKeyType
+      DB_TYPE: mariadb
+      USE_SERVER: true
+      SERVER_PROTOCOL: https
+      INSTALL_SERVER: true
+      CHOWN_SERVER: true
+      OWNCLOUD_LOG: true
+      CONFIGURE_ENCRYPTION: true
+      ENCRYPTION_TYPE: masterkey
+      INSTALL_TESTING_APP: true
\ No newline at end of file
diff --git a/tests/acceptance/config/behat.yml b/tests/acceptance/config/behat.yml
index 40f37d4c680d..fec938484d7e 100644
--- a/tests/acceptance/config/behat.yml
+++ b/tests/acceptance/config/behat.yml
@@ -327,6 +327,20 @@ default:
         - WebUILoginContext:
         - WebUIPersonalGeneralSettingsContext:
 
+    # This suite is part of the encryption app in later core versions
+    webUIMasterKeyType:
+      paths:
+        - '%paths.base%/../features/webUIMasterKeyType'
+      contexts:
+        - EncryptionContext:
+        - WebUIAdminEncryptionSettingsContext:
+        - WebUIPersonalEncryptionSettingsContext:
+        - WebUIGeneralContext:
+        - WebUILoginContext:
+        - WebUIFilesContext:
+        - FeatureContext: *common_feature_context_params
+        - OccContext:
+
     webUIMoveFilesFolders:
       paths:
         - '%paths.base%/../features/webUIMoveFilesFolders'
diff --git a/tests/acceptance/features/webUIMasterKeyType/webUIMasterKeys.feature b/tests/acceptance/features/webUIMasterKeyType/webUIMasterKeys.feature
new file mode 100644
index 000000000000..519c5e652b91
--- /dev/null
+++ b/tests/acceptance/features/webUIMasterKeyType/webUIMasterKeys.feature
@@ -0,0 +1,28 @@
+@webUI @skipOnEncryptionType:user-keys @skipOnStorage:ceph
+Feature: encrypt files using master keys
+  As an admin
+  I want to be able to encrypt user files using master keys
+  So that I can use a common key to encrypt files of all user
+
+  Scenario: user cannot access their file after recreating master key with re-login
+    Given user "user0" has been created with default attributes
+    And the administrator has set the encryption type to "masterkey"
+    And user "user0" has uploaded file "filesForUpload/textfile.txt" to "/somefile.txt"
+    And user "user0" has logged in using the webUI
+    When the administrator successfully recreates the encryption masterkey using the occ command
+    Then the command output should contain the text 'Note: All users are required to relogin.'
+    When the user opens file "lorem.txt" expecting to fail using the webUI
+    Then the user should be redirected to the general exception webUI page with the title "%productname%"
+    And the title of the exception on general exception webUI page should be "Forbidden"
+    And a message should be displayed on the general exception webUI page containing "Encryption not ready"
+
+  Scenario: user can access their file after recreating master key with re-login
+    Given user "user0" has been created with default attributes
+    And the administrator has set the encryption type to "masterkey"
+    And user "user0" has uploaded file "filesForUpload/textfile.txt" to "/somefile.txt"
+    And user "user0" has logged in using the webUI
+    When the administrator successfully recreates the encryption masterkey using the occ command
+    And the user re-logs in as "user0" using the webUI
+    And the user opens file "lorem.txt" using the webUI
+    Then no dialog should be displayed on the webUI
+    And the user should be redirected to a webUI page with the title "Files - %productname%"
\ No newline at end of file

From eb58c686fda0451f5fe4870a70ab4cda9b4746f9 Mon Sep 17 00:00:00 2001
From: Saugat Pachhai <suagatchhetri@outlook.com>
Date: Mon, 20 May 2019 17:11:59 +0545
Subject: [PATCH 063/131] Add acceptance test flags in makefile for
 autocompletion

---
 Makefile | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Makefile b/Makefile
index 13fee863c1c0..b9f742d4adf1 100644
--- a/Makefile
+++ b/Makefile
@@ -56,6 +56,14 @@ TEST_DATABASE=sqlite
 TEST_EXTERNAL_ENV=smb-silvershell
 TEST_PHP_SUITE=
 
+# Acceptance test flags (for shells supporting autocompletion of makefiles, eg: zsh)
+TEST_SERVER_URL?=
+TEST_SERVER_FED_URL?=
+TEST_EXTERNAL_USER_BACKENDS?=
+BEHAT_FEATURE?=
+NORERUN?=
+BEHAT_RERUN_TIMES?=
+
 RELEASE_CHANNEL=git
 
 # internal aliases

From 449c19addd3735cd3cd82f24f0d2e8afee14e068 Mon Sep 17 00:00:00 2001
From: paurakhsharma <paurakh011@gmail.com>
Date: Wed, 29 May 2019 14:52:38 +0545
Subject: [PATCH 064/131] webUISharingInternalUsers/user no skeleton file steps

---
 .../features/bootstrap/Provisioning.php       |  57 +++++++++-
 .../shareAutocompletion.feature               |  15 +--
 .../shareWithUsers.feature                    | 100 +++++++++++++-----
 3 files changed, 137 insertions(+), 35 deletions(-)

diff --git a/tests/acceptance/features/bootstrap/Provisioning.php b/tests/acceptance/features/bootstrap/Provisioning.php
index 511d6e4b0203..f0d08232cece 100644
--- a/tests/acceptance/features/bootstrap/Provisioning.php
+++ b/tests/acceptance/features/bootstrap/Provisioning.php
@@ -279,9 +279,7 @@ public function userHasBeenCreatedWithDefaultAttributes($user) {
 	 * @return void
 	 */
 	public function userHasBeenCreatedWithDefaultAttributesAndWithoutSkeletonFiles($user) {
-		$this->runOcc(["config:system:get skeletondirectory"]);
-		$path = \trim($this->getStdOutOfOccCommand());
-		$this->runOcc(["config:system:delete skeletondirectory"]);
+		$path = $this->popSkeletonDirectoryConfig();
 		try {
 			$this->userHasBeenCreatedWithDefaultAttributes($user);
 		} finally {
@@ -290,6 +288,47 @@ public function userHasBeenCreatedWithDefaultAttributesAndWithoutSkeletonFiles($
 		}
 	}
 
+	/**
+	 * @Given these users have been created with default attributes and without skeleton files:
+	 * expects a table of users with the heading
+	 * "|username|"
+	 *
+	 * @param TableNode $table
+	 *
+	 * @return void
+	 */
+	public function theseUsersHaveBeenCreatedWithDefaultAttributesAndWithoutSkeletonFiles(TableNode $table) {
+		$path = $this->popSkeletonDirectoryConfig();
+		try {
+			foreach ($table as $row) {
+				$this->userHasBeenCreatedWithDefaultAttributes($row['username']);
+			}
+		} finally {
+			// restore skeletondirectory even if user creation failed
+			$this->runOcc(["config:system:set skeletondirectory --value $path"]);
+		}
+	}
+
+	/**
+	 * @Given these users have been created without skeleton files:
+	 * expects a table of users with the heading
+	 * "|username|password|displayname|email|"
+	 * password, displayname & email are optional
+	 *
+	 * @param TableNode $table
+	 *
+	 * @return void
+	 */
+	public function theseUsersHaveBeenCreatedWithoutSkeletonFiles(TableNode $table) {
+		$path = $this->popSkeletonDirectoryConfig();
+		try {
+			$this->theseUsersHaveBeenCreated("", "", $table);
+		} finally {
+			// restore skeletondirectory even if user creation failed
+			$this->runOcc(["config:system:set skeletondirectory --value $path"]);
+		}
+	}
+
 	/**
 	 * @Given /^these users have been created\s?(with default attributes|)\s?(but not initialized|):$/
 	 * expects a table of users with the heading
@@ -2898,4 +2937,16 @@ public function getDisabledApps() {
 		);
 		return ($this->getArrayOfAppsResponded($this->response));
 	}
+
+	/**
+	 * Removes skeleton directory config from config.php and returns the config value
+	 *
+	 * @return string
+	 */
+	public function popSkeletonDirectoryConfig() {
+		$this->runOcc(["config:system:get skeletondirectory"]);
+		$path = \trim($this->getStdOutOfOccCommand());
+		$this->runOcc(["config:system:delete skeletondirectory"]);
+		return $path;
+	}
 }
diff --git a/tests/acceptance/features/webUISharingInternalUsers/shareAutocompletion.feature b/tests/acceptance/features/webUISharingInternalUsers/shareAutocompletion.feature
index 3d30e0e05bea..6b732727a72a 100644
--- a/tests/acceptance/features/webUISharingInternalUsers/shareAutocompletion.feature
+++ b/tests/acceptance/features/webUISharingInternalUsers/shareAutocompletion.feature
@@ -9,11 +9,14 @@ Feature: Autocompletion of share-with names
     Given these users have been created with default attributes but not initialized:
       | username    |
       | user1       |
-      | user3       |
-      | usergrp     |
       | regularuser |
-    # Some extra users to make the share autocompletion interesting
-    Given these users have been created but not initialized:
+    # Users that are in the special known users already without skeleton files
+    And these users have been created with default attributes and without skeleton files:
+      | username |
+      | user3    |
+      | usergrp  |
+    # Some extra users without skeleton files to make the share autocompletion interesting
+    And these users have been created without skeleton files:
       | username  | password  | displayname     | email          |
       | two       | %regular% | User Two        | u2@oc.com.np   |
       | u444      | %regular% | Four            | u3@oc.com.np   |
@@ -168,8 +171,8 @@ Feature: Autocompletion of share-with names
     And user "Four" should not be listed in the autocomplete list on the webUI
 
   @skipOnLDAP
-  Scenario: autocompletion of a pattern where the name of existing users contains the pattern at the end
-    Given user "usergrp" has logged in using the webUI
+  Scenario: autocompletion of a pattern where the name of existing users contain the pattern at the end
+    Given user "regularuser" has logged in using the webUI
     And the user has browsed to the files page
     And the user has opened the share dialog for folder "simple-folder"
     When the user types "r3" in the share-with-field
diff --git a/tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature b/tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature
index be452e56294a..65c036facd97 100644
--- a/tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature
+++ b/tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature
@@ -4,16 +4,15 @@ Feature: Sharing files and folders with internal users
   I want to share files and folders with other users
   So that those users can access the files and folders
 
-  Background:
-    Given these users have been created with default attributes:
-      | username |
-      | user1    |
-      | user2    |
 
   @TestAlsoOnExternalUserBackend
   @smokeTest
   Scenario: share a file & folder with another internal user
-    Given user "user2" has logged in using the webUI
+    Given these users have been created with default attributes:
+      | username |
+      | user1    |
+      | user2    |
+    And user "user2" has logged in using the webUI
     When the user shares folder "simple-folder" with user "User One" using the webUI
     And the user shares file "testimage.jpg" with user "User One" using the webUI
     And the user re-logs in as "user1" using the webUI
@@ -27,7 +26,9 @@ Feature: Sharing files and folders with internal users
 
   @TestAlsoOnExternalUserBackend @skipOnFIREFOX
   Scenario: share a file with another internal user who overwrites and unshares the file
-    Given user "user2" has logged in using the webUI
+    Given user "user1" has been created with default attributes and without skeleton files
+    And user "user2" has been created with default attributes
+    And user "user2" has logged in using the webUI
     When the user renames file "lorem.txt" to "new-lorem.txt" using the webUI
     And the user shares file "new-lorem.txt" with user "User One" using the webUI
     And the user re-logs in as "user1" using the webUI
@@ -45,7 +46,9 @@ Feature: Sharing files and folders with internal users
 
   @TestAlsoOnExternalUserBackend
   Scenario: share a folder with another internal user who uploads, overwrites and deletes files
-    Given user "user2" has logged in using the webUI
+    Given user "user1" has been created with default attributes and without skeleton files
+    And user "user2" has been created with default attributes
+    And user "user2" has logged in using the webUI
     When the user renames folder "simple-folder" to "new-simple-folder" using the webUI
     And the user shares folder "new-simple-folder" with user "User One" using the webUI
     And the user re-logs in as "user1" using the webUI
@@ -72,7 +75,9 @@ Feature: Sharing files and folders with internal users
 
   @TestAlsoOnExternalUserBackend
   Scenario: share a folder with another internal user who unshares the folder
-    Given user "user2" has logged in using the webUI
+    Given user "user1" has been created with default attributes and without skeleton files
+    And user "user2" has been created with default attributes
+    And user "user2" has logged in using the webUI
     When the user renames folder "simple-folder" to "new-simple-folder" using the webUI
     And the user shares folder "new-simple-folder" with user "User One" using the webUI
 		# unshare the received shared folder and check it is gone
@@ -88,7 +93,11 @@ Feature: Sharing files and folders with internal users
 
   @skipOnMICROSOFTEDGE @TestAlsoOnExternalUserBackend
   Scenario: share a folder with another internal user and prohibit deleting
-    Given user "user2" has logged in using the webUI
+    Given these users have been created with default attributes:
+      | username |
+      | user1    |
+      | user2    |
+    And user "user2" has logged in using the webUI
     When the user shares folder "simple-folder" with user "User One" using the webUI
     And the user sets the sharing permissions of "User One" for "simple-folder" using the webUI to
       | delete | no |
@@ -98,7 +107,9 @@ Feature: Sharing files and folders with internal users
 
   @skipOnFIREFOX
   Scenario: share a folder with other user and then it should be listed on Shared with You for other user
-    Given user "user2" has logged in using the webUI
+    Given user "user1" has been created with default attributes and without skeleton files
+    And user "user2" has been created with default attributes
+    And user "user2" has logged in using the webUI
     And the user has renamed folder "simple-folder" to "new-simple-folder" using the webUI
     And the user has renamed file "lorem.txt" to "ipsum.txt" using the webUI
     And the user has shared file "ipsum.txt" with user "User One" using the webUI
@@ -109,7 +120,9 @@ Feature: Sharing files and folders with internal users
     And folder "new-simple-folder" should be listed on the webUI
 
   Scenario: share a folder with other user and then it should be listed on Shared with Others page
-    Given user "user2" has logged in using the webUI
+    Given user "user1" has been created with default attributes and without skeleton files
+    And user "user2" has been created with default attributes
+    And user "user2" has logged in using the webUI
     And the user has shared file "lorem.txt" with user "User One" using the webUI
     And the user has shared folder "simple-folder" with user "User One" using the webUI
     When the user browses to the shared-with-others page
@@ -117,7 +130,9 @@ Feature: Sharing files and folders with internal users
     And folder "simple-folder" should be listed on the webUI
 
   Scenario: share two file with same name but different paths
-    Given user "user2" has logged in using the webUI
+    Given user "user1" has been created with default attributes and without skeleton files
+    And user "user2" has been created with default attributes
+    And user "user2" has logged in using the webUI
     And the user has shared file "lorem.txt" with user "User One" using the webUI
     When the user opens folder "simple-folder" using the webUI
     And the user shares file "lorem.txt" with user "User One" using the webUI
@@ -127,17 +142,25 @@ Feature: Sharing files and folders with internal users
 
   Scenario: user tries to share a file from a group which is blacklisted from sharing
     Given group "grp1" has been created
+    And these users have been created with default attributes and without skeleton files:
+      | username |
+      | user1    |
+      | user3    |
+    And user "user2" has been created with default attributes
     And user "user1" has been added to group "grp1"
-    And user "user3" has been created with default attributes
     And the administrator has browsed to the admin sharing settings page
     When the administrator enables exclude groups from sharing using the webUI
     And the administrator adds group "grp1" to the group sharing blacklist using the webUI
     Then user "user1" should not be able to share file "testimage.jpg" with user "user3" using the sharing API
 
   Scenario: user tries to share a folder from a group which is blacklisted from sharing
-    Given group "grp1" has been created
+    Given these users have been created with default attributes and without skeleton files:
+      | username |
+      | user1    |
+      | user3    |
+    And user "user2" has been created with default attributes
+    And group "grp1" has been created
     And user "user1" has been added to group "grp1"
-    And user "user3" has been created with default attributes
     And the administrator has browsed to the admin sharing settings page
     When the administrator enables exclude groups from sharing using the webUI
     And the administrator adds group "grp1" to the group sharing blacklist using the webUI
@@ -146,7 +169,11 @@ Feature: Sharing files and folders with internal users
   Scenario: member of a blacklisted from sharing group tries to re-share a file received as a share
     Given these users have been created with default attributes:
       | username |
+      | user1    |
       | user3    |
+    And these users have been created with default attributes and without skeleton files:
+      | username |
+      | user2    |
       | user4    |
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
@@ -157,8 +184,10 @@ Feature: Sharing files and folders with internal users
     Then user "user1" should not be able to share file "/testimage (2).jpg" with user "User Four" using the sharing API
 
   Scenario: member of a blacklisted from sharing group tries to re-share a folder received as a share
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and without skeleton files:
       | username |
+      | user1    |
+      | user2    |
       | user3    |
       | user4    |
     And group "grp1" has been created
@@ -171,10 +200,12 @@ Feature: Sharing files and folders with internal users
     Then user "user1" should not be able to share folder "/common" with user "User Four" using the sharing API
 
   Scenario: member of a blacklisted from sharing group tries to re-share a file inside a folder received as a share
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and without skeleton files:
       | username |
-      | user3    |
+      | user1    |
+      | user2    |
       | user4    |
+    And user "user3" has been created with default attributes
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
     And the administrator has browsed to the admin sharing settings page
@@ -186,8 +217,10 @@ Feature: Sharing files and folders with internal users
     Then user "user1" should not be able to share file "/common/testimage.jpg" with user "User Four" using the sharing API
 
   Scenario: member of a blacklisted from sharing group tries to re-share a folder inside a folder received as a share
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and without skeleton files:
       | username |
+      | user1    |
+      | user2    |
       | user3    |
       | user4    |
     And the administrator has browsed to the admin sharing settings page
@@ -200,8 +233,8 @@ Feature: Sharing files and folders with internal users
 
   Scenario: user tries to share a file from a group which is blacklisted from sharing using webUI from files page
     Given group "grp1" has been created
+    And user "user1" has been created with default attributes
     And user "user1" has been added to group "grp1"
-    And user "user3" has been created with default attributes
     And the administrator has browsed to the admin sharing settings page
     And the administrator has enabled exclude groups from sharing from the admin sharing settings page
     When the administrator adds group "grp1" to the group sharing blacklist using the webUI
@@ -212,8 +245,12 @@ Feature: Sharing files and folders with internal users
 
   Scenario: user tries to re-share a file from a group which is blacklisted from sharing using webUI from shared with you page
     Given group "grp1" has been created
+    And these users have been created with default attributes:
+      | username |
+      | user1    |
+      | user2    |
     And user "user1" has been added to group "grp1"
-    And user "user3" has been created with default attributes
+    And user "user3" has been created with default attributes and without skeleton files
     And user "user2" has shared file "/testimage.jpg" with user "user1"
     And the administrator has browsed to the admin sharing settings page
     And the administrator has enabled exclude groups from sharing from the admin sharing settings page
@@ -226,7 +263,11 @@ Feature: Sharing files and folders with internal users
     And user "user1" should not be able to share file "testimage (2).jpg" with user "User Three" using the sharing API
 
   Scenario: user shares the file/folder with another internal user and delete the share with user
-    Given user "user1" has logged in using the webUI
+    Given these users have been created with default attributes:
+      | username |
+      | user1    |
+      | user2    |
+    And user "user1" has logged in using the webUI
     And user "user1" has shared file "lorem.txt" with user "user2"
     When the user opens the share dialog for file "lorem.txt"
     And the user deletes share with user "User Two" for the current file
@@ -238,6 +279,8 @@ Feature: Sharing files and folders with internal users
   @mailhog
   Scenario: user should be able to send notification by email when allow share mail notification has been enabled
     Given parameter "shareapi_allow_mail_notification" of app "core" has been set to "yes"
+    And user "user1" has been created with default attributes
+    And user "user2" has been created with default attributes and without skeleton files
     And user "user1" has logged in using the webUI
     And user "user1" has shared file "lorem.txt" with user "user2"
     And the user has opened the share dialog for file "lorem.txt"
@@ -251,9 +294,10 @@ Feature: Sharing files and folders with internal users
   @mailhog
   Scenario: user should get and error message when trying to send notification by email to a user who has not setup their email
     Given parameter "shareapi_allow_mail_notification" of app "core" has been set to "yes"
-    And these users have been created:
-      |username|password|
-      |user0   |1234    |
+    And user "user1" has been created with default attributes
+    And these users have been created without skeleton files:
+      | username | password |
+      | user0    | 1234     |
     And user "user1" has logged in using the webUI
     And user "user1" has shared file "lorem.txt" with user "user0"
     And the user has opened the share dialog for file "lorem.txt"
@@ -265,6 +309,8 @@ Feature: Sharing files and folders with internal users
   @mailhog
   Scenario: user should not be able to send notification by email more than once
     Given parameter "shareapi_allow_mail_notification" of app "core" has been set to "yes"
+    And user "user1" has been created with default attributes
+    And user "user2" has been created with default attributes and without skeleton files
     And user "user1" has logged in using the webUI
     And user "user1" has shared file "lorem.txt" with user "user2"
     And the user has opened the share dialog for file "lorem.txt"
@@ -276,6 +322,8 @@ Feature: Sharing files and folders with internal users
 
   Scenario: user should not be able to send notification by email when allow share mail notification has been disabled
     Given parameter "shareapi_allow_mail_notification" of app "core" has been set to "no"
+    And user "user1" has been created with default attributes
+    And user "user2" has been created with default attributes and without skeleton files
     And user "user1" has logged in using the webUI
     And user "user1" has shared file "lorem.txt" with user "user2"
     When the user opens the share dialog for file "lorem.txt"

From b0b80d430d336ed8bb67f7be76ade05cd6df50fb Mon Sep 17 00:00:00 2001
From: Saugat Pachhai <suagatchhetri@outlook.com>
Date: Sun, 2 Jun 2019 09:27:32 +0545
Subject: [PATCH 065/131] Fix minor annoyances and provide helpful output on
 test run

---
 .../features/bootstrap/Provisioning.php       |  7 ++
 tests/acceptance/run.sh                       | 66 +++++++++++++++----
 2 files changed, 61 insertions(+), 12 deletions(-)

diff --git a/tests/acceptance/features/bootstrap/Provisioning.php b/tests/acceptance/features/bootstrap/Provisioning.php
index f0d08232cece..3ba11b843c2f 100644
--- a/tests/acceptance/features/bootstrap/Provisioning.php
+++ b/tests/acceptance/features/bootstrap/Provisioning.php
@@ -1329,6 +1329,13 @@ public function createUser(
 				);
 				foreach ($results as $result) {
 					if ($result->getStatusCode() !== 200) {
+						$message = $this->getResponseXml($result)->xpath("/ocs/meta/message");
+						if ($message && (string) $message[0] === "User already exists") {
+							PHPUnit\Framework\Assert::fail(
+								'Could not create user as it already exists. ' .
+								'Please delete the user to run tests again.'
+							);
+						}
 						throw new Exception(
 							"could not create user. "
 							. $result->getStatusCode() . " " . $result->getBody()
diff --git a/tests/acceptance/run.sh b/tests/acceptance/run.sh
index f64c5327ffc2..5f6e7f74ee2d 100755
--- a/tests/acceptance/run.sh
+++ b/tests/acceptance/run.sh
@@ -231,6 +231,38 @@ function get_path_from_url() {
 	echo ${PATH%/}
 }
 
+# check that server is up and working correctly
+# $1 the full URL including the protocol
+# exits if server is not working correctly (by pinging status.php), otherwise returns
+function assert_server_up() {
+	curl -k -sSf -L $1/status.php -o /dev/null
+	if [[ $? -eq 0 ]]
+	then
+		return
+	else
+		echo >&2 "Server on $1 is down or not working correctly."
+		exit 98
+	fi
+}
+
+# check that testing app is installed
+# $1 the full URL including the protocol
+# if testing app is not installed, this returns 500 status code
+# we are not sending request with auth, so if it is installed 401 Not Authorized is returned.
+# anyway, if it's not 500, assume testing app is installed and move on.
+# Otherwise, print to stderr and exit.
+function assert_testing_app_enabled() {
+	CURL_RESULT=`curl -s $1/ocs/v2.php/apps/testing/api/v1/app/testing -o /dev/null -w "%{http_code}"`
+	if [[ ${CURL_RESULT} -eq 500 ]]
+	then
+		echo >&2 "Testing app is not enabled on the server on $1."
+		echo >&2 "Please install and enable it to run the tests."
+		exit 98
+	else
+		return
+	fi
+}
+
 # Provide a default admin username and password.
 # But let the caller pass them if they wish
 if [ -z "${ADMIN_USERNAME}" ]
@@ -425,17 +457,17 @@ function teardown() {
 		kill ${PHPPID}
 		kill ${PHPPID_FED}
 	fi
-	
+
 	if [ "${SHOW_OC_LOGS}" = true ]
 	then
 		tail "${OC_PATH}/data/owncloud.log"
 	fi
-	
+
 	# Reset the original language
 	export LANG=${OLD_LANG}
 	
 	rm -f "${TEST_LOG_FILE}"
-	
+
 	echo "runsh: Exit code of main run: ${BEHAT_EXIT_STATUS}"
 }
 
@@ -462,24 +494,34 @@ then
 	TESTING_APP_URL="${TEST_SERVER_URL}/ocs/v2.php/apps/testing/api/v1/"
 	OCC_URL="${TESTING_APP_URL}occ"
 	DIR_URL="${TESTING_APP_URL}dir"
+	# test that server is up and running, and testing app is enabled.
+	assert_server_up ${TEST_SERVER_URL}
+	assert_testing_app_enabled ${TEST_SERVER_URL}
+
 	if [ -n "${TEST_SERVER_FED_URL}" ]
 	then
 		TESTING_APP_FED_URL="${TEST_SERVER_FED_URL}/ocs/v2.php/apps/testing/api/v1/"
 		OCC_FED_URL="${TESTING_APP_FED_URL}occ"
+		# test that fed server is up and running, and testing app is enabled.
+		assert_server_up ${TEST_SERVER_FED_URL}
+		assert_testing_app_enabled ${TEST_SERVER_FED_URL}
 	fi
-	
+
 	echo "Not using php inbuilt server for running scenario ..."
 	echo "Updating .htaccess for proper rewrites"
 	#get the sub path of the webserver and set the correct RewriteBase
 	WEBSERVER_PATH=$(get_path_from_url ${TEST_SERVER_URL})
+	HTACCESS_UPDATE_FAILURE_MSG="Could not update .htaccess in local server. Some tests might fail as a result."
 	remote_occ ${ADMIN_AUTH} ${OCC_URL} "config:system:set htaccess.RewriteBase --value /${WEBSERVER_PATH}/"
 	remote_occ ${ADMIN_AUTH} ${OCC_URL} "maintenance:update:htaccess"
+	[[ $? -eq 0 ]] || { echo "${HTACCESS_UPDATE_FAILURE_MSG}"; }
 
 	if [ -n "${TEST_SERVER_FED_URL}" ]
 	then
 		WEBSERVER_PATH=$(get_path_from_url ${TEST_SERVER_FED_URL})
 		remote_occ ${ADMIN_AUTH} ${OCC_FED_URL} "config:system:set htaccess.RewriteBase --value /${WEBSERVER_PATH}/"
 		remote_occ ${ADMIN_AUTH} ${OCC_FED_URL} "maintenance:update:htaccess"
+		[[ $? -eq 0 ]] || { echo "${HTACCESS_UPDATE_FAILURE_MSG/local/federated}"; }
 	fi
 else
 	echo "Using php inbuilt server for running scenario ..."
@@ -545,11 +587,11 @@ ACCEPTANCE_DIR=$(dirname "${BEHAT_CONFIG_DIR}")
 BEHAT_FEATURES_DIR="${ACCEPTANCE_DIR}/features"
 
 declare -a BEHAT_SUITES
-if [ -n "${BEHAT_SUITE}" ]
+if [[ -n "${BEHAT_SUITE}" ]]
 then
 	BEHAT_SUITES+=(${BEHAT_SUITE})
 else
-	if [ -n "${RUN_PART}" ]
+	if [[ -n "${RUN_PART}" ]]
 	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`
@@ -560,13 +602,13 @@ else
 		# 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} ]
+		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))))
+			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 ]
@@ -727,7 +769,7 @@ then
 	fi
 	for URL in ${TESTING_APP_URL} ${TESTING_APP_FED_URL}
 	do
-		curl -k -s -u $ADMIN_AUTH ${URL}testingskeletondirectory -d "directory=${SRC_SKELETON_DIR}" > /dev/null
+		curl -k -s -u ${ADMIN_AUTH} ${URL}testingskeletondirectory -d "directory=${SRC_SKELETON_DIR}" > /dev/null
 	done
 else
 	for URL in ${OCC_URL} ${OCC_FED_URL}
@@ -930,11 +972,11 @@ for i in "${!BEHAT_SUITES[@]}"
 	do
 	BEHAT_SUITE_OPTION="--suite=${BEHAT_SUITES[$i]}"
 	SUITE_FEATURE_TEXT="${BEHAT_SUITES[$i]}"
-	for rerun_number in $(seq 1 $BEHAT_RERUN_TIMES)
+	for rerun_number in $(seq 1 ${BEHAT_RERUN_TIMES})
 		do
-		if (($BEHAT_RERUN_TIMES > 1))
+		if ((${BEHAT_RERUN_TIMES} > 1))
 		then
-			echo -e "\nTest repeat $rerun_number of $BEHAT_RERUN_TIMES"
+			echo -e "\nTest repeat $rerun_number of ${BEHAT_RERUN_TIMES}"
 		fi
 		run_behat_tests
 	done

From be6ed8acf197e708a80301138e3021d07bd754f9 Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Fri, 31 May 2019 12:09:14 +0545
Subject: [PATCH 066/131] skipOnEncryption annotation added on feature test

---
 .../features/apiShareManagementBasic/createShare.feature         | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/acceptance/features/apiShareManagementBasic/createShare.feature b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
index 4ea11243b324..b68e5577d5ec 100644
--- a/tests/acceptance/features/apiShareManagementBasic/createShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
@@ -589,6 +589,7 @@ Feature: sharing
       | 1               | 100             |
       | 2               | 200             |
 
+  @skipOnEncryption @issue-encryption-126
   Scenario: share with user when username contains capital letters
     Given these users have been created:
       | username |

From 6e61c6eeb6deedea57d70bbe53d5c88060a99132 Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Wed, 15 May 2019 14:44:34 +0545
Subject: [PATCH 067/131] acceptance test for tags removal and tags deletion

---
 .../features/bootstrap/WebUITagsContext.php   | 13 ++++
 .../lib/FilesPageElement/DetailsDialog.php    | 58 +++++++++++++++++
 .../features/webUITags/deleteTags.feature     | 34 ++++++++++
 .../features/webUITags/editTags.feature       | 36 ++++++++++
 .../features/webUITags/removeTags.feature     | 65 +++++++++++++++++++
 5 files changed, 206 insertions(+)
 create mode 100644 tests/acceptance/features/webUITags/editTags.feature

diff --git a/tests/acceptance/features/bootstrap/WebUITagsContext.php b/tests/acceptance/features/bootstrap/WebUITagsContext.php
index 82e2e6ba2d90..6c2497e241e8 100644
--- a/tests/acceptance/features/bootstrap/WebUITagsContext.php
+++ b/tests/acceptance/features/bootstrap/WebUITagsContext.php
@@ -25,6 +25,7 @@
 use Behat\MinkExtension\Context\RawMinkContext;
 use Page\FilesPage;
 use Page\TagsPage;
+use Behat\Gherkin\Node\TableNode;
 
 require_once 'bootstrap.php';
 
@@ -103,6 +104,18 @@ public function theUserTypesAValueInTheCollaborativeTagsFieldUsingTheWebUI($valu
 		$this->filesPage->getDetailsDialog()->insertTagNameInTheTagsField($value);
 	}
 
+	/**
+	 * @When the user edits the tag with name :oldName and sets its name to :newName using the webUI
+	 *
+	 * @param string $oldName
+	 * @param string $newName
+	 *
+	 * @return void
+	 */
+	public function theUserEditsTheTagWithNameAndSetsItsNameToUsingTheWebui($oldName, $newName) {
+		$this->filesPage->getDetailsDialog()->renameTag($oldName, $newName);
+	}
+
 	/**
 	 * @Then all the tags starting with :value in their name should be listed in the dropdown list on the webUI
 	 *
diff --git a/tests/acceptance/features/lib/FilesPageElement/DetailsDialog.php b/tests/acceptance/features/lib/FilesPageElement/DetailsDialog.php
index 4a7a857ef9db..f4e4e94b57ad 100644
--- a/tests/acceptance/features/lib/FilesPageElement/DetailsDialog.php
+++ b/tests/acceptance/features/lib/FilesPageElement/DetailsDialog.php
@@ -27,7 +27,9 @@
 use Behat\Mink\Session;
 use Page\OwncloudPage;
 use SensioLabs\Behat\PageObjectExtension\PageObject\Exception\ElementNotFoundException;
+use WebDriver\Exception\NoSuchElement;
 use WebDriver\Exception\StaleElementReference;
+use WebDriver\Key;
 
 /**
  * The Details Dialog
@@ -60,6 +62,7 @@ class DetailsDialog extends OwncloudPage {
 	private $tagsDropDownResultXpath = "//div[contains(@class, 'systemtags-select2-dropdown')]" .
 										"//ul[@class='select2-results']" .
 										"//span[@class='label']";
+	private $tagEditInputXpath = "//input[@id='view9-rename-input']";
 
 	private $commentXpath = "//ul[@class='comments']//div[@class='message' and contains(., '%s')]";
 	private $commentInputXpath = "//form[@class='newCommentForm']//textarea[@class='message']";
@@ -232,6 +235,7 @@ public function getCommentList() {
 			"xpath", $this->commentListXpath
 		);
 	}
+
 	/**
 	 * check if a comment with given text is listed on the webUI
 	 *
@@ -497,6 +501,60 @@ public function deleteTag($tagName) {
 			}
 		}
 	}
+
+	/**
+	 * Rename a tag on the files in the details dialog
+	 *
+	 * @param string $tagName
+	 * @param string $newName
+	 *
+	 * @return void
+	 * @throws ElementNotFoundException
+	 */
+	public function renameTag($tagName, $newName) {
+		$this->insertTagNameInTheTagsField($tagName);
+		$suggestions = $this->getDropDownTagsSuggestionResults();
+		foreach ($suggestions as $tag) {
+			if ($tag->getText() === $tagName) {
+				$tagContainer = $tag->getParent();
+				$editBtn = $tagContainer->find("xpath", $this->tagEditButtonInTagXpath);
+				$this->assertElementNotNull(
+					$editBtn,
+					__METHOD__ .
+					" xpath: $this->tagEditButtonInTagXpath" .
+					"could not find tag edit button"
+				);
+				$editBtn->focus();
+				$editBtn->click();
+				$editInput = $this->find(
+					"xpath", $this->tagEditInputXpath
+				);
+				$this->assertElementNotNull(
+					$editInput,
+					__METHOD__ .
+					"xpath: $this->tagEditInputXpath" .
+					" could not find tag edit input"
+				);
+				$editInput->focus();
+				$editInput->click();
+				try {
+					$this->fillField("Rename", $newName . Key::ENTER);
+				} catch (NoSuchElement $e) {
+					// this seems to be a bug in MinkSelenium2Driver.
+					// Used to work fine in 1.3.1 but now throws this exception
+					// Actually all that we need does happen, so we just don't do anything
+				} catch (StaleElementReference $e) {
+					// At the end of processing setValue, MinkSelenium2Driver tries to blur
+					// away from the element. But we pressed enter which has already
+					// made the element go away. So we do not care about this exception.
+					// This issue started happening due to:
+					// https://github.com/minkphp/MinkSelenium2Driver/pull/286
+				}
+				break;
+			}
+		}
+	}
+
 	/**
 	 * Returns xpath of the tag results dropdown
 	 *
diff --git a/tests/acceptance/features/webUITags/deleteTags.feature b/tests/acceptance/features/webUITags/deleteTags.feature
index 8255c805927f..8e054681567c 100644
--- a/tests/acceptance/features/webUITags/deleteTags.feature
+++ b/tests/acceptance/features/webUITags/deleteTags.feature
@@ -43,3 +43,37 @@ Feature: Deletion of existing tags from files and folders
       | lorem | normal |
     When the user deletes tag with name "lorem" using the webUI
     Then tag "lorem" should not exist for user "user1"
+
+  Scenario: Delete a tag that exists for multiple file
+    Given the user has created a "normal" tag with name "lorem"
+    And the user has added tag "lorem" to file "lorem.txt"
+    And the user has added tag "lorem" to file "lorem-big.txt"
+    And the user has browsed directly to display the details of file "lorem.txt" in folder "simple-folder"
+    When the user deletes tag with name "lorem" using the webUI
+    Then tag "lorem" should not exist for user "user1"
+
+  Scenario: Delete all tags that exist for a file
+    Given the user has created a "normal" tag with name "lorem"
+    And the user has created a "normal" tag with name "Confidential"
+    And the user has added tag "lorem" to file "lorem.txt"
+    And the user has added tag "Confidential" to file "lorem.txt"
+    And the user has browsed directly to display the details of file "lorem.txt" in folder "/"
+    When the user deletes tag with name "lorem" using the webUI
+    And the user deletes tag with name "Confidential" using the webUI
+    Then file "lorem.txt" should have no tags for user "user1"
+
+  Scenario: Delete multiple tags that exist for a file
+    Given the user has created a "normal" tag with name "lorem"
+    And the user has created a "normal" tag with name "Confidential"
+    And the user has created a "normal" tag with name "some-tag"
+    And the user has added tag "lorem" to file "lorem.txt"
+    And the user has added tag "Confidential" to file "lorem.txt"
+    And the user has added tag "some-tag" to file "lorem.txt"
+    And the user has browsed directly to display the details of file "lorem.txt" in folder "/"
+    When the user deletes tag with name "lorem" using the webUI
+    And the user deletes tag with name "Confidential" using the webUI
+    Then tag "lorem" should not exist for user "user1"
+    And tag "Confidential" should not exist for user "user1"
+    And file "/lorem.txt" should have the following tags for user "user1"
+      | some-tag | normal |
+
diff --git a/tests/acceptance/features/webUITags/editTags.feature b/tests/acceptance/features/webUITags/editTags.feature
new file mode 100644
index 000000000000..9fe8738cb4a5
--- /dev/null
+++ b/tests/acceptance/features/webUITags/editTags.feature
@@ -0,0 +1,36 @@
+@webUI @insulated @disablePreviews @systemtags-app-required
+Feature: Edit tags for files and folders
+  As a user
+  I want to edit tags for files/folders
+  So that I can find them easily
+
+  Background:
+    Given these users have been created with default attributes:
+      | username |
+      | user1    |
+      | user2    |
+    And the user has browsed to the login page
+    And the user has logged in with username "user1" and password "%alt1%" using the webUI
+
+  Scenario: Change the name of a tag that already exists for a file
+    Given the user has created a "normal" tag with name "lorem"
+    And the user has added tag "lorem" to file "lorem.txt"
+    When the user browses directly to display the details of file "lorem.txt" in folder "/"
+    And the user edits the tag with name "lorem" and sets its name to "lorem-big" using the webUI
+    Then file "lorem.txt" should have the following tags for user "user1"
+      | lorem-big  | normal |
+    And tag "lorem" should not exist for the user
+
+  Scenario: Change the name of multiple tags that exist for a file
+    Given the user has created a "normal" tag with name "lorem"
+    And the user has created a "normal" tag with name "some-tag"
+    And the user has added tag "lorem" to file "lorem.txt"
+    And the user has added tag "some-tag" to file "lorem.txt"
+    When the user browses directly to display the details of file "lorem.txt" in folder "/"
+    And the user edits the tag with name "lorem" and sets its name to "lorem-big" using the webUI
+    And the user edits the tag with name "some-tag" and sets its name to "another-tag" using the webUI
+    Then file "lorem.txt" should have the following tags for user "user1"
+      |  lorem-big  | normal |
+      | another-tag | normal |
+    And tag "lorem" should not exist for the user
+    And tag "some-tag" should not exist for the user
\ No newline at end of file
diff --git a/tests/acceptance/features/webUITags/removeTags.feature b/tests/acceptance/features/webUITags/removeTags.feature
index 4260633a6156..65b00ffecb59 100644
--- a/tests/acceptance/features/webUITags/removeTags.feature
+++ b/tests/acceptance/features/webUITags/removeTags.feature
@@ -8,6 +8,7 @@ Feature: Removal of already existing tags from files and folders
     Given these users have been created with default attributes:
       | username |
       | user1    |
+      | user2    |
     And the user has browsed to the login page
     And the user has logged in with username "user1" and password "%alt1%" using the webUI
 
@@ -18,4 +19,68 @@ Feature: Removal of already existing tags from files and folders
     And the user toggles a tag "lorem" on the file using the webUI
     Then file "simple-folder/lorem.txt" should have no tags for user "user1"
 
+  Scenario: Remove a tag that already exists for a file in the root
+    Given the user has browsed directly to display the details of file "lorem.txt" in folder "/"
+    And the user has added a tag "lorem" to the file using the webUI
+    When the user browses directly to display the details of file "lorem.txt" in folder "/"
+    And the user toggles a tag "lorem" on the file using the webUI
+    Then file "lorem.txt" should have no tags for user "user1"
+
+  Scenario: Remove all tags that already exist for a file
+    Given the user has created a "normal" tag with name "lorem"
+    And the user has created a "normal" tag with name "Confidential"
+    And the user has added tag "lorem" to file "lorem.txt"
+    And the user has added tag "Confidential" to file "lorem.txt"
+    When the user browses directly to display the details of file "lorem.txt" in folder "/"
+    And the user toggles a tag "lorem" on the file using the webUI
+    And the user toggles a tag "Confidential" on the file using the webUI
+    Then file "lorem.txt" should have no tags for user "user1"
+
+  Scenario: Shared user removes a tag in shared file
+    Given the user has created a "normal" tag with name "tag1"
+    And user "user1" has uploaded file with content "does-not-matter" to "/coolnewfile.txt"
+    And the user has added tag "tag1" to file "coolnewfile.txt"
+    And the user has shared file "coolnewfile.txt" with user "user2"
+    When the user re-logs in as "user2" using the webUI
+    Then file "coolnewfile.txt" should have the following tags for user "user2"
+      | tag1 | normal |
+    When the user browses directly to display the details of file "coolnewfile.txt" in folder "/"
+    And the user toggles a tag "tag1" on the file using the webUI
+    Then file "coolnewfile.txt" should have no tags for user "user2"
+    And file "coolnewfile.txt" should have no tags for user "user1"
 
+  Scenario: Sharer removes a tag in shared file
+    Given the user has created a "normal" tag with name "tag1"
+    And user "user1" has uploaded file with content "does-not-matter" to "/coolnewfile.txt"
+    And the user has added tag "tag1" to file "coolnewfile.txt"
+    And the user has shared file "coolnewfile.txt" with user "user2"
+    When the user re-logs in as "user2" using the webUI
+    Then file "coolnewfile.txt" should have the following tags for user "user2"
+      | tag1 | normal |
+    When the user re-logs in with username "user1" and password "%alt1%" using the webUI
+    And the user browses directly to display the details of file "coolnewfile.txt" in folder "/"
+    And the user toggles a tag "tag1" on the file using the webUI
+    Then file "coolnewfile.txt" should have no tags for user "user2"
+    And file "coolnewfile.txt" should have no tags for user "user1"
+
+  Scenario: Remove multiple tags that exist for a file
+    Given the user has created a "normal" tag with name "lorem"
+    And the user has created a "normal" tag with name "Confidential"
+    And the user has created a "normal" tag with name "some-tag"
+    And the user has added tag "lorem" to file "lorem.txt"
+    And the user has added tag "Confidential" to file "lorem.txt"
+    And the user has added tag "some-tag" to file "lorem.txt"
+    When the user browses directly to display the details of file "lorem.txt" in folder "/"
+    And the user toggles a tag "lorem" on the file using the webUI
+    And the user toggles a tag "Confidential" on the file using the webUI
+    Then file "lorem.txt" should have the following tags for user "user1"
+      | some-tag | normal |
+
+  Scenario: Remove a tag from a file and assign another tag
+    Given the user has created a "normal" tag with name "lorem"
+    And the user has added tag "lorem" to file "lorem.txt"
+    When the user browses directly to display the details of file "lorem.txt" in folder "/"
+    And the user toggles a tag "lorem" on the file using the webUI
+    And the user adds a tag "some-tag" to the file using the webUI
+    Then file "lorem.txt" should have the following tags for user "user1"
+      | some-tag | normal |

From 96b7bfaf52f901f659d217288e23b224b1d6d64f Mon Sep 17 00:00:00 2001
From: Dipak Acharya <dpakach@gmail.com>
Date: Mon, 3 Jun 2019 13:01:31 +0545
Subject: [PATCH 068/131] Do not use skeleton file when not required

---
 .../adminStorageSettings.feature              |  12 +-
 .../acceptShares.feature                      | 163 +++++++++---------
 2 files changed, 83 insertions(+), 92 deletions(-)

diff --git a/tests/acceptance/features/webUIAdminSettings/adminStorageSettings.feature b/tests/acceptance/features/webUIAdminSettings/adminStorageSettings.feature
index bf57d4008292..709e36a3befa 100644
--- a/tests/acceptance/features/webUIAdminSettings/adminStorageSettings.feature
+++ b/tests/acceptance/features/webUIAdminSettings/adminStorageSettings.feature
@@ -15,7 +15,7 @@ Feature: admin storage settings
     Then the external storage form should not be displayed on the storage settings page
 
   Scenario: administrator creates a local storage mount
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and without skeleton files
     And the administrator has browsed to the admin storage settings page
     And the administrator has enabled the external storage
     When the administrator creates the local storage mount "local_storage1" using the webUI
@@ -23,7 +23,7 @@ Feature: admin storage settings
     Then folder "local_storage1" should be listed on the webUI
 
   Scenario: administrator assigns an applicable user to a local storage mount
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and without skeleton files:
       | username |
       | user0    |
       | user1    |
@@ -41,7 +41,7 @@ Feature: admin storage settings
     And folder "local_storage2" should be listed on the webUI
 
   Scenario: user should get access if the user is removed from the applicable user and the user was the only applicable user
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and without skeleton files:
       | username |
       | user0    |
       | user1    |
@@ -56,7 +56,7 @@ Feature: admin storage settings
     And folder "local_storage1" should be listed on the webUI
 
   Scenario: administrator should be able to create a local mount for a specific group
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and without skeleton files:
       | username |
       | user0    |
       | user1    |
@@ -72,7 +72,7 @@ Feature: admin storage settings
     And folder "local_storage1" should not be listed on the webUI
 
   Scenario: removing group from applicable group of a local mount
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and without skeleton files:
       | username |
       | user0    |
       | user1    |
@@ -122,7 +122,7 @@ Feature: admin storage settings
     And folder "local_storage1" should not be listed on the webUI
 
   Scenario: local storage mount is not deleted when the one of two users applicable to the mount is deleted
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and without skeleton files:
       | username |
       | user0    |
       | user1    |
diff --git a/tests/acceptance/features/webUISharingAcceptShares/acceptShares.feature b/tests/acceptance/features/webUISharingAcceptShares/acceptShares.feature
index 8b647feda276..bad08fd14a37 100644
--- a/tests/acceptance/features/webUISharingAcceptShares/acceptShares.feature
+++ b/tests/acceptance/features/webUISharingAcceptShares/acceptShares.feature
@@ -5,10 +5,8 @@ Feature: accept/decline shares coming from internal users
   So that I can keep my file system clean
 
   Background:
-    Given these users have been created with default attributes:
-      | username |
-      | user1    |
-      | user2    |
+    Given user "user1" has been created with default attributes and without skeleton files
+    Given user "user2" has been created with default attributes
     And these groups have been created:
       | groupname |
       | grp1      |
@@ -21,45 +19,37 @@ Feature: accept/decline shares coming from internal users
     And user "user2" has shared folder "/simple-folder" with group "grp1"
     And user "user2" has shared file "/testimage.jpg" with user "user1"
     When user "user1" logs in using the webUI
-    Then folder "simple-folder (2)" should not be listed on the webUI
-    And file "testimage (2).jpg" should not be listed on the webUI
+    Then folder "simple-folder" should not be listed on the webUI
+    And file "testimage.jpg" should not be listed on the webUI
     But folder "simple-folder" should be listed in the shared-with-you page on the webUI
     And file "testimage.jpg" should be listed in the shared-with-you page on the webUI
     And folder "simple-folder" should be in state "Pending" in the shared-with-you page on the webUI
     And file "testimage.jpg" should be in state "Pending" in the shared-with-you page on the webUI
 
-  Scenario: receive shares with same name from different users
-    Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been disabled
-    And user "user3" has been created with default attributes
-    And user "user2" has shared folder "/simple-folder" with user "user3"
-    And user "user1" has shared folder "/simple-folder" with user "user3"
-    When user "user3" logs in using the webUI
-    Then folder "simple-folder" shared by "User One" should be in state "Pending" in the shared-with-you page on the webUI
-    And folder "simple-folder" shared by "User Two" should be in state "Pending" in the shared-with-you page on the webUI
-
   Scenario: receive shares with same name from different users, accept one by one
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been disabled
-    And user "user3" has been created with default attributes
+    And user "user3" has been created with default attributes and without skeleton files
     And user "user2" has created folder "/simple-folder/from_user2"
     And user "user2" has shared folder "/simple-folder" with user "user3"
+    And user "user1" has created folder "/simple-folder"
     And user "user1" has created folder "/simple-folder/from_user1"
     And user "user1" has shared folder "/simple-folder" with user "user3"
     And user "user3" has logged in using the webUI
     When the user accepts share "simple-folder" offered by user "User One" using the webUI
     And the user accepts share "simple-folder" offered by user "User Two" using the webUI
-    Then folder "simple-folder (2)" shared by "User One" should be in state "" in the shared-with-you page on the webUI
-    And folder "simple-folder (3)" shared by "User Two" should be in state "" in the shared-with-you page on the webUI
+    Then folder "simple-folder" shared by "User One" should be in state "" in the shared-with-you page on the webUI
+    And folder "simple-folder (2)" shared by "User Two" should be in state "" in the shared-with-you page on the webUI
     And user "user3" should see the following elements
-      | /simple-folder%20(2)/from_user1/ |
-      | /simple-folder%20(3)/from_user2/ |
+      | /simple-folder/from_user1/       |
+      | /simple-folder%20(2)/from_user2/ |
 
   Scenario: receive shares with same name from different users
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been disabled
     And user "user3" has been created with default attributes
-    And user "user2" has shared folder "/simple-folder" with user "user3"
-    And user "user1" has shared folder "/simple-folder" with user "user3"
-    When user "user3" logs in using the webUI
-    Then folder "simple-folder" shared by "User One" should be in state "Pending" in the shared-with-you page on the webUI
+    And user "user2" has shared folder "/simple-folder" with user "user1"
+    And user "user3" has shared folder "/simple-folder" with user "user1"
+    When user "user1" logs in using the webUI
+    Then folder "simple-folder" shared by "User Three" should be in state "Pending" in the shared-with-you page on the webUI
     And folder "simple-folder" shared by "User Two" should be in state "Pending" in the shared-with-you page on the webUI
 
   @smokeTest
@@ -69,12 +59,12 @@ Feature: accept/decline shares coming from internal users
     And user "user2" has shared file "/testimage.jpg" with user "user1"
     And user "user1" has logged in using the webUI
     When the user accepts share "simple-folder" offered by user "User Two" using the webUI
-    Then folder "simple-folder (2)" should be in state "" in the shared-with-you page on the webUI
+    Then folder "simple-folder" should be in state "" in the shared-with-you page on the webUI
     And file "testimage.jpg" should be in state "Pending" in the shared-with-you page on the webUI
-    And folder "simple-folder (2)" should be in state "" in the shared-with-you page on the webUI after a page reload
+    And folder "simple-folder" should be in state "" in the shared-with-you page on the webUI after a page reload
     And file "testimage.jpg" should be in state "Pending" in the shared-with-you page on the webUI after a page reload
-    And folder "simple-folder (2)" should be listed in the files page on the webUI
-    And file "testimage (2).jpg" should not be listed in the files page on the webUI
+    And folder "simple-folder" should be listed in the files page on the webUI
+    And file "testimage.jpg" should not be listed in the files page on the webUI
 
   @smokeTest
   Scenario: decline an offered (pending) share
@@ -85,8 +75,8 @@ Feature: accept/decline shares coming from internal users
     When the user declines share "simple-folder" offered by user "User Two" using the webUI
     Then folder "simple-folder" should be in state "Declined" in the shared-with-you page on the webUI
     And file "testimage.jpg" should be in state "Pending" in the shared-with-you page on the webUI
-    And folder "simple-folder (2)" should not be listed in the files page on the webUI
-    And file "testimage (2).jpg" should not be listed in the files page on the webUI
+    And folder "simple-folder" should not be listed in the files page on the webUI
+    And file "testimage.jpg" should not be listed in the files page on the webUI
 
   @smokeTest
   Scenario: decline an accepted share (with page-reload in between)
@@ -96,11 +86,11 @@ Feature: accept/decline shares coming from internal users
     And user "user1" has logged in using the webUI
     When the user accepts share "simple-folder" offered by user "User Two" using the webUI
     And the user reloads the current page of the webUI
-    And the user declines share "simple-folder (2)" offered by user "User Two" using the webUI
-    Then folder "simple-folder (2)" should be in state "Declined" in the shared-with-you page on the webUI
+    And the user declines share "simple-folder" offered by user "User Two" using the webUI
+    Then folder "simple-folder" should be in state "Declined" in the shared-with-you page on the webUI
     And file "testimage.jpg" should be in state "Pending" in the shared-with-you page on the webUI
-    And folder "simple-folder (2)" should not be listed in the files page on the webUI
-    And file "testimage (2).jpg" should not be listed in the files page on the webUI
+    And folder "simple-folder" should not be listed in the files page on the webUI
+    And file "testimage.jpg" should not be listed in the files page on the webUI
 
   Scenario: decline an accepted share (without any page-reload in between)
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been disabled
@@ -108,11 +98,11 @@ Feature: accept/decline shares coming from internal users
     And user "user2" has shared file "/testimage.jpg" with user "user1"
     And user "user1" has logged in using the webUI
     When the user accepts share "simple-folder" offered by user "User Two" using the webUI
-    And the user declines share "simple-folder (2)" offered by user "User Two" using the webUI
-    Then folder "simple-folder (2)" should be in state "Declined" in the shared-with-you page on the webUI
+    And the user declines share "simple-folder" offered by user "User Two" using the webUI
+    Then folder "simple-folder" should be in state "Declined" in the shared-with-you page on the webUI
     And file "testimage.jpg" should be in state "Pending" in the shared-with-you page on the webUI
-    And folder "simple-folder (2)" should not be listed in the files page on the webUI
-    And file "testimage (2).jpg" should not be listed in the files page on the webUI
+    And folder "simple-folder" should not be listed in the files page on the webUI
+    And file "testimage.jpg" should not be listed in the files page on the webUI
 
   Scenario: accept a previously declined share
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been disabled
@@ -121,10 +111,10 @@ Feature: accept/decline shares coming from internal users
     And user "user1" has logged in using the webUI
     And the user declines share "simple-folder" offered by user "User Two" using the webUI
     When the user accepts share "simple-folder" offered by user "User Two" using the webUI
-    Then folder "simple-folder (2)" should be in state "" in the shared-with-you page on the webUI
+    Then folder "simple-folder" should be in state "" in the shared-with-you page on the webUI
     And file "testimage.jpg" should be in state "Pending" in the shared-with-you page on the webUI
-    And folder "simple-folder (2)" should be listed in the files page on the webUI
-    And file "testimage (2).jpg" should not be listed in the files page on the webUI
+    And folder "simple-folder" should be listed in the files page on the webUI
+    And file "testimage.jpg" should not be listed in the files page on the webUI
 
   Scenario: accept a share that you received as user and as group member
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been disabled
@@ -133,8 +123,8 @@ Feature: accept/decline shares coming from internal users
     And user "user1" has logged in using the webUI
     When the user accepts share "simple-folder" offered by user "User Two" using the webUI
     And the user reloads the current page of the webUI
-    Then folder "simple-folder (2)" should be in state "" in the shared-with-you page on the webUI
-    And folder "simple-folder (2)" should be listed in the files page on the webUI
+    Then folder "simple-folder" should be in state "" in the shared-with-you page on the webUI
+    And folder "simple-folder" should be listed in the files page on the webUI
 
   Scenario: reject a share that you received as user and as group member
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been disabled
@@ -144,7 +134,7 @@ Feature: accept/decline shares coming from internal users
     When the user declines share "simple-folder" offered by user "User Two" using the webUI
     And the user reloads the current page of the webUI
     Then folder "simple-folder" should be in state "Declined" in the shared-with-you page on the webUI
-    And folder "simple-folder (2)" should not be listed in the files page on the webUI
+    And folder "simple-folder" should not be listed in the files page on the webUI
 
   Scenario: reshare a share that you received to a group that you are member of
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been disabled
@@ -152,11 +142,11 @@ Feature: accept/decline shares coming from internal users
     And user "user1" has logged in using the webUI
     When the user accepts share "simple-folder" offered by user "User Two" using the webUI
     And the user has browsed to the files page
-    And the user shares folder "simple-folder (2)" with group "grp1" using the webUI
-    And the user declines share "simple-folder (2)" offered by user "User Two" using the webUI
+    And the user shares folder "simple-folder" with group "grp1" using the webUI
+    And the user declines share "simple-folder" offered by user "User Two" using the webUI
     And the user reloads the current page of the webUI
-    Then folder "simple-folder (2)" should be in state "Declined" in the shared-with-you page on the webUI
-    And folder "simple-folder (2)" should not be listed in the files page on the webUI
+    Then folder "simple-folder" should be in state "Declined" in the shared-with-you page on the webUI
+    And folder "simple-folder" should not be listed in the files page on the webUI
 
   @smokeTest
   Scenario: unshare an accepted share on the "All files" page
@@ -166,12 +156,12 @@ Feature: accept/decline shares coming from internal users
     And user "user1" has accepted the share "/simple-folder" offered by user "user2"
     And user "user1" has accepted the share "/testimage.jpg" offered by user "user2"
     And user "user1" has logged in using the webUI
-    When the user unshares folder "simple-folder (2)" using the webUI
-    And the user unshares file "testimage (2).jpg" using the webUI
-    Then folder "simple-folder (2)" should not be listed in the files page on the webUI
-    And file "testimage (2).jpg" should not be listed in the files page on the webUI
-    And folder "simple-folder (2)" should be in state "Declined" in the shared-with-you page on the webUI
-    And file "testimage (2).jpg" should be in state "Declined" in the shared-with-you page on the webUI
+    When the user unshares folder "simple-folder" using the webUI
+    And the user unshares file "testimage.jpg" using the webUI
+    Then folder "simple-folder" should not be listed in the files page on the webUI
+    And file "testimage.jpg" should not be listed in the files page on the webUI
+    And folder "simple-folder" should be in state "Declined" in the shared-with-you page on the webUI
+    And file "testimage.jpg" should be in state "Declined" in the shared-with-you page on the webUI
 
   @smokeTest
   Scenario: Auto-accept shares
@@ -179,42 +169,42 @@ Feature: accept/decline shares coming from internal users
     And user "user2" has shared folder "/simple-folder" with group "grp1"
     And user "user2" has shared folder "/testimage.jpg" with user "user1"
     When user "user1" logs in using the webUI
-    Then folder "simple-folder (2)" should be listed on the webUI
-    And file "testimage (2).jpg" should be listed on the webUI
-    And folder "simple-folder (2)" should be listed in the shared-with-you page on the webUI
-    And file "testimage (2).jpg" should be listed in the shared-with-you page on the webUI
-    And folder "simple-folder (2)" should be in state "" in the shared-with-you page on the webUI
-    And file "testimage (2).jpg" should be in state "" in the shared-with-you page on the webUI
+    Then folder "simple-folder" should be listed on the webUI
+    And file "testimage.jpg" should be listed on the webUI
+    And folder "simple-folder" should be listed in the shared-with-you page on the webUI
+    And file "testimage.jpg" should be listed in the shared-with-you page on the webUI
+    And folder "simple-folder" should be in state "" in the shared-with-you page on the webUI
+    And file "testimage.jpg" should be in state "" in the shared-with-you page on the webUI
 
   Scenario: decline auto-accepted shares
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been enabled
     And user "user2" has shared folder "/simple-folder" with group "grp1"
     And user "user2" has shared folder "/testimage.jpg" with user "user1"
     And user "user1" has logged in using the webUI
-    When the user declines share "simple-folder (2)" offered by user "User Two" using the webUI
-    And the user declines share "testimage (2).jpg" offered by user "User Two" using the webUI
+    When the user declines share "simple-folder" offered by user "User Two" using the webUI
+    And the user declines share "testimage.jpg" offered by user "User Two" using the webUI
     And the user has browsed to the files page
-    Then folder "simple-folder (2)" should not be listed on the webUI
-    And file "testimage (2).jpg" should not be listed on the webUI
-    And folder "simple-folder (2)" should be in state "Declined" in the shared-with-you page on the webUI
-    And file "testimage (2).jpg" should be in state "Declined" in the shared-with-you page on the webUI
+    Then folder "simple-folder" should not be listed on the webUI
+    And file "testimage.jpg" should not be listed on the webUI
+    And folder "simple-folder" should be in state "Declined" in the shared-with-you page on the webUI
+    And file "testimage.jpg" should be in state "Declined" in the shared-with-you page on the webUI
 
   Scenario: unshare auto-accepted shares
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been enabled
     And user "user2" has shared folder "/simple-folder" with group "grp1"
     And user "user2" has shared folder "/testimage.jpg" with user "user1"
     And user "user1" has logged in using the webUI
-    When the user unshares folder "simple-folder (2)" using the webUI
-    And the user unshares file "testimage (2).jpg" using the webUI
-    Then folder "simple-folder (2)" should not be listed on the webUI
-    And file "testimage (2).jpg" should not be listed on the webUI
-    And folder "simple-folder (2)" should be in state "Declined" in the shared-with-you page on the webUI
-    And file "testimage (2).jpg" should be in state "Declined" in the shared-with-you page on the webUI
+    When the user unshares folder "simple-folder" using the webUI
+    And the user unshares file "testimage.jpg" using the webUI
+    Then folder "simple-folder" should not be listed on the webUI
+    And file "testimage.jpg" should not be listed on the webUI
+    And folder "simple-folder" should be in state "Declined" in the shared-with-you page on the webUI
+    And file "testimage.jpg" should be in state "Declined" in the shared-with-you page on the webUI
 
   Scenario: unshare renamed shares
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been enabled
     And user "user2" has shared folder "/simple-folder" with user "user1"
-    And user "user1" has moved folder "/simple-folder (2)" to "/simple-folder-renamed"
+    And user "user1" has moved folder "/simple-folder" to "/simple-folder-renamed"
     And user "user1" has logged in using the webUI
     When the user unshares folder "simple-folder-renamed" using the webUI
     Then folder "simple-folder-renamed" should not be listed on the webUI
@@ -223,9 +213,10 @@ Feature: accept/decline shares coming from internal users
   Scenario: unshare moved shares
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been enabled
     And user "user2" has shared folder "/simple-folder" with user "user1"
-    And user "user1" has moved folder "/simple-folder (2)" to "/simple-folder/shared"
+    And user "user1" has created folder "/new-folder"
+    And user "user1" has moved folder "/simple-folder" to "/new-folder/shared"
     And user "user1" has logged in using the webUI
-    When the user opens folder "simple-folder" using the webUI
+    When the user opens folder "new-folder" using the webUI
     And the user unshares folder "shared" using the webUI
     Then folder "shared" should not be listed on the webUI
     And folder "shared" should be in state "Declined" in the shared-with-you page on the webUI
@@ -233,7 +224,7 @@ Feature: accept/decline shares coming from internal users
   Scenario: unshare renamed shares, accept it again
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been enabled
     And user "user2" has shared folder "/simple-folder" with user "user1"
-    And user "user1" has moved folder "/simple-folder (2)" to "/simple-folder-renamed"
+    And user "user1" has moved folder "/simple-folder" to "/simple-folder-renamed"
     And user "user1" has logged in using the webUI
     When the user unshares folder "simple-folder-renamed" using the webUI
     And the user accepts share "simple-folder-renamed" offered by user "User Two" using the webUI
@@ -248,8 +239,8 @@ Feature: accept/decline shares coming from internal users
     And user "user2" shares folder "/simple-folder" with group "grp1" using the sharing API
     And user "user2" shares file "/testimage.jpg" with user "user1" using the sharing API
     And the user browses to the files page
-    Then folder "simple-folder (2)" should not be listed on the webUI
-    And file "testimage (2).jpg" should not be listed on the webUI
+    Then folder "simple-folder" should not be listed on the webUI
+    And file "testimage.jpg" should not be listed on the webUI
     But folder "simple-folder" should be listed in the shared-with-you page on the webUI
     And file "testimage.jpg" should be listed in the shared-with-you page on the webUI
     And folder "simple-folder" should be in state "Pending" in the shared-with-you page on the webUI
@@ -263,12 +254,12 @@ Feature: accept/decline shares coming from internal users
     And user "user2" shares folder "/simple-folder" with group "grp1" using the sharing API
     And user "user2" shares file "/testimage.jpg" with user "user1" using the sharing API
     And the user browses to the files page
-    Then folder "simple-folder (2)" should be listed on the webUI
-    And file "testimage (2).jpg" should be listed on the webUI
-    And folder "simple-folder (2)" should be listed in the shared-with-you page on the webUI
-    And file "testimage (2).jpg" should be listed in the shared-with-you page on the webUI
-    And folder "simple-folder (2)" should be in state "" in the shared-with-you page on the webUI
-    And file "testimage (2).jpg" should be in state "" in the shared-with-you page on the webUI
+    Then folder "simple-folder" should be listed on the webUI
+    And file "testimage.jpg" should be listed on the webUI
+    And folder "simple-folder" should be listed in the shared-with-you page on the webUI
+    And file "testimage.jpg" should be listed in the shared-with-you page on the webUI
+    And folder "simple-folder" should be in state "" in the shared-with-you page on the webUI
+    And file "testimage.jpg" should be in state "" in the shared-with-you page on the webUI
 
   Scenario: User-based accepting checkbox is not visible while global is disabled
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been disabled
@@ -286,8 +277,8 @@ Feature: accept/decline shares coming from internal users
     And user "user2" shares folder "/simple-folder" with group "grp1" using the sharing API
     And user "user2" shares file "/testimage.jpg" with user "user1" using the sharing API
     And the user browses to the files page
-    Then folder "simple-folder (2)" should not be listed on the webUI
-    And file "testimage (2).jpg" should not be listed on the webUI
+    Then folder "simple-folder" should not be listed on the webUI
+    And file "testimage.jpg" should not be listed on the webUI
     And folder "simple-folder" should be listed in the shared-with-you page on the webUI
     And file "testimage.jpg" should be listed in the shared-with-you page on the webUI
     And folder "simple-folder" should be in state "Pending" in the shared-with-you page on the webUI

From 78d2a4e5f71fe5dc096f1edae5e2192755ef043c Mon Sep 17 00:00:00 2001
From: Saugat Pachhai <suagatchhetri@outlook.com>
Date: Sun, 2 Jun 2019 21:26:30 +0545
Subject: [PATCH 069/131] Check if 'mod_rewrite' is enabled

---
 tests/acceptance/run.sh | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/tests/acceptance/run.sh b/tests/acceptance/run.sh
index 5f6e7f74ee2d..9548166d0f10 100755
--- a/tests/acceptance/run.sh
+++ b/tests/acceptance/run.sh
@@ -263,6 +263,24 @@ function assert_testing_app_enabled() {
 	fi
 }
 
+# check if certain apache_module is enabled
+# $1 admin authentication string username:password
+# $2 the full url to the testing app
+# $3 Module to check for
+# return 0 if given module is enabled, else return with 1
+function check_apache_module_enabled() {
+	# test if mod_rewrite is enabled
+	CURL_RESULT=`curl -k -s -u $1 $2apache_modules/$3`
+	STATUS_CODE=`echo ${CURL_RESULT} | xmllint --xpath "string(ocs/meta/statuscode)" -`
+	if [[ ${STATUS_CODE} -ne 200 ]]
+	then
+		echo -n "Could not reliably determine if '$3' module is enabled, because "
+		echo ${CURL_RESULT} | xmllint --xpath "string(ocs/meta/message)" -
+		return 1
+	fi
+	return 0
+}
+
 # Provide a default admin username and password.
 # But let the caller pass them if they wish
 if [ -z "${ADMIN_USERNAME}" ]
@@ -515,6 +533,8 @@ then
 	remote_occ ${ADMIN_AUTH} ${OCC_URL} "config:system:set htaccess.RewriteBase --value /${WEBSERVER_PATH}/"
 	remote_occ ${ADMIN_AUTH} ${OCC_URL} "maintenance:update:htaccess"
 	[[ $? -eq 0 ]] || { echo "${HTACCESS_UPDATE_FAILURE_MSG}"; }
+	# check if mod_rewrite module is enabled
+	check_apache_module_enabled ${ADMIN_AUTH} ${TESTING_APP_URL} "mod_rewrite"
 
 	if [ -n "${TEST_SERVER_FED_URL}" ]
 	then
@@ -522,6 +542,8 @@ then
 		remote_occ ${ADMIN_AUTH} ${OCC_FED_URL} "config:system:set htaccess.RewriteBase --value /${WEBSERVER_PATH}/"
 		remote_occ ${ADMIN_AUTH} ${OCC_FED_URL} "maintenance:update:htaccess"
 		[[ $? -eq 0 ]] || { echo "${HTACCESS_UPDATE_FAILURE_MSG/local/federated}"; }
+		# check if mod_rewrite module is enabled
+		check_apache_module_enabled ${ADMIN_AUTH} ${TESTING_APP_URL} "mod_rewrite"
 	fi
 else
 	echo "Using php inbuilt server for running scenario ..."

From 07402ddfeaf094313c039b2e903427c89b4b1e24 Mon Sep 17 00:00:00 2001
From: Dipak Acharya <dpakach@gmail.com>
Date: Mon, 3 Jun 2019 14:28:27 +0545
Subject: [PATCH 070/131] Split webUISharingInternalUsers into two suites

---
 .drone.yml                                           | 12 ++++++++++++
 tests/acceptance/config/behat.yml                    | 12 ++++++++++++
 .../shareAutocompletion.feature                      |  0
 3 files changed, 24 insertions(+)
 rename tests/acceptance/features/{webUISharingInternalUsers => webUISharingAutocompletion}/shareAutocompletion.feature (100%)

diff --git a/.drone.yml b/.drone.yml
index 08f4aeca5b10..0920649c5e85 100644
--- a/.drone.yml
+++ b/.drone.yml
@@ -1291,6 +1291,18 @@ matrix:
       OWNCLOUD_LOG: true
       INSTALL_TESTING_APP: true
 
+    - PHP_VERSION: 7.1
+      TEST_SUITE: selenium
+      BROWSER: chrome
+      BEHAT_SUITE: webUISharingAutocompletion
+      DB_TYPE: mariadb
+      USE_SERVER: true
+      SERVER_PROTOCOL: https
+      INSTALL_SERVER: true
+      CHOWN_SERVER: true
+      OWNCLOUD_LOG: true
+      INSTALL_TESTING_APP: true
+
     - PHP_VERSION: 7.1
       TEST_SUITE: selenium
       BROWSER: chrome
diff --git a/tests/acceptance/config/behat.yml b/tests/acceptance/config/behat.yml
index fec938484d7e..66abed72c666 100644
--- a/tests/acceptance/config/behat.yml
+++ b/tests/acceptance/config/behat.yml
@@ -409,6 +409,18 @@ default:
         - WebUIAdminSharingSettingsContext:
         - WebUIPersonalSharingSettingsContext:
 
+    webUISharingAutocompletion:
+      paths:
+        - '%paths.base%/../features/webUISharingAutocompletion'
+      contexts:
+        - FeatureContext: *common_feature_context_params
+        - WebUIFilesContext:
+        - WebUIGeneralContext:
+        - WebUILoginContext:
+        - WebUISharingContext:
+        - OccContext:
+        - WebUIPersonalSharingSettingsContext:
+
     webUISharingExternal:
       paths:
         - '%paths.base%/../features/webUISharingExternal'
diff --git a/tests/acceptance/features/webUISharingInternalUsers/shareAutocompletion.feature b/tests/acceptance/features/webUISharingAutocompletion/shareAutocompletion.feature
similarity index 100%
rename from tests/acceptance/features/webUISharingInternalUsers/shareAutocompletion.feature
rename to tests/acceptance/features/webUISharingAutocompletion/shareAutocompletion.feature

From 0055d0906f95df1cbd27b236a5399e397a9fbb36 Mon Sep 17 00:00:00 2001
From: Dipak Acharya <dpakach@gmail.com>
Date: Mon, 3 Jun 2019 17:12:02 +0545
Subject: [PATCH 071/131] Use skeleton files only when necessary in
 webuiCreateDelete and webUISharingIntGrp suites

---
 .../webUICreateDelete/createFolders.feature   |  8 ++++--
 .../createFoldersEdgeCases.feature            |  6 ++--
 .../deleteFilesFolders.feature                |  2 +-
 .../shareWithGroups.feature                   | 28 +++++++++----------
 .../shareWithGroupsEdgeCases.feature          | 20 ++++++-------
 5 files changed, 34 insertions(+), 30 deletions(-)

diff --git a/tests/acceptance/features/webUICreateDelete/createFolders.feature b/tests/acceptance/features/webUICreateDelete/createFolders.feature
index f8f79511e85e..2b2d401639c6 100644
--- a/tests/acceptance/features/webUICreateDelete/createFolders.feature
+++ b/tests/acceptance/features/webUICreateDelete/createFolders.feature
@@ -5,7 +5,7 @@ Feature: create folders
   So that I can organise my data structure
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and without skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the files page
 
@@ -30,11 +30,15 @@ Feature: create folders
     Then folder "sub-folder" should be listed on the webUI
 
   Scenario: Create a folder with existing name
+    Given user "user1" has created folder "/simple-folder"
+    And the user has reloaded the current page of the webUI
     When the user creates a folder with the invalid name "simple-folder" using the webUI
     Then near the folder input field a tooltip with the text 'simple-folder already exists' should be displayed on the webUI
 
   Scenario: Create a folder in a public share
-    Given the user has created a new public link for folder "simple-empty-folder" using the webUI with
+    Given user "user1" has created folder "/simple-empty-folder"
+    And the user has reloaded the current page of the webUI
+    And the user has created a new public link for folder "simple-empty-folder" using the webUI with
       | permission | read-write |
     And the public accesses the last created public link using the webUI
     When the user creates a folder with the name "top-folder" using the webUI
diff --git a/tests/acceptance/features/webUICreateDelete/createFoldersEdgeCases.feature b/tests/acceptance/features/webUICreateDelete/createFoldersEdgeCases.feature
index d0d37fd831c6..ea18f6c81ed1 100644
--- a/tests/acceptance/features/webUICreateDelete/createFoldersEdgeCases.feature
+++ b/tests/acceptance/features/webUICreateDelete/createFoldersEdgeCases.feature
@@ -5,7 +5,7 @@ Feature: create folder
   So that I can organise my data structure
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and without skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the files page
 
@@ -39,8 +39,8 @@ Feature: create folder
 
   @smokeTest
   Scenario Outline: Create a sub-folder inside an existing folder with problematic name
-	# Use an existing folder with problematic name to create a sub-folder
-	# Uses the folder created by skeleton
+    Given user "user1" has created folder <folder>
+    And the user has reloaded the current page of the webUI
     When the user opens folder <folder> using the webUI
     And the user creates a folder with the name "sub-folder" using the webUI
     Then folder "sub-folder" should be listed on the webUI
diff --git a/tests/acceptance/features/webUICreateDelete/deleteFilesFolders.feature b/tests/acceptance/features/webUICreateDelete/deleteFilesFolders.feature
index 144effee3893..02c52c1456ba 100644
--- a/tests/acceptance/features/webUICreateDelete/deleteFilesFolders.feature
+++ b/tests/acceptance/features/webUICreateDelete/deleteFilesFolders.feature
@@ -117,7 +117,7 @@ Feature: deleting files and folders
     And file "zzzz-must-be-last-file-in-folder.txt" should not be listed on the webUI
 
   Scenario: delete files from shared with others page
-    Given user "user2" has been created with default attributes
+    Given user "user2" has been created with default attributes and without skeleton files
     Given the user has shared file "lorem.txt" with user "User Two" using the webUI
     And the user has shared folder "simple-folder" with user "User Two" using the webUI
     And the user has browsed to the shared-with-others page
diff --git a/tests/acceptance/features/webUISharingInternalGroups/shareWithGroups.feature b/tests/acceptance/features/webUISharingInternalGroups/shareWithGroups.feature
index 954c3b9db96a..4374f76c042a 100644
--- a/tests/acceptance/features/webUISharingInternalGroups/shareWithGroups.feature
+++ b/tests/acceptance/features/webUISharingInternalGroups/shareWithGroups.feature
@@ -5,11 +5,11 @@ Feature: Sharing files and folders with internal groups
   So that those groups can access the files and folders
 
   Background:
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and without skeleton files:
       | username |
       | user1    |
       | user2    |
-      | user3    |
+    And user "user3" has been created with default attributes
     And these groups have been created:
       | groupname |
       | grp1      |
@@ -23,15 +23,15 @@ Feature: Sharing files and folders with internal groups
     When the user shares folder "simple-folder" with group "grp1" using the webUI
     And the user shares file "testimage.jpg" with group "grp1" using the webUI
     And the user re-logs in as "user1" using the webUI
-    Then folder "simple-folder (2)" should be listed on the webUI
-    And folder "simple-folder (2)" should be marked as shared with "grp1" by "User Three" on the webUI
-    And file "testimage (2).jpg" should be listed on the webUI
-    And file "testimage (2).jpg" should be marked as shared with "grp1" by "User Three" on the webUI
+    Then folder "simple-folder" should be listed on the webUI
+    And folder "simple-folder" should be marked as shared with "grp1" by "User Three" on the webUI
+    And file "testimage.jpg" should be listed on the webUI
+    And file "testimage.jpg" should be marked as shared with "grp1" by "User Three" on the webUI
     When the user re-logs in as "user2" using the webUI
-    Then folder "simple-folder (2)" should be listed on the webUI
-    And folder "simple-folder (2)" should be marked as shared with "grp1" by "User Three" on the webUI
-    And file "testimage (2).jpg" should be listed on the webUI
-    And file "testimage (2).jpg" should be marked as shared with "grp1" by "User Three" on the webUI
+    Then folder "simple-folder" should be listed on the webUI
+    And folder "simple-folder" should be marked as shared with "grp1" by "User Three" on the webUI
+    And file "testimage.jpg" should be listed on the webUI
+    And file "testimage.jpg" should be marked as shared with "grp1" by "User Three" on the webUI
 
   @TestAlsoOnExternalUserBackend @skipOnFIREFOX
   Scenario: share a file with an internal group a member overwrites and unshares the file
@@ -112,19 +112,19 @@ Feature: Sharing files and folders with internal groups
     Given group "system-group" has been created
     And the administrator has browsed to the admin sharing settings page
     When the administrator excludes group "system-group" from receiving shares using the webUI
-    Then user "user1" should not be able to share file "lorem.txt" with group "system-group" using the sharing API
+    Then user "user3" should not be able to share file "lorem.txt" with group "system-group" using the sharing API
 
   Scenario: user tries to share a folder in a group which is excluded from receiving share
     Given group "system-group" has been created
     And the administrator has browsed to the admin sharing settings page
     When the administrator excludes group "system-group" from receiving shares using the webUI
-    Then user "user1" should not be able to share folder "simple-folder" with group "system-group" using the sharing API
+    Then user "user3" should not be able to share folder "simple-folder" with group "system-group" using the sharing API
 
   Scenario: autocompletion for a group that is excluded from receiving shares
     Given group "system-group" has been created
     And the administrator has browsed to the admin sharing settings page
     When the administrator excludes group "system-group" from receiving shares using the webUI
-    And the user re-logs in as "user1" using the webUI
+    And the user re-logs in as "user3" using the webUI
     And the user browses to the files page
     And the user opens the share dialog for folder "simple-folder"
     And the user types "system-group" in the share-with-field
@@ -184,7 +184,7 @@ Feature: Sharing files and folders with internal groups
   @mailhog
   Scenario: user should get an error message when trying to send notification by email to the group where some user have set up their email and others haven't
     Given parameter "shareapi_allow_mail_notification" of app "core" has been set to "yes"
-    And these users have been created:
+    And these users have been created without skeleton files:
       | username           |
       | brand-new-user     |
       | off-brand-new-user |
diff --git a/tests/acceptance/features/webUISharingInternalGroups/shareWithGroupsEdgeCases.feature b/tests/acceptance/features/webUISharingInternalGroups/shareWithGroupsEdgeCases.feature
index 7644a42c951d..5223ce661beb 100644
--- a/tests/acceptance/features/webUISharingInternalGroups/shareWithGroupsEdgeCases.feature
+++ b/tests/acceptance/features/webUISharingInternalGroups/shareWithGroupsEdgeCases.feature
@@ -5,11 +5,11 @@ Feature: Sharing files and folders with internal groups
   So that those groups can access the files and folders
 
   Scenario Outline: sharing  files and folder with an internal problematic group name
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and without skeleton files:
       | username |
       | user1    |
       | user2    |
-      | user3    |
+    And user "user3" has been created with default attributes
     And these groups have been created:
       | groupname |
       | <group>   |
@@ -19,15 +19,15 @@ Feature: Sharing files and folders with internal groups
     When the user shares folder "simple-folder" with group "<group>" using the webUI
     And the user shares file "testimage.jpg" with group "<group>" using the webUI
     And the user re-logs in as "user1" using the webUI
-    Then folder "simple-folder (2)" should be listed on the webUI
-    And folder "simple-folder (2)" should be marked as shared with "<group>" by "User Three" on the webUI
-    And file "testimage (2).jpg" should be listed on the webUI
-    And file "testimage (2).jpg" should be marked as shared with "<group>" by "User Three" on the webUI
+    Then folder "simple-folder" should be listed on the webUI
+    And folder "simple-folder" should be marked as shared with "<group>" by "User Three" on the webUI
+    And file "testimage.jpg" should be listed on the webUI
+    And file "testimage.jpg" should be marked as shared with "<group>" by "User Three" on the webUI
     When the user re-logs in as "user2" using the webUI
-    Then folder "simple-folder (2)" should be listed on the webUI
-    And folder "simple-folder (2)" should be marked as shared with "<group>" by "User Three" on the webUI
-    And file "testimage (2).jpg" should be listed on the webUI
-    And file "testimage (2).jpg" should be marked as shared with "<group>" by "User Three" on the webUI
+    Then folder "simple-folder" should be listed on the webUI
+    And folder "simple-folder" should be marked as shared with "<group>" by "User Three" on the webUI
+    And file "testimage.jpg" should be listed on the webUI
+    And file "testimage.jpg" should be marked as shared with "<group>" by "User Three" on the webUI
     Examples:
       | group     |
       | ?\?@#%@,; |

From 8366c4b2dfa9a601b8f7002aa7a5f7d13c7ee27d Mon Sep 17 00:00:00 2001
From: paurakhsharma <paurakh011@gmail.com>
Date: Fri, 31 May 2019 15:24:24 +0545
Subject: [PATCH 072/131] apiShareManagementBasic don't user skeleton files
 when not required

---
 .../createShare.feature                       | 44 ++++++++++---------
 .../deleteShare.feature                       | 40 ++++++++++++++---
 .../updateShare.feature                       | 30 ++++++++-----
 3 files changed, 74 insertions(+), 40 deletions(-)

diff --git a/tests/acceptance/features/apiShareManagementBasic/createShare.feature b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
index b68e5577d5ec..a184d915bc4e 100644
--- a/tests/acceptance/features/apiShareManagementBasic/createShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
@@ -9,7 +9,7 @@ Feature: sharing
   @skipOnEncryptionType:user-keys @issue-32322
   Scenario Outline: Creating a new share with user
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
     When user "user0" shares file "welcome.txt" with user "user1" using the sharing API
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
@@ -43,7 +43,7 @@ Feature: sharing
 
   Scenario Outline: Creating a new share with user who already received a share through their group
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
     And user "user0" has shared file "welcome.txt" with group "grp1"
@@ -146,7 +146,7 @@ Feature: sharing
 
   Scenario Outline: Creating a new share with a disabled user
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
     And user "user0" has been disabled
     When user "user0" shares file "welcome.txt" with user "user1" using the sharing API
     Then the OCS status code should be "<ocs_status_code>"
@@ -158,7 +158,7 @@ Feature: sharing
   @issue-32068
   Scenario: Creating a new share with a disabled user
     Given using OCS API version "2"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
     And user "user0" has been disabled
     When user "user0" shares file "welcome.txt" with user "user1" using the sharing API
     Then the OCS status code should be "997"
@@ -342,7 +342,7 @@ Feature: sharing
 
   Scenario Outline: sharing subfolder when parent already shared
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
     And group "grp1" has been created
     And user "user0" has created folder "/test"
     And user "user0" has created folder "/test/sub"
@@ -358,7 +358,7 @@ Feature: sharing
 
   Scenario Outline: sharing subfolder when parent already shared with group of sharer
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
     And group "grp1" has been created
     And user "user0" has been added to group "grp1"
     And user "user0" has created folder "/test"
@@ -375,10 +375,12 @@ Feature: sharing
 
   Scenario Outline: sharing subfolder of already shared folder, GET result is correct
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
-    And user "user3" has been created with default attributes
-    And user "user4" has been created with default attributes
+    And these users have been created with default attributes and without skeleton files:
+      | username |
+      | user1    |
+      | user2    |
+      | user3    |
+      | user4    |
     And user "user0" has created folder "/folder1"
     And user "user0" has shared file "/folder1" with user "user1"
     And user "user0" has shared file "/folder1" with user "user2"
@@ -404,7 +406,7 @@ Feature: sharing
   @issue-33733
   Scenario Outline: Cannot create share with zero permissions
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
     When user "user0" sends HTTP method "POST" to OCS API endpoint "/apps/files_sharing/api/v1/shares" with body
       | path        | welcome.txt |
       | shareWith   | user1       |
@@ -421,7 +423,7 @@ Feature: sharing
   @issue-33733 @skipOnLDAP @user_ldap-issue-378
   Scenario Outline: user who is excluded from sharing tries to share a file with another user
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
     And group "excludedFromSharing" has been created
     And user "user0" has been added to group "excludedFromSharing"
     And parameter "shareapi_exclude_groups" of app "core" has been set to "yes"
@@ -441,7 +443,7 @@ Feature: sharing
   @issue-33733
   Scenario Outline: user who is excluded from sharing tries to share a file with a group
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
     And group "excludedFromSharing" has been created
     And group "anotherGroup" has been created
     And user "user0" has been added to group "excludedFromSharing"
@@ -463,7 +465,7 @@ Feature: sharing
   @issue-33733 @skipOnLDAP @user_ldap-issue-378
   Scenario Outline: user who is excluded from sharing tries to share a folder with another user
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
     And group "excludedFromSharing" has been created
     And user "user0" has been added to group "excludedFromSharing"
     And parameter "shareapi_exclude_groups" of app "core" has been set to "yes"
@@ -483,7 +485,7 @@ Feature: sharing
   @issue-33733
   Scenario Outline: user who is excluded from sharing tries to share a folder with a group
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
     And group "excludedFromSharing" has been created
     And group "anotherGroup" has been created
     And user "user0" has been added to group "excludedFromSharing"
@@ -504,7 +506,7 @@ Feature: sharing
 
   Scenario Outline: user shares a file with file name longer than 64 chars to another user
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
     And user "user0" has moved file "welcome.txt" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt"
     When user "user0" shares file "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" with user "user1" using the sharing API
     Then the OCS status code should be "<ocs_status_code>"
@@ -518,7 +520,7 @@ Feature: sharing
   Scenario Outline: user shares a file with file name longer than 64 chars to a group
     Given using OCS API version "<ocs_api_version>"
     And group "grp1" has been created
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
     And user "user1" has been added to group "grp1"
     And user "user0" has moved file "welcome.txt" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt"
     When user "user0" shares file "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" with group "grp1" using the sharing API
@@ -532,7 +534,7 @@ Feature: sharing
 
   Scenario Outline: user shares a folder with folder name longer than 64 chars to another user
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
     And user "user0" has created folder "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog"
     And user "user0" has moved file "welcome.txt" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog/welcome.txt"
     When user "user0" shares folder "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" with user "user1" using the sharing API
@@ -547,7 +549,7 @@ Feature: sharing
   Scenario Outline: user shares a folder with folder name longer than 64 chars to a group
     Given using OCS API version "<ocs_api_version>"
     And group "grp1" has been created
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
     And user "user1" has been added to group "grp1"
     And user "user0" has created folder "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog"
     And user "user0" has moved file "welcome.txt" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog/welcome.txt"
@@ -591,7 +593,7 @@ Feature: sharing
 
   @skipOnEncryption @issue-encryption-126
   Scenario: share with user when username contains capital letters
-    Given these users have been created:
+    Given these users have been created without skeleton files:
       | username |
       | user1    |
     When user "user0" shares file "/welcome.txt" with user "USER1" using the sharing API
@@ -607,7 +609,7 @@ Feature: sharing
       | /welcome.txt |
 
   Scenario: creating a new share with user of a group when username contains capital letters
-    Given these users have been created:
+    Given these users have been created without skeleton files:
       | username |
       | user1    |
     And group "grp1" has been created
diff --git a/tests/acceptance/features/apiShareManagementBasic/deleteShare.feature b/tests/acceptance/features/apiShareManagementBasic/deleteShare.feature
index 3a96e6742714..baaf26517c8c 100644
--- a/tests/acceptance/features/apiShareManagementBasic/deleteShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/deleteShare.feature
@@ -3,11 +3,11 @@ Feature: sharing
 
   Background:
     Given using old DAV path
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
 
   Scenario Outline: Delete all group shares
-    Given using OCS API version "<ocs_api_version>"
+    Given user "user0" has been created with default attributes
+    And user "user1" has been created with default attributes
+    And using OCS API version "<ocs_api_version>"
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
     And user "user0" has shared file "textfile0.txt" with group "grp1"
@@ -23,7 +23,9 @@ Feature: sharing
 
   @smokeTest
   Scenario Outline: delete a share
-    Given using OCS API version "<ocs_api_version>"
+    Given user "user0" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
+    And using OCS API version "<ocs_api_version>"
     And user "user0" has shared file "textfile0.txt" with user "user1"
     When user "user0" deletes the last share using the sharing API
     Then the OCS status code should be "<ocs_status_code>"
@@ -36,6 +38,10 @@ Feature: sharing
 
   Scenario: orphaned shares
     Given using OCS API version "1"
+    And these users have been created with default attributes and without skeleton files:
+      | username |
+      | user0    |
+      | user1    |
     And a new browser session for "user0" has been started
     And user "user0" has created folder "/common"
     And user "user0" has created folder "/common/sub"
@@ -46,9 +52,13 @@ Feature: sharing
 
   Scenario Outline: sharing subfolder of already shared folder, GET result is correct
     Given using OCS API version "<ocs_api_version>"
-    And user "user2" has been created with default attributes
-    And user "user3" has been created with default attributes
-    And user "user4" has been created with default attributes
+    And these users have been created with default attributes and without skeleton files:
+      | username |
+      | user0    |
+      | user1    |
+      | user2    |
+      | user3    |
+      | user4    |
     And user "user0" has created folder "/folder1"
     And user "user0" has shared file "/folder1" with user "user1"
     And user "user0" has shared file "/folder1" with user "user2"
@@ -76,6 +86,8 @@ Feature: sharing
   @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 "user0" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
     And user "user0" has created folder "/shared"
     And user "user0" has moved file "/textfile0.txt" to "/shared/shared_file.txt"
     And user "user0" has shared folder "/shared" with user "user1"
@@ -89,6 +101,8 @@ Feature: sharing
   @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 "user0" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
     And user "user0" has created folder "/shared"
     And user "user0" has created folder "/shared/sub"
     And user "user0" has moved file "/textfile0.txt" to "/shared/sub/shared_file.txt"
@@ -106,6 +120,10 @@ Feature: sharing
   Scenario Outline: unshare from self
     Given using OCS API version "<ocs_api_version>"
     And group "grp1" has been created
+    And these users have been created with default attributes and without skeleton files:
+      | username |
+      | user0    |
+      | user1    |
     And user "user2" has been created with default attributes
     And user "user2" has been added to group "grp1"
     And user "user1" has been added to group "grp1"
@@ -124,6 +142,8 @@ Feature: sharing
 
   Scenario: sharee of a read-only share folder tries to delete the shared folder
     Given using OCS API version "1"
+    And user "user0" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
     And user "user0" has created folder "/shared"
     And user "user0" has moved file "/textfile0.txt" to "/shared/shared_file.txt"
     And user "user0" has shared folder "shared" with user "user1" with permissions 1
@@ -133,6 +153,8 @@ Feature: sharing
 
   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 "user0" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
     And user "user0" has created folder "/shared"
     And user "user0" has moved file "/textfile0.txt" to "/shared/shared_file.txt"
     And user "user0" has shared folder "shared" with user "user1" with permissions 4
@@ -142,6 +164,10 @@ Feature: sharing
 
   Scenario: sharee of an upload-only shared folder tries to delete their file in the folder
     Given using OCS API version "1"
+    And these users have been created with default attributes and without skeleton files:
+      | username |
+      | user0    |
+      | user1    |
     And user "user0" has created folder "/shared"
     And user "user0" has shared folder "shared" with user "user1" with permissions 4
     When user "user1" uploads file "filesForUpload/textfile.txt" to "shared/textfile.txt" using the WebDAV API
diff --git a/tests/acceptance/features/apiShareManagementBasic/updateShare.feature b/tests/acceptance/features/apiShareManagementBasic/updateShare.feature
index c37597cf0ea7..3a7d24fca566 100644
--- a/tests/acceptance/features/apiShareManagementBasic/updateShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/updateShare.feature
@@ -9,8 +9,10 @@ Feature: sharing
   @smokeTest
   Scenario Outline: Allow modification of reshare
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    And these users have been created with default attributes and without skeleton files:
+      | username |
+      | user1    |
+      | user2    |
     And user "user0" has created folder "/TMP"
     And user "user0" has shared folder "TMP" with user "user1"
     And user "user1" has shared folder "TMP" with user "user2"
@@ -276,7 +278,7 @@ Feature: sharing
   @public_link_share-feature-required
   Scenario Outline: Adding public upload to a read only shared folder as recipient is not allowed
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
     And user "user0" has created folder "/test"
     And user "user0" has shared folder "/test" with user "user1" with permissions 17
     And as user "user1"
@@ -307,8 +309,10 @@ Feature: sharing
       | 2               | 400              |
 
   Scenario: Share ownership change after moving a shared file outside of an outer share
-    Given user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    Given these users have been created with default attributes and without skeleton files:
+      | username |
+      | user1    |
+      | user2    |
     And user "user0" has created folder "/folder1"
     And user "user0" has created folder "/folder1/folder2"
     And user "user1" has created folder "/moved-out"
@@ -335,8 +339,10 @@ Feature: sharing
     And as "user2" folder "/folder2" should exist
 
   Scenario: Share ownership change after moving a shared file to another share
-    Given user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    Given these users have been created with default attributes and without skeleton files:
+      | username |
+      | user1    |
+      | user2    |
     And user "user0" has created folder "/user0-folder"
     And user "user0" has created folder "/user0-folder/folder2"
     And user "user2" has created folder "/user2-folder"
@@ -365,7 +371,7 @@ Feature: sharing
   @public_link_share-feature-required
   Scenario Outline: Adding public upload to a shared folder as recipient is allowed with permissions
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
     And user "user0" has created folder "/test"
     And user "user0" has shared folder "/test" with user "user1" with permissions 31
     And as user "user1"
@@ -385,7 +391,7 @@ Feature: sharing
   @public_link_share-feature-required
   Scenario Outline: Adding public upload to a read only shared folder as recipient is not allowed
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
     And user "user0" has created folder "/test"
     And user "user0" has shared folder "/test" with user "user1" with permissions 17
     And as user "user1"
@@ -405,7 +411,7 @@ Feature: sharing
   @public_link_share-feature-required
   Scenario Outline: Adding public upload to a shared folder as recipient is allowed with permissions
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
     And user "user0" has created folder "/test"
     And user "user0" has shared folder "/test" with user "user1" with permissions 31
     And as user "user1"
@@ -424,7 +430,7 @@ Feature: sharing
 
   Scenario Outline: Increasing permissions is allowed for owner
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and without skeleton files
     And user "user2" has been created with default attributes
     And group "grp1" has been created
     And user "user2" has been added to group "grp1"
@@ -481,4 +487,4 @@ Feature: sharing
     Examples:
       | ocs_api_version | ocs_status_code |
       | 1               | 100             |
-      | 2               | 200             |
\ No newline at end of file
+      | 2               | 200             |

From 34c2041f13ba4cb799a1cf9ac1e1968ac8dea064 Mon Sep 17 00:00:00 2001
From: Saugat Pachhai <suagatchhetri@outlook.com>
Date: Tue, 4 Jun 2019 16:15:26 +0545
Subject: [PATCH 073/131] Get rid of setting configs via WebUISharingContext

We already set the capabilities via FeatureContext on both fed and local servers.
The same settings were run twice causing conflicts, causing some of the enabled
configs to get disabled. The settings are already tracked.
---
 .../bootstrap/WebUISharingContext.php         | 92 -------------------
 1 file changed, 92 deletions(-)

diff --git a/tests/acceptance/features/bootstrap/WebUISharingContext.php b/tests/acceptance/features/bootstrap/WebUISharingContext.php
index dfe779def359..0b2e94ed92b5 100644
--- a/tests/acceptance/features/bootstrap/WebUISharingContext.php
+++ b/tests/acceptance/features/bootstrap/WebUISharingContext.php
@@ -1401,7 +1401,6 @@ public function before(BeforeScenarioScope $scope) {
 		$this->featureContext = $environment->getContext('FeatureContext');
 		$this->webUIGeneralContext = $environment->getContext('WebUIGeneralContext');
 		$this->webUIFilesContext = $environment->getContext('WebUIFilesContext');
-		$this->setupSharingConfigs();
 	}
 
 	/**
@@ -1435,95 +1434,4 @@ public function tearDownScenario() {
 			);
 		}
 	}
-
-	/**
-	 * @return void
-	 */
-	private function setupSharingConfigs() {
-		$settings = [
-			[
-				'capabilitiesApp' => 'files_sharing',
-				'capabilitiesParameter' => 'api_enabled',
-				'testingApp' => 'core',
-				'testingParameter' => 'shareapi_enabled',
-				'testingState' => true
-			],
-			[
-				'capabilitiesApp' => 'files_sharing',
-				'capabilitiesParameter' => 'public@@@enabled',
-				'testingApp' => 'core',
-				'testingParameter' => 'shareapi_allow_links',
-				'testingState' => true
-			],
-			[
-				'capabilitiesApp' => 'files_sharing',
-				'capabilitiesParameter' => 'public@@@upload',
-				'testingApp' => 'core',
-				'testingParameter' => 'shareapi_allow_public_upload',
-				'testingState' => true
-			],
-			[
-				'capabilitiesApp' => 'files_sharing',
-				'capabilitiesParameter' => 'group_sharing',
-				'testingApp' => 'core',
-				'testingParameter' => 'shareapi_allow_group_sharing',
-				'testingState' => true
-			],
-			[
-				'capabilitiesApp' => 'files_sharing',
-				'capabilitiesParameter' => 'share_with_group_members_only',
-				'testingApp' => 'core',
-				'testingParameter' => 'shareapi_only_share_with_group_members',
-				'testingState' => false
-			],
-			[
-				'capabilitiesApp' => 'files_sharing',
-				'capabilitiesParameter' => 'share_with_membership_groups_only',
-				'testingApp' => 'core',
-				'testingParameter' => 'shareapi_only_share_with_membership_groups',
-				'testingState' => false
-			],
-			[
-				'capabilitiesApp' => 'files_sharing',
-				'capabilitiesParameter' =>
-					'user_enumeration@@@enabled',
-				'testingApp' => 'core',
-				'testingParameter' =>
-					'shareapi_allow_share_dialog_user_enumeration',
-				'testingState' => true
-			],
-			[
-				'capabilitiesApp' => 'files_sharing',
-				'capabilitiesParameter' =>
-					'user_enumeration@@@group_members_only',
-				'testingApp' => 'core',
-				'testingParameter' =>
-					'shareapi_share_dialog_user_enumeration_group_members',
-				'testingState' => false
-			],
-			[
-				'capabilitiesApp' => 'federation',
-				'capabilitiesParameter' => 'outgoing',
-				'testingApp' => 'files_sharing',
-				'testingParameter' => 'outgoing_server2server_share_enabled',
-				'testingState' => true
-			],
-			[
-				'capabilitiesApp' => 'federation',
-				'capabilitiesParameter' => 'incoming',
-				'testingApp' => 'files_sharing',
-				'testingParameter' => 'incoming_server2server_share_enabled',
-				'testingState' => true
-			]
-		];
-
-		$change = AppConfigHelper::setCapabilities(
-			$this->featureContext->getBaseUrl(),
-			$this->featureContext->getAdminUsername(),
-			$this->featureContext->getAdminPassword(),
-			$settings,
-			$this->webUIGeneralContext->getSavedCapabilitiesXml()[$this->featureContext->getBaseUrl()]
-		);
-		$this->webUIGeneralContext->addToSavedCapabilitiesChanges($change);
-	}
 }

From 0a78a7e460113cb0d71a4e417965be355eaefe01 Mon Sep 17 00:00:00 2001
From: bhawana <bhawana.prs@gmail.com>
Date: Wed, 22 May 2019 14:32:07 +0545
Subject: [PATCH 074/131] Acceptance test for sharing folders with groups
 having emoji in their name

---
 .../createShare.feature                       | 30 +++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/tests/acceptance/features/apiShareManagementBasic/createShare.feature b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
index a184d915bc4e..a4c8d17f9e95 100644
--- a/tests/acceptance/features/apiShareManagementBasic/createShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
@@ -619,3 +619,33 @@ Feature: sharing
     And the HTTP status code should be "200"
     And user "user1" should see the following elements
       | /welcome.txt |
+
+  Scenario Outline: Share of folder to a group with emoji in the name
+    Given using OCS API version "<ocs_api_version>"
+    And user "user1" has been created with default attributes
+    And user "user2" has been created with default attributes
+    And group "😀 😁" has been created
+    And user "user1" has been added to group "😀 😁"
+    And user "user2" has been added to group "😀 😁"
+    When user "user0" shares folder "/PARENT" with group "😀 😁" using the sharing API
+    Then user "user1" should see the following elements
+      | /FOLDER/                 |
+      | /PARENT/                 |
+      | /PARENT/parent.txt       |
+      | /PARENT%20(2)/           |
+      | /PARENT%20(2)/parent.txt |
+    And the OCS status code should be "<ocs_status_code>"
+    And the HTTP status code should be "200"
+    And user "user2" should see the following elements
+      | /FOLDER/                 |
+      | /PARENT/                 |
+      | /PARENT/parent.txt       |
+      | /PARENT%20(2)/           |
+      | /PARENT%20(2)/parent.txt |
+    And the OCS status code should be "<ocs_status_code>"
+    And the HTTP status code should be "200"
+    Examples:
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
+    
\ No newline at end of file

From 3de569fa7ca5f153ac24f5bec17ae459a0d460c3 Mon Sep 17 00:00:00 2001
From: bhawana <bhawana.prs@gmail.com>
Date: Thu, 23 May 2019 15:35:07 +0545
Subject: [PATCH 075/131] Acceptance test for creating password with emoji

---
 .../apiProvisioning-v1/resetUserPassword.feature | 16 ++++++++++++++++
 .../apiProvisioning-v2/resetUserPassword.feature | 16 ++++++++++++++++
 .../changePasswordFromSetting.feature            |  2 +-
 3 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/tests/acceptance/features/apiProvisioning-v1/resetUserPassword.feature b/tests/acceptance/features/apiProvisioning-v1/resetUserPassword.feature
index dd9d1c7a22a2..b320facd5d0e 100644
--- a/tests/acceptance/features/apiProvisioning-v1/resetUserPassword.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/resetUserPassword.feature
@@ -71,3 +71,19 @@ Feature: reset user password
     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"
+
+  Scenario Outline: reset user password including emoji
+    Given these users have been created:
+      | username       | password  | displayname | email                    |
+      | brand-new-user | %regular% | New user    | brand.new.user@oc.com.np |
+    When the administrator resets the password of user "brand-new-user" to "<password>" using the provisioning API
+    Then the OCS status code should be "100"
+    And the HTTP status code should be "200"
+    And the content of file "textfile0.txt" for user "brand-new-user" using password "<password>" should be "ownCloud test text file 0" plus end-of-line
+    Examples:
+      | password        | comment  |
+      | 😛 😜           | smileys  |
+      | 🐶🐱 🐭           | Animals  |
+      | ⌚️ 📱 📲 💻           | objects  |
+      | 🚴🏿‍♀️ 🚴‍♂️            | cycling |
+    But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt"
\ No newline at end of file
diff --git a/tests/acceptance/features/apiProvisioning-v2/resetUserPassword.feature b/tests/acceptance/features/apiProvisioning-v2/resetUserPassword.feature
index 16bc6c3f760a..40209b88e575 100644
--- a/tests/acceptance/features/apiProvisioning-v2/resetUserPassword.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/resetUserPassword.feature
@@ -71,3 +71,19 @@ Feature: reset user password
     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"
+
+  Scenario Outline: reset user password including emoji
+    Given these users have been created:
+      | username       | password  | displayname | email                    |
+      | brand-new-user | %regular% | New user    | brand.new.user@oc.com.np |
+    When the administrator resets the password of user "brand-new-user" to "<password>" using the provisioning API
+    Then the OCS status code should be "200"
+    And the HTTP status code should be "200"
+    And the content of file "textfile0.txt" for user "brand-new-user" using password "<password>" should be "ownCloud test text file 0" plus end-of-line
+    Examples:
+      | password        | comment  |
+      | 😛 😜           | smileys  |
+      | 🐶🐱 🐭           | Animals  |
+      | ⌚️ 📱 📲 💻           | objects  |
+      | 🚴🏿‍♀️ 🚴‍♂️            | cycling |
+    But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt"
\ No newline at end of file
diff --git a/tests/acceptance/features/webUIPersonalSettings/changePasswordFromSetting.feature b/tests/acceptance/features/webUIPersonalSettings/changePasswordFromSetting.feature
index 2285dd65e348..89841d7115de 100644
--- a/tests/acceptance/features/webUIPersonalSettings/changePasswordFromSetting.feature
+++ b/tests/acceptance/features/webUIPersonalSettings/changePasswordFromSetting.feature
@@ -21,4 +21,4 @@ Feature: Change Login Password
 
   Scenario: New password is same as current password
     When the user changes the password to "%alt1%" using the webUI
-    Then a password error message should be displayed on the webUI with the text "The new password cannot be the same as the previous one"
\ No newline at end of file
+    Then a password error message should be displayed on the webUI with the text "The new password cannot be the same as the previous one"

From 6b0e21fc70d70df0ee44ee4c705020ba040c92ba Mon Sep 17 00:00:00 2001
From: Artur Neumann <artur@jankaritech.com>
Date: Wed, 5 Jun 2019 11:38:16 +0545
Subject: [PATCH 076/131] skip tests on encryption that fail because of a known
 issue

---
 .../features/apiProvisioning-v1/resetUserPassword.feature      | 3 ++-
 .../features/apiProvisioning-v2/resetUserPassword.feature      | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/tests/acceptance/features/apiProvisioning-v1/resetUserPassword.feature b/tests/acceptance/features/apiProvisioning-v1/resetUserPassword.feature
index b320facd5d0e..3e799473868e 100644
--- a/tests/acceptance/features/apiProvisioning-v1/resetUserPassword.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/resetUserPassword.feature
@@ -72,6 +72,7 @@ Feature: reset user password
     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:
       | username       | password  | displayname | email                    |
@@ -80,10 +81,10 @@ Feature: reset user password
     Then the OCS status code should be "100"
     And the HTTP status code should be "200"
     And the content of file "textfile0.txt" for user "brand-new-user" using password "<password>" should be "ownCloud test text file 0" plus end-of-line
+    But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt"
     Examples:
       | password        | comment  |
       | 😛 😜           | smileys  |
       | 🐶🐱 🐭           | Animals  |
       | ⌚️ 📱 📲 💻           | objects  |
       | 🚴🏿‍♀️ 🚴‍♂️            | cycling |
-    But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt"
\ No newline at end of file
diff --git a/tests/acceptance/features/apiProvisioning-v2/resetUserPassword.feature b/tests/acceptance/features/apiProvisioning-v2/resetUserPassword.feature
index 40209b88e575..605087c102ef 100644
--- a/tests/acceptance/features/apiProvisioning-v2/resetUserPassword.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/resetUserPassword.feature
@@ -72,6 +72,7 @@ Feature: reset user password
     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:
       | username       | password  | displayname | email                    |
@@ -80,10 +81,10 @@ Feature: reset user password
     Then the OCS status code should be "200"
     And the HTTP status code should be "200"
     And the content of file "textfile0.txt" for user "brand-new-user" using password "<password>" should be "ownCloud test text file 0" plus end-of-line
+    But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt"
     Examples:
       | password        | comment  |
       | 😛 😜           | smileys  |
       | 🐶🐱 🐭           | Animals  |
       | ⌚️ 📱 📲 💻           | objects  |
       | 🚴🏿‍♀️ 🚴‍♂️            | cycling |
-    But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt"
\ No newline at end of file

From 50cd7f84733123eeb5f0b50a45d0229e949dcba0 Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Fri, 31 May 2019 14:08:19 +0545
Subject: [PATCH 077/131] sharing with user with uppercase username

---
 .../shareWithUsers.feature                          | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature b/tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature
index 65c036facd97..b138ca0e61dc 100644
--- a/tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature
+++ b/tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature
@@ -328,3 +328,16 @@ Feature: Sharing files and folders with internal users
     And user "user1" has shared file "lorem.txt" with user "user2"
     When the user opens the share dialog for file "lorem.txt"
     Then the user should not be able to send the share notification by email using the webUI
+
+  @issue-35382
+  Scenario: user shares a file with another user with uppercase username
+    Given user "user1" has been created with default attributes
+    And these users have been created without skeleton files:
+      | username |
+      | SomeUser |
+    And user "user1" has logged in using the webUI
+    When the user shares file "lorem.txt" with user "SomeUser" using the webUI
+    And the user re-logs in as "SomeUser" using the webUI
+    And the user browses to the shared-with-you page
+    Then file "lorem.txt" should not be listed on the webUI
+#    Then file "lorem.txt" should be listed on the webUI

From 3169b5222c0495031c375d7f2f031becbd2dda5b Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Thu, 30 May 2019 12:09:29 +0545
Subject: [PATCH 078/131] cli test for security certificates

---
 .../features/bootstrap/CommandLine.php        |  1 -
 .../features/bootstrap/OccContext.php         | 54 +++++++++++++++++++
 .../cliMain/securityCertificates.feature      | 43 +++++++++++++++
 3 files changed, 97 insertions(+), 1 deletion(-)
 create mode 100644 tests/acceptance/features/cliMain/securityCertificates.feature

diff --git a/tests/acceptance/features/bootstrap/CommandLine.php b/tests/acceptance/features/bootstrap/CommandLine.php
index 2a4b74fc3adf..65a132d6523d 100644
--- a/tests/acceptance/features/bootstrap/CommandLine.php
+++ b/tests/acceptance/features/bootstrap/CommandLine.php
@@ -334,7 +334,6 @@ public function findLines($input, $text) {
 				$results[] = $line;
 			}
 		}
-
 		return $results;
 	}
 
diff --git a/tests/acceptance/features/bootstrap/OccContext.php b/tests/acceptance/features/bootstrap/OccContext.php
index 8f5a4f30c0d4..8fcbe4fe516a 100644
--- a/tests/acceptance/features/bootstrap/OccContext.php
+++ b/tests/acceptance/features/bootstrap/OccContext.php
@@ -38,6 +38,18 @@ class OccContext implements Context {
 	 */
 	private $featureContext;
 
+	/**
+	 *
+	 * @var ImportedCertificates
+	 */
+	private $importedCertificates = [];
+
+	/**
+	 *
+	 * @var RemovedCertificates
+	 */
+	private $removedCertificates = [];
+
 	/**
 	 * @var string lastDeletedJobId
 	 */
@@ -55,6 +67,33 @@ public function invokingTheCommand($cmd) {
 		$this->featureContext->runOcc([$cmd]);
 	}
 
+	/**
+	 * @When the administrator imports security certificate form the path :path
+	 * @Given the administrator has imported security certificate form the path :path
+	 *
+	 * @param string $path
+	 *
+	 * @return void
+	 */
+	public function theAdministratorImportsSecurityCertificateFormThePath($path) {
+		$this->invokingTheCommand("security:certificates:import " . $path);
+		$pathComponents = \explode("/", $path);
+		$certificate = \end($pathComponents);
+		\array_push($this->importedCertificates, $certificate);
+	}
+
+	/**
+	 * @When the administrator removes the security certificate :certificate
+	 *
+	 * @param string $certificate
+	 *
+	 * @return void
+	 */
+	public function theAdministratorRemovesTheSecurityCertificate($certificate) {
+		$this->invokingTheCommand("security:certificates:remove " . $certificate);
+		\array_push($this->removedCertificates, $certificate);
+	}
+
 	/**
 	 * @When /^the administrator invokes occ command "([^"]*)" with environment variable "([^"]*)" set to "([^"]*)"$/
 	 * @Given /^the administrator has invoked occ command "([^"]*)" with environment variable "([^"]*)" set to "([^"]*)"$/
@@ -846,6 +885,21 @@ public function theSystemConfigKeyFromLastCommandOutputShouldContainValue(
 		);
 	}
 
+	/**
+	 * This will run after EVERY scenario.
+	 * It will set the properties for this object.
+	 *
+	 * @AfterScenario
+	 *
+	 * @return void
+	 */
+	public function removeImportedCertificates() {
+		$remainingCertificates = \array_diff($this->importedCertificates, $this->removedCertificates);
+		foreach ($remainingCertificates as $certificate) {
+			$this->invokingTheCommand("security:certificates:remove " . $certificate);
+			$this->theCommandShouldHaveBeenSuccessful();
+		}
+	}
 	/**
 	 * This will run before EVERY scenario.
 	 * It will set the properties for this object.
diff --git a/tests/acceptance/features/cliMain/securityCertificates.feature b/tests/acceptance/features/cliMain/securityCertificates.feature
new file mode 100644
index 000000000000..11a6922c2daf
--- /dev/null
+++ b/tests/acceptance/features/cliMain/securityCertificates.feature
@@ -0,0 +1,43 @@
+@cli
+Feature: security certificates
+  As an admin
+  I want to be able to manage the ownCloud security certificates
+  So that I can ensure the proper encrpytion mechanism
+
+  Scenario: Import a security certificate
+    When the administrator imports security certificate form the path "tests/data/certificates/goodCertificate.crt"
+    Then the command should have been successful
+    When the administrator invokes occ command "security:certificates"
+    Then the command should have been successful
+    And the command output table should contain the following text:
+      | table_column         |
+      | goodCertificate.crt  |
+
+  Scenario: List security certificates when multiple certificates are imported
+    Given the administrator has imported security certificate form the path "tests/data/certificates/goodCertificate.crt"
+    And the administrator has imported security certificate form the path "tests/data/certificates/badCertificate.crt"
+    When the administrator invokes occ command "security:certificates"
+    And the command output table should contain the following text:
+    | table_column         |
+    | goodCertificate.crt  |
+    | badCertificate.crt   |
+
+  Scenario: Remove a security certificate
+    Given the administrator has imported security certificate form the path "tests/data/certificates/goodCertificate.crt"
+    And the administrator has imported security certificate form the path "tests/data/certificates/badCertificate.crt"
+    When the administrator removes the security certificate "goodCertificate.crt"
+    Then the command should have been successful
+    When the administrator invokes occ command "security:certificates"
+    And the command output table should contain the following text:
+      | table_column         |
+      | badCertificate.crt   |
+
+  @issue-35364
+  Scenario: Remove a security certificate that is not installed
+    When the administrator removes the security certificate "someCertificate.crt"
+    Then the command should have been successful
+    # Then the command should not have been successful
+
+  Scenario: Import random file as certificate
+    When the administrator imports security certificate form the path "tests/data/lorem.txt"
+    Then the command error output should contain the text "Certificate could not get parsed."
\ No newline at end of file

From a1018135aecdc18a2a6df83bd46c8b246fc494d4 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Wed, 5 Jun 2019 12:59:09 +0545
Subject: [PATCH 079/131] Change 'form the path' to 'from the path'

---
 tests/acceptance/features/bootstrap/OccContext.php   |  6 +++---
 .../features/cliMain/securityCertificates.feature    | 12 ++++++------
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/tests/acceptance/features/bootstrap/OccContext.php b/tests/acceptance/features/bootstrap/OccContext.php
index 8fcbe4fe516a..c9133c02b57a 100644
--- a/tests/acceptance/features/bootstrap/OccContext.php
+++ b/tests/acceptance/features/bootstrap/OccContext.php
@@ -68,14 +68,14 @@ public function invokingTheCommand($cmd) {
 	}
 
 	/**
-	 * @When the administrator imports security certificate form the path :path
-	 * @Given the administrator has imported security certificate form the path :path
+	 * @When the administrator imports security certificate from the path :path
+	 * @Given the administrator has imported security certificate from the path :path
 	 *
 	 * @param string $path
 	 *
 	 * @return void
 	 */
-	public function theAdministratorImportsSecurityCertificateFormThePath($path) {
+	public function theAdministratorImportsSecurityCertificateFromThePath($path) {
 		$this->invokingTheCommand("security:certificates:import " . $path);
 		$pathComponents = \explode("/", $path);
 		$certificate = \end($pathComponents);
diff --git a/tests/acceptance/features/cliMain/securityCertificates.feature b/tests/acceptance/features/cliMain/securityCertificates.feature
index 11a6922c2daf..a0aac967b5f2 100644
--- a/tests/acceptance/features/cliMain/securityCertificates.feature
+++ b/tests/acceptance/features/cliMain/securityCertificates.feature
@@ -5,7 +5,7 @@ Feature: security certificates
   So that I can ensure the proper encrpytion mechanism
 
   Scenario: Import a security certificate
-    When the administrator imports security certificate form the path "tests/data/certificates/goodCertificate.crt"
+    When the administrator imports security certificate from the path "tests/data/certificates/goodCertificate.crt"
     Then the command should have been successful
     When the administrator invokes occ command "security:certificates"
     Then the command should have been successful
@@ -14,8 +14,8 @@ Feature: security certificates
       | goodCertificate.crt  |
 
   Scenario: List security certificates when multiple certificates are imported
-    Given the administrator has imported security certificate form the path "tests/data/certificates/goodCertificate.crt"
-    And the administrator has imported security certificate form the path "tests/data/certificates/badCertificate.crt"
+    Given the administrator has imported security certificate from the path "tests/data/certificates/goodCertificate.crt"
+    And the administrator has imported security certificate from the path "tests/data/certificates/badCertificate.crt"
     When the administrator invokes occ command "security:certificates"
     And the command output table should contain the following text:
     | table_column         |
@@ -23,8 +23,8 @@ Feature: security certificates
     | badCertificate.crt   |
 
   Scenario: Remove a security certificate
-    Given the administrator has imported security certificate form the path "tests/data/certificates/goodCertificate.crt"
-    And the administrator has imported security certificate form the path "tests/data/certificates/badCertificate.crt"
+    Given the administrator has imported security certificate from the path "tests/data/certificates/goodCertificate.crt"
+    And the administrator has imported security certificate from the path "tests/data/certificates/badCertificate.crt"
     When the administrator removes the security certificate "goodCertificate.crt"
     Then the command should have been successful
     When the administrator invokes occ command "security:certificates"
@@ -39,5 +39,5 @@ Feature: security certificates
     # Then the command should not have been successful
 
   Scenario: Import random file as certificate
-    When the administrator imports security certificate form the path "tests/data/lorem.txt"
+    When the administrator imports security certificate from the path "tests/data/lorem.txt"
     Then the command error output should contain the text "Certificate could not get parsed."
\ No newline at end of file

From b64168aa565f15ba700303687999bb63382dc539 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Wed, 5 Jun 2019 17:37:25 +0545
Subject: [PATCH 080/131] Make create user steps specify explicitly that the
 user has skeleton files

---
 .../acceptance/features/apiAuth/cors.feature  |   2 +-
 .../features/apiAuth/filesAppAuth.feature     |   2 +-
 .../features/apiAuth/tokenAuth.feature        |   2 +-
 .../features/apiAuth/webDavAuth.feature       |   2 +-
 .../features/apiAuthOcs/ocsGETAuth.feature    |   2 +-
 .../features/apiAuthOcs/ocsPOSTAuth.feature   |   4 +-
 .../apiCapabilities/capabilities.feature      |   6 +-
 .../features/apiComments/comments.feature     |   2 +-
 .../apiComments/createComments.feature        |   4 +-
 .../apiComments/deleteComments.feature        |   6 +-
 .../features/apiComments/editComments.feature |   4 +-
 .../features/apiFavorites/favorites.feature   |   8 +-
 .../apiFederation/etagPropagation.feature     |   4 +-
 .../features/apiFederation/federated.feature  |   6 +-
 .../features/apiMain/caldav.feature           |   2 +-
 .../features/apiMain/carddav.feature          |   2 +-
 .../features/apiMain/checksums.feature        |   6 +-
 .../features/apiMain/external-storage.feature |  18 +--
 .../acceptance/features/apiMain/quota.feature |  32 ++---
 .../apiProvisioning-v1/addUser.feature        |   6 +-
 .../apiProvisioningUsingAppPassword.feature   |  16 +--
 .../apiProvisioning-v1/createSubAdmin.feature |   8 +-
 .../apiProvisioning-v1/deleteUser.feature     |  12 +-
 .../apiProvisioning-v1/disableApp.feature     |   4 +-
 .../apiProvisioning-v1/disableUser.feature    |  28 ++--
 .../apiProvisioning-v1/editUser.feature       |  20 +--
 .../apiProvisioning-v1/enableApp.feature      |   4 +-
 .../apiProvisioning-v1/enableUser.feature     |  16 +--
 .../apiProvisioning-v1/getSubAdmins.feature   |  12 +-
 .../apiProvisioning-v1/getUser.feature        |  14 +-
 .../apiProvisioning-v1/getUsers.feature       |  10 +-
 .../apiProvisioning-v1/removeSubAdmin.feature |  10 +-
 .../apiProvisioning-v2/addUser.feature        |   6 +-
 .../apiProvisioningUsingAppPassword.feature   |  16 +--
 .../apiProvisioning-v2/createSubAdmin.feature |   8 +-
 .../apiProvisioning-v2/deleteUser.feature     |  12 +-
 .../apiProvisioning-v2/disableApp.feature     |   4 +-
 .../apiProvisioning-v2/disableUser.feature    |  28 ++--
 .../apiProvisioning-v2/editUser.feature       |  20 +--
 .../apiProvisioning-v2/enableApp.feature      |   4 +-
 .../apiProvisioning-v2/enableUser.feature     |  16 +--
 .../apiProvisioning-v2/getSubAdmins.feature   |  12 +-
 .../apiProvisioning-v2/getUser.feature        |  14 +-
 .../apiProvisioning-v2/getUsers.feature       |  10 +-
 .../apiProvisioning-v2/removeSubAdmin.feature |  10 +-
 .../apiProvisioningGroups-v1/addGroup.feature |   4 +-
 .../addToGroup.feature                        |  22 ++--
 .../deleteGroup.feature                       |   4 +-
 .../apiProvisioningGroups-v1/getGroup.feature |  14 +-
 .../getSubAdminGroups.feature                 |   2 +-
 .../getUserGroups.feature                     |  14 +-
 .../removeFromGroup.feature                   |  22 ++--
 .../apiProvisioningGroups-v2/addGroup.feature |   4 +-
 .../addToGroup.feature                        |  22 ++--
 .../deleteGroup.feature                       |   4 +-
 .../apiProvisioningGroups-v2/getGroup.feature |  14 +-
 .../getSubAdminGroups.feature                 |   2 +-
 .../getUserGroups.feature                     |  12 +-
 .../removeFromGroup.feature                   |  22 ++--
 .../apiShareManagement/acceptShares.feature   |   6 +-
 .../apiShareManagement/disableSharing.feature |  10 +-
 .../apiShareManagement/mergeShare.feature     |   4 +-
 .../moveReceivedShare.feature                 |   6 +-
 .../multilinksharing.feature                  |   2 +-
 .../apiShareManagement/reShare.feature        |  16 +--
 .../createShare.feature                       |  18 +--
 .../deleteShare.feature                       |  16 +--
 .../updateShare.feature                       |   6 +-
 .../apiShareOperations/accessToShare.feature  |   4 +-
 .../changingFilesShare.feature                |   4 +-
 .../downloadFromShare.feature                 |  18 +--
 .../getWebDAVSharePermissions.feature         |   4 +-
 .../apiShareOperations/gettingShares.feature  |  18 +--
 .../apiShareOperations/uploadToShare.feature  |  26 ++--
 .../features/apiSharees/sharees.feature       |   4 +-
 .../sharingNotifications.feature              |   2 +-
 .../features/apiTags/assignTags.feature       |   2 +-
 .../features/apiTags/assignTagsGroup.feature  |   2 +-
 .../features/apiTags/createTags.feature       |   2 +-
 .../features/apiTags/deleteTags.feature       |   2 +-
 .../features/apiTags/editTags.feature         |   2 +-
 .../features/apiTags/retreiveTags.feature     |   2 +-
 .../features/apiTags/unassignTags.feature     |   2 +-
 .../apiTrashbin/trashbinDelete.feature        |   2 +-
 .../apiTrashbin/trashbinFilesFolders.feature  |  28 ++--
 .../apiTrashbin/trashbinRestore.feature       |  20 +--
 .../features/apiVersions/fileVersions.feature |  32 ++---
 .../apiWebdavLocks/exclusiveLocks.feature     |   8 +-
 .../features/apiWebdavLocks/folder.feature    |   2 +-
 .../apiWebdavLocks/publicLink.feature         |   2 +-
 .../publicLinkLockdiscovery.feature           |   2 +-
 .../apiWebdavLocks/requestsWithToken.feature  |   6 +-
 .../apiWebdavLocks2/resharedShares.feature    |   2 +-
 .../apiWebdavLocks2/setTimeout.feature        |   6 +-
 .../features/apiWebdavLocks2/unlock.feature   |  18 +--
 .../features/apiWebdavMove/moveFile.feature   |   8 +-
 .../apiWebdavMove/moveFileAsync.feature       |   8 +-
 .../features/apiWebdavMove/moveFolder.feature |   2 +-
 .../apiWebdavOperations/deleteFile.feature    |   2 +-
 .../apiWebdavOperations/deleteFolder.feature  |   2 +-
 .../deleteFolderContents.feature              |   2 +-
 .../apiWebdavOperations/downloadFile.feature  |   2 +-
 .../apiWebdavOperations/refuseAccess.feature  |   2 +-
 .../apiWebdavOperations/search.feature        |   2 +-
 .../apiWebdavProperties/copyFile.feature      |   6 +-
 .../apiWebdavProperties/createFolder.feature  |   2 +-
 .../getFileProperties.feature                 |   6 +-
 .../apiWebdavProperties/getQuota.feature      |   6 +-
 .../setFileProperties.feature                 |   4 +-
 .../apiWebdavUpload/uploadFile.feature        |   2 +-
 .../uploadFileAsyncUsingNewChunking.feature   |   2 +-
 .../uploadFileUsingNewChunking.feature        |   2 +-
 .../uploadFileUsingOldChunking.feature        |   2 +-
 .../features/bootstrap/Provisioning.php       |   2 +
 .../cliBackground/backgroundQueue.feature     |   2 +-
 .../cliMain/cliIncomingShares.feature         |  14 +-
 .../acceptance/features/cliMain/files.feature |  34 ++---
 .../cliMain/transfer-ownership.feature        | 120 +++++++++---------
 .../cliProvisioning/addToGroup.feature        |   6 +-
 .../features/cliProvisioning/addUser.feature  |   6 +-
 .../cliProvisioning/disableUser.feature       |   6 +-
 .../features/cliProvisioning/editUser.feature |   6 +-
 .../cliProvisioning/enableUser.feature        |   6 +-
 .../features/cliProvisioning/getGroup.feature |   2 +-
 .../features/cliProvisioning/getUser.feature  |   2 +-
 .../cliProvisioning/getUserGroups.feature     |   4 +-
 .../cliProvisioning/removeFromGroup.feature   |   8 +-
 .../cliProvisioning/resetUserPassword.feature |   2 +-
 .../cliProvisioning/userLastSeen.feature      |   4 +-
 .../cliProvisioning/userReport.feature        |   6 +-
 .../cliProvisioning/userSettings.feature      |   2 +-
 .../features/cliTrashbin/trashbin.feature     |   6 +-
 .../adminStorageSettings.feature              |   6 +-
 .../features/webUIComments/comments.feature   |   2 +-
 .../deleteFilesFolders.feature                |   2 +-
 .../webUIFavorites/favoritesFile.feature      |   2 +-
 .../webUIFavorites/unfavoriteFile.feature     |   2 +-
 .../browseDirectlyToDetailsTab.feature        |   2 +-
 .../features/webUIFiles/fileDetails.feature   |   6 +-
 .../features/webUIFiles/hiddenFile.feature    |   2 +-
 .../webUIFiles/scrollMenuIntoView.feature     |   2 +-
 .../features/webUIFiles/search.feature        |  10 +-
 .../features/webUIFiles/versions.feature      |   8 +-
 .../features/webUILogin/login.feature         |   2 +-
 .../features/webUILogin/resetPassword.feature |   2 +-
 .../resetPasswordUsingEmail.feature           |   2 +-
 .../webUIMoveFilesFolders/moveFiles.feature   |   2 +-
 .../webUIMoveFilesFolders/moveFolders.feature |   2 +-
 ...ccessToChangeFullNameThroughConfig.feature |   4 +-
 .../changeOwnEmailAddress.feature             |   2 +-
 .../changeOwnFullName.feature                 |   2 +-
 .../changePasswordFromSetting.feature         |   2 +-
 .../personalGeneralSettings.feature           |   2 +-
 .../personalSecuritySettings.feature          |   2 +-
 .../webUIRenameFiles/renameFiles.feature      |   2 +-
 ...meFilesInsideProblematicFolderName.feature |   2 +-
 .../webUIRenameFolders/renameFolders.feature  |   2 +-
 .../disableSharing.feature                    |   2 +-
 .../restrictReSharing.feature                 |   2 +-
 .../restrictSharing.feature                   |   2 +-
 .../acceptShares.feature                      |   4 +-
 .../shareAutocompletion.feature               |  20 +--
 .../federationSharing.feature                 |  10 +-
 .../shareWithGroups.feature                   |   4 +-
 .../shareWithGroupsEdgeCases.feature          |   2 +-
 .../shareWithUsers.feature                    |  40 +++---
 .../notificationLink.feature                  |   2 +-
 .../shareWithGroups.feature                   |   2 +-
 .../shareWithUsers.feature                    |   2 +-
 .../shareByPublicLink.feature                 |   6 +-
 .../features/webUITags/createTags.feature     |   4 +-
 .../features/webUITags/deleteTags.feature     |   4 +-
 .../features/webUITags/editTags.feature       |   2 +-
 .../features/webUITags/removeTags.feature     |   2 +-
 .../features/webUITags/tagsSuggestion.feature |   2 +-
 .../webUITrashbin/trashbinDelete.feature      |   2 +-
 .../trashbinFilesFolders.feature              |   2 +-
 .../webUITrashbin/trashbinRestore.feature     |   2 +-
 .../features/webUIUpload/upload.feature       |   2 +-
 .../webUIUpload/uploadEdgecases.feature       |   2 +-
 .../uploadFileGreaterThanQuotaSize.feature    |   2 +-
 181 files changed, 701 insertions(+), 699 deletions(-)

diff --git a/tests/acceptance/features/apiAuth/cors.feature b/tests/acceptance/features/apiAuth/cors.feature
index eb25580f449f..9a73a0c582d8 100644
--- a/tests/acceptance/features/apiAuth/cors.feature
+++ b/tests/acceptance/features/apiAuth/cors.feature
@@ -1,7 +1,7 @@
 @api @TestAlsoOnExternalUserBackend
 Feature: CORS headers
   Background:
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
 
   Scenario Outline: CORS headers should be returned when setting CORS domain sending Origin header
     Given using OCS API version "<ocs_api_version>"
diff --git a/tests/acceptance/features/apiAuth/filesAppAuth.feature b/tests/acceptance/features/apiAuth/filesAppAuth.feature
index 421574c5307a..b0fe18da3429 100644
--- a/tests/acceptance/features/apiAuth/filesAppAuth.feature
+++ b/tests/acceptance/features/apiAuth/filesAppAuth.feature
@@ -2,7 +2,7 @@
 Feature: auth
 
   Background:
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And a new client token for "user0" has been generated
 
   @smokeTest
diff --git a/tests/acceptance/features/apiAuth/tokenAuth.feature b/tests/acceptance/features/apiAuth/tokenAuth.feature
index e5916f2304f4..488335c7f102 100644
--- a/tests/acceptance/features/apiAuth/tokenAuth.feature
+++ b/tests/acceptance/features/apiAuth/tokenAuth.feature
@@ -3,7 +3,7 @@ Feature: tokenAuth
 
   Background:
     Given using OCS API version "1"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And token auth has been enforced
 
   Scenario: creating a user with basic auth should be blocked when token auth is enforced
diff --git a/tests/acceptance/features/apiAuth/webDavAuth.feature b/tests/acceptance/features/apiAuth/webDavAuth.feature
index 387a5c485082..428d275f1106 100644
--- a/tests/acceptance/features/apiAuth/webDavAuth.feature
+++ b/tests/acceptance/features/apiAuth/webDavAuth.feature
@@ -2,7 +2,7 @@
 Feature: auth
 
   Background:
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And a new client token for "user0" has been generated
 
   Scenario: using WebDAV anonymously
diff --git a/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature b/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature
index 5ea4181b8131..1ee1a3b36ed6 100644
--- a/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature
+++ b/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature
@@ -1,7 +1,7 @@
 @api @TestAlsoOnExternalUserBackend
 Feature: auth
   Background:
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
 
   @issue-32068
   Scenario Outline: using OCS anonymously
diff --git a/tests/acceptance/features/apiAuthOcs/ocsPOSTAuth.feature b/tests/acceptance/features/apiAuthOcs/ocsPOSTAuth.feature
index d4b6feef2579..919b8f5642d1 100644
--- a/tests/acceptance/features/apiAuthOcs/ocsPOSTAuth.feature
+++ b/tests/acceptance/features/apiAuthOcs/ocsPOSTAuth.feature
@@ -2,12 +2,12 @@
 Feature: auth
 
   Background:
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
 
   @issue-32068
   Scenario Outline: send POST requests to OCS endpoints as normal user with wrong password
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     When user "user0" sends HTTP method "POST" to OCS API endpoint "<endpoint>" with body using password "invalid"
       | data        | doesnotmatter |
     Then the OCS status code should be "<ocs-code>"
diff --git a/tests/acceptance/features/apiCapabilities/capabilities.feature b/tests/acceptance/features/apiCapabilities/capabilities.feature
index 0a5ef867b2dd..3dc08e7b4d4b 100644
--- a/tests/acceptance/features/apiCapabilities/capabilities.feature
+++ b/tests/acceptance/features/apiCapabilities/capabilities.feature
@@ -499,7 +499,7 @@ Feature: capabilities
 
   Scenario: When in a group that is excluded from sharing, can_share is off
     Given parameter "shareapi_exclude_groups" of app "core" has been set to "yes"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And group "group1" has been created
     And group "hash#group" has been created
     And group "group-3" has been created
@@ -528,7 +528,7 @@ Feature: capabilities
 
   Scenario: When not in any group that is excluded from sharing, can_share is on
     Given parameter "shareapi_exclude_groups" of app "core" has been set to "yes"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And group "group1" has been created
     And group "hash#group" has been created
     And group "group-3" has been created
@@ -557,7 +557,7 @@ Feature: capabilities
 
   Scenario: When in a group that is excluded from sharing and in another group, can_share is off
     Given parameter "shareapi_exclude_groups" of app "core" has been set to "yes"
-    And user "user2" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
     And group "group1" has been created
     And group "hash#group" has been created
     And group "group-3" has been created
diff --git a/tests/acceptance/features/apiComments/comments.feature b/tests/acceptance/features/apiComments/comments.feature
index 4f3fbfa381d0..d9614426b928 100644
--- a/tests/acceptance/features/apiComments/comments.feature
+++ b/tests/acceptance/features/apiComments/comments.feature
@@ -3,7 +3,7 @@ Feature: Comments
 
   Background:
     Given using new DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
 
   @smokeTest
   Scenario: Getting info of comments using files endpoint
diff --git a/tests/acceptance/features/apiComments/createComments.feature b/tests/acceptance/features/apiComments/createComments.feature
index 246ab0839de7..3afb74021593 100644
--- a/tests/acceptance/features/apiComments/createComments.feature
+++ b/tests/acceptance/features/apiComments/createComments.feature
@@ -3,8 +3,8 @@ Feature: Comments
 
   Background:
     Given using new DAV path
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And as user "user0"
 
   @smokeTest
diff --git a/tests/acceptance/features/apiComments/deleteComments.feature b/tests/acceptance/features/apiComments/deleteComments.feature
index 7fa1a7d69db3..1ac589600a57 100644
--- a/tests/acceptance/features/apiComments/deleteComments.feature
+++ b/tests/acceptance/features/apiComments/deleteComments.feature
@@ -3,8 +3,8 @@ Feature: Comments
 
   Background:
     Given using new DAV path
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And as user "user0"
 
   @smokeTest
@@ -91,6 +91,6 @@ Feature: Comments
     Given the user has created folder "/FOLDER_TO_COMMENT"
     And the user has commented with content "Comment from owner" on folder "/FOLDER_TO_COMMENT"
     And user "user0" has been deleted
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     When the user creates folder "/FOLDER_TO_COMMENT" using the WebDAV API
     Then the user should have 0 comments on folder "/FOLDER_TO_COMMENT"
diff --git a/tests/acceptance/features/apiComments/editComments.feature b/tests/acceptance/features/apiComments/editComments.feature
index c396a71e682b..c87bf8ac96ae 100644
--- a/tests/acceptance/features/apiComments/editComments.feature
+++ b/tests/acceptance/features/apiComments/editComments.feature
@@ -3,8 +3,8 @@ Feature: Comments
 
   Background:
     Given using new DAV path
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And as user "user0"
 
   @smokeTest
diff --git a/tests/acceptance/features/apiFavorites/favorites.feature b/tests/acceptance/features/apiFavorites/favorites.feature
index 74b70b087723..a2789e9e931e 100644
--- a/tests/acceptance/features/apiFavorites/favorites.feature
+++ b/tests/acceptance/features/apiFavorites/favorites.feature
@@ -3,7 +3,7 @@ Feature: favorite
 
   Background:
     Given using OCS API version "1"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And as user "user0"
 
   Scenario Outline: Favorite a folder
@@ -83,7 +83,7 @@ Feature: favorite
 
   Scenario Outline: moving a favorite file out of a share keeps favorite state
     Given using <dav_version> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And the user has created folder "/shared"
     And the user has moved file "/textfile0.txt" to "/shared/shared_file.txt"
     And the user has shared folder "/shared" with user "user1"
@@ -148,7 +148,7 @@ Feature: favorite
 
   Scenario Outline: sharer file favorite state should not change the favorite state of sharee
     Given using <dav_version> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And the user has moved file "/textfile0.txt" to "/favoriteFile.txt"
     And the user has shared file "/favoriteFile.txt" with user "user1"
     When the user favorites element "/favoriteFile.txt" using the WebDAV API
@@ -160,7 +160,7 @@ Feature: favorite
 
   Scenario Outline: sharee file favorite state should not change the favorite state of sharer
     Given using <dav_version> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And the user has moved file "/textfile0.txt" to "/favoriteFile.txt"
     And the user has shared file "/favoriteFile.txt" with user "user1"
     When user "user1" favorites element "/favoriteFile.txt" using the WebDAV API
diff --git a/tests/acceptance/features/apiFederation/etagPropagation.feature b/tests/acceptance/features/apiFederation/etagPropagation.feature
index b8a1cba6d8a8..cfaeb6e286c5 100644
--- a/tests/acceptance/features/apiFederation/etagPropagation.feature
+++ b/tests/acceptance/features/apiFederation/etagPropagation.feature
@@ -4,9 +4,9 @@ Feature: propagation of etags between federated and local server
   Background:
     Given using OCS API version "1"
     And using server "REMOTE"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And using server "LOCAL"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
 
   Scenario: Overwrite a federated shared folder as sharer propagates etag for recipient
     Given user "user1" from server "LOCAL" has shared "/PARENT" with user "user0" from server "REMOTE"
diff --git a/tests/acceptance/features/apiFederation/federated.feature b/tests/acceptance/features/apiFederation/federated.feature
index 68d24edb93c0..519f95e57cbc 100644
--- a/tests/acceptance/features/apiFederation/federated.feature
+++ b/tests/acceptance/features/apiFederation/federated.feature
@@ -3,9 +3,9 @@ Feature: federated
 
   Background:
     Given using server "REMOTE"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And using server "LOCAL"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
 
   Scenario Outline: Federate share a file with another server
     Given using OCS API version "<ocs-api-version>"
@@ -163,7 +163,7 @@ Feature: federated
     Given user "user0" from server "REMOTE" has shared "/textfile0.txt" with user "user1" from server "LOCAL"
     And user "user1" from server "LOCAL" has accepted the last pending share
     And using server "LOCAL"
-    And user "user2" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
     And using OCS API version "<ocs-api-version>"
     When user "user1" creates a share using the sharing API with settings
       | path        | /textfile0 (2).txt |
diff --git a/tests/acceptance/features/apiMain/caldav.feature b/tests/acceptance/features/apiMain/caldav.feature
index 70d25067874c..58bbc25e90b4 100644
--- a/tests/acceptance/features/apiMain/caldav.feature
+++ b/tests/acceptance/features/apiMain/caldav.feature
@@ -2,7 +2,7 @@
 Feature: caldav
 
   Background:
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
 
   @caldav
   Scenario: Accessing a not existing calendar of another user
diff --git a/tests/acceptance/features/apiMain/carddav.feature b/tests/acceptance/features/apiMain/carddav.feature
index 3963653f56cd..e63eb17bc51b 100644
--- a/tests/acceptance/features/apiMain/carddav.feature
+++ b/tests/acceptance/features/apiMain/carddav.feature
@@ -2,7 +2,7 @@
 Feature: carddav
 
   Background:
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
 
   @carddav
   Scenario: Accessing a not existing addressbook of another user
diff --git a/tests/acceptance/features/apiMain/checksums.feature b/tests/acceptance/features/apiMain/checksums.feature
index c78584181c22..ff626bb47c00 100644
--- a/tests/acceptance/features/apiMain/checksums.feature
+++ b/tests/acceptance/features/apiMain/checksums.feature
@@ -2,7 +2,7 @@
 Feature: checksums
 
   Background:
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
 
   Scenario Outline: Uploading a file with checksum should work
     Given using <dav_version> DAV path
@@ -109,7 +109,7 @@ Feature: checksums
 
   Scenario: Sharing a file with checksum should return the checksum in the propfind using new DAV path
     Given using new DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a"
     When user "user0" shares file "/myChecksumFile.txt" with user "user1" using the sharing API
     And user "user1" requests the checksum of "/myChecksumFile.txt" via propfind
@@ -117,7 +117,7 @@ Feature: checksums
 
   Scenario: Sharing and modifying a file should return correct checksum in the propfind using new DAV path
     Given using new DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a"
     When user "user0" shares file "/myChecksumFile.txt" with user "user1" using the sharing API
     And user "user1" uploads file with checksum "SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399" and content "Some Text" to "/myChecksumFile.txt" using the WebDAV API
diff --git a/tests/acceptance/features/apiMain/external-storage.feature b/tests/acceptance/features/apiMain/external-storage.feature
index 99ce0d8818d3..def7226a9529 100644
--- a/tests/acceptance/features/apiMain/external-storage.feature
+++ b/tests/acceptance/features/apiMain/external-storage.feature
@@ -7,8 +7,8 @@ Feature: external-storage
 
   @public_link_share-feature-required
   Scenario: Share by public link a file inside a local external storage
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/local_storage/foo"
     And user "user0" has moved file "/textfile0.txt" to "/local_storage/foo/textfile0.txt"
     And user "user0" has shared folder "/local_storage/foo" with user "user1"
@@ -23,16 +23,16 @@ Feature: external-storage
       | mimetype | httpd/unix-directory |
 
   Scenario: Move a file into storage
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/local_storage/foo1"
     When user "user0" moves file "/textfile0.txt" to "/local_storage/foo1/textfile0.txt" using the WebDAV API
     Then as "user1" file "/local_storage/foo1/textfile0.txt" should exist
     And as "user0" file "/local_storage/foo1/textfile0.txt" should exist
 
   Scenario: Move a file out of storage
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/local_storage/foo2"
     And user "user0" has moved file "/textfile0.txt" to "/local_storage/foo2/textfile0.txt"
     When user "user1" moves file "/local_storage/foo2/textfile0.txt" to "/local.txt" using the WebDAV API
@@ -41,7 +41,7 @@ Feature: external-storage
     And as "user1" file "/local.txt" should exist
 
   Scenario: Download a file that exists in filecache but not storage fails with 404
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And user "user0" has created folder "/local_storage/foo3"
     And user "user0" 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
@@ -50,7 +50,7 @@ Feature: external-storage
     And as "user0" file "local_storage/foo3/textfile0.txt" should not exist
 
   Scenario: Upload a file to external storage while quota is set on home storage
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And the quota of user "user0" has been set to "1 B"
     When user "user0" 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"
@@ -58,7 +58,7 @@ Feature: external-storage
 
   Scenario Outline: query OCS endpoint for information about the mount
     Given using OCS API version "<ocs_api_version>"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     When user "user0" sends HTTP method "GET" to OCS API endpoint "<endpoint>"
     Then the OCS status code should be "<ocs-code>"
     And the HTTP status code should be "<http-code>"
diff --git a/tests/acceptance/features/apiMain/quota.feature b/tests/acceptance/features/apiMain/quota.feature
index 2c850062834b..6be9d50f8796 100644
--- a/tests/acceptance/features/apiMain/quota.feature
+++ b/tests/acceptance/features/apiMain/quota.feature
@@ -8,7 +8,7 @@ Feature: quota
 
   Scenario Outline: Uploading a file as owner having enough quota
     Given using <dav_version> DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And the quota of user "user0" has been set to "10 MB"
     When user "user0" uploads file "filesForUpload/textfile.txt" to filenames based on "/testquota.txt" with all mechanisms using the WebDAV API
     Then the HTTP status code of all upload responses should be "201"
@@ -20,7 +20,7 @@ Feature: quota
   @smokeTest
   Scenario Outline: Uploading a file as owner having insufficient quota
     Given using <dav_version> DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And the quota of user "user0" has been set to "20 B"
     When user "user0" uploads file "filesForUpload/textfile.txt" to filenames based on "/testquota.txt" with all mechanisms using the WebDAV API
     Then the HTTP status code of all upload responses should be "507"
@@ -32,7 +32,7 @@ Feature: quota
 
   Scenario Outline: Overwriting a file as owner having enough quota
     Given using <dav_version> DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And the quota of user "user0" has been set to "10 MB"
     And user "user0" has uploaded file with content "test" to "/testquota.txt"
     When user "user0" overwrites file "filesForUpload/textfile.txt" to filenames based on "/testquota.txt" with all mechanisms using the WebDAV API
@@ -44,7 +44,7 @@ Feature: quota
 
   Scenario Outline: Overwriting a file as owner having insufficient quota
     Given using <dav_version> DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And the quota of user "user0" has been set to "20 B"
     And user "user0" has uploaded file with content "test" to "/testquota.txt"
     When user "user0" overwrites file "filesForUpload/textfile.txt" to filenames based on "/testquota.txt" with all mechanisms using the WebDAV API
@@ -59,8 +59,8 @@ Feature: quota
 
   Scenario Outline: Uploading a file in received folder having enough quota
     Given using <dav_version> DAV path
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And the quota of user "user0" has been set to "20 B"
     And the quota of user "user1" has been set to "10 MB"
     And user "user1" has created folder "/testquota"
@@ -74,8 +74,8 @@ Feature: quota
 
   Scenario Outline: Uploading a file in received folder having insufficient quota
     Given using <dav_version> DAV path
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And the quota of user "user0" has been set to "10 MB"
     And the quota of user "user1" has been set to "20 B"
     And user "user1" has created folder "/testquota"
@@ -90,8 +90,8 @@ Feature: quota
 
   Scenario Outline: Overwriting a file in received folder having enough quota
     Given using <dav_version> DAV path
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And the quota of user "user0" has been set to "20 B"
     And the quota of user "user1" has been set to "10 MB"
     And user "user1" has created folder "/testquota"
@@ -106,8 +106,8 @@ Feature: quota
 
   Scenario Outline: Overwriting a file in received folder having insufficient quota
     Given using <dav_version> DAV path
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And the quota of user "user0" has been set to "10 MB"
     And the quota of user "user1" has been set to "20 B"
     And user "user1" has created folder "/testquota"
@@ -125,8 +125,8 @@ Feature: quota
 
   Scenario Outline: Overwriting a received file having enough quota
     Given using <dav_version> DAV path
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And the quota of user "user0" has been set to "20 B"
     And the quota of user "user1" has been set to "10 MB"
     And user "user1" has uploaded file with content "test" to "/testquota.txt"
@@ -140,8 +140,8 @@ Feature: quota
 
   Scenario Outline: Overwriting a received file having insufficient quota
     Given using <dav_version> DAV path
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And the quota of user "user0" has been set to "10 MB"
     And the quota of user "user1" has been set to "20 B"
     And user "user1" has moved file "/textfile0.txt" to "/testquota.txt"
diff --git a/tests/acceptance/features/apiProvisioning-v1/addUser.feature b/tests/acceptance/features/apiProvisioning-v1/addUser.feature
index 810ec8a1bf9c..9853b9205adf 100644
--- a/tests/acceptance/features/apiProvisioning-v1/addUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/addUser.feature
@@ -17,14 +17,14 @@ Feature: add user
     And user "brand-new-user" should be able to access a skeleton file
 
   Scenario: admin tries to create an existing user
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and 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
+    Given user "brand-new-user" has been created with default attributes and 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"
@@ -86,7 +86,7 @@ Feature: add 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
+    Given user "brand-new-user" has been created with default attributes and 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"
diff --git a/tests/acceptance/features/apiProvisioning-v1/apiProvisioningUsingAppPassword.feature b/tests/acceptance/features/apiProvisioning-v1/apiProvisioningUsingAppPassword.feature
index d98cbceb4906..f7dd240d660a 100644
--- a/tests/acceptance/features/apiProvisioning-v1/apiProvisioningUsingAppPassword.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/apiProvisioningUsingAppPassword.feature
@@ -9,7 +9,7 @@ Feature: access user provisioning API using app password
 
   @smokeTest
   Scenario: admin deletes the user
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "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
@@ -19,8 +19,8 @@ Feature: access user provisioning API using app password
     And user "brand-new-user" should not exist
 
   Scenario: subadmin gets users in their group
-    Given user "brand-new-user" has been created with default attributes
-    And user "another-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
+    And user "another-new-user" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "another-new-user" has been added to group "new-group"
     And user "brand-new-user" has been made a subadmin of group "new-group"
@@ -34,7 +34,7 @@ Feature: access user provisioning API using app password
 
   @smokeTest
   Scenario: normal user gets their own information using the app password
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username | displayname |
       | newuser  | New User    |
     And a new client token for "newuser" has been generated
@@ -45,8 +45,8 @@ Feature: access user provisioning API using app password
     And the display name returned by the API should be "New User"
 
   Scenario: subadmin tries to get users of other group
-    Given user "brand-new-user" has been created with default attributes
-    And user "another-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
+    And user "another-new-user" has been created with default attributes and skeleton files
     And group "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"
@@ -59,8 +59,8 @@ Feature: access user provisioning API using app password
     And the HTTP status code should be "200"
 
   Scenario: normal user tries to get other user information using the app password
-    Given user "newuser" has been created with default attributes
-    And user "anotheruser" has been created with default attributes
+    Given user "newuser" has been created with default attributes and skeleton files
+    And user "anotheruser" has been created with default attributes and skeleton files
     And a new client token for "newuser" has been generated
     And a new browser session for "newuser" has been started
     And the user has generated a new app password named "my-client"
diff --git a/tests/acceptance/features/apiProvisioning-v1/createSubAdmin.feature b/tests/acceptance/features/apiProvisioning-v1/createSubAdmin.feature
index 9916754ae092..97f8c5ab2ed7 100644
--- a/tests/acceptance/features/apiProvisioning-v1/createSubAdmin.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/createSubAdmin.feature
@@ -9,7 +9,7 @@ Feature: create a subadmin
 
   @smokeTest
   Scenario: admin creates a subadmin
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "new-group" has been created
     When the administrator makes user "brand-new-user" a subadmin of group "new-group" using the provisioning API
     Then the OCS status code should be "100"
@@ -25,7 +25,7 @@ Feature: create a subadmin
     And user "not-user" should not be a subadmin of group "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
+    Given user "brand-new-user" has been created with default attributes and 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"
@@ -33,8 +33,8 @@ Feature: create a subadmin
     And the API should not return any data
 
   Scenario: subadmin of a group tries to make another user subadmin of their group
-    Given user "subadmin" has been created with default attributes
-    And user "brand-new-user" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
+    And user "brand-new-user" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     And user "brand-new-user" has been added to group "new-group"
diff --git a/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature b/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature
index b092939ab953..ac4be9a945ef 100644
--- a/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature
@@ -9,14 +9,14 @@ Feature: delete users
 
   @smokeTest
   Scenario: Delete a user
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and 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, and specify the user name in different case
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and 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"
@@ -24,8 +24,8 @@ Feature: delete users
 
   @smokeTest
   Scenario: subadmin deletes a user in their group
-    Given user "subadmin" has been created with default attributes
-    And user "brand-new-user" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
+    And user "brand-new-user" has been created with default attributes and skeleton files
     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"
@@ -35,8 +35,8 @@ Feature: delete users
     And user "brand-new-user" should not exist
 
   Scenario: normal user tries to delete a user
-    Given user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
     When user "user1" deletes user "user2" 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/apiProvisioning-v1/disableApp.feature b/tests/acceptance/features/apiProvisioning-v1/disableApp.feature
index 85330e109a6b..1ed0f2b6a167 100644
--- a/tests/acceptance/features/apiProvisioning-v1/disableApp.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/disableApp.feature
@@ -16,7 +16,7 @@ Feature: disable an app
     And app "comments" should be disabled
 
   Scenario: subadmin tries to disable an app
-    Given user "subadmin" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
     And group "newgroup" has been created
     And user "subadmin" has been made a subadmin of group "newgroup"
     And app "comments" has been enabled
@@ -26,7 +26,7 @@ Feature: disable an app
     And app "comments" should be enabled
 
   Scenario: normal user tries to disable an app
-    Given user "newuser" has been created with default attributes
+    Given user "newuser" has been created with default attributes and skeleton files
     And app "comments" has been enabled
     When user "newuser" disables app "comments"
     Then the OCS status code should be "997"
diff --git a/tests/acceptance/features/apiProvisioning-v1/disableUser.feature b/tests/acceptance/features/apiProvisioning-v1/disableUser.feature
index 37146324d315..ac7e993bde9f 100644
--- a/tests/acceptance/features/apiProvisioning-v1/disableUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/disableUser.feature
@@ -9,7 +9,7 @@ Feature: disable user
 
   @smokeTest
   Scenario: admin disables an user
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     When the administrator disables user "user1" using the provisioning API
     Then the OCS status code should be "100"
     And the HTTP status code should be "200"
@@ -17,8 +17,8 @@ Feature: disable user
 
   @smokeTest
   Scenario: Subadmin should be able to disable an user in their group
-    Given user "subadmin" has been created with default attributes
-    And user "user1" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been added to group "new-group"
     And user "user1" has been added to group "new-group"
@@ -29,8 +29,8 @@ Feature: disable user
     And user "user1" should be disabled
 
   Scenario: Subadmin should not be able to disable an user not in their group
-    Given user "subadmin" has been created with default attributes
-    And user "user1" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And group "another-group" has been created
     And user "subadmin" has been added to group "new-group"
@@ -42,8 +42,8 @@ Feature: disable user
     And user "user1" should be enabled
 
   Scenario: Subadmins should not be able to disable users that have admin permissions in their group
-    Given user "another-admin" has been created with default attributes
-    And user "subadmin" has been created with default attributes
+    Given user "another-admin" has been created with default attributes and skeleton files
+    And user "subadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "another-admin" has been added to group "admin"
     And user "subadmin" has been added to group "new-group"
@@ -55,7 +55,7 @@ Feature: disable user
     And user "another-admin" should be enabled
 
   Scenario: Admin can disable another admin user
-    Given user "another-admin" has been created with default attributes
+    Given user "another-admin" has been created with default attributes and 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"
@@ -63,7 +63,7 @@ Feature: disable user
     And user "another-admin" should be disabled
 
   Scenario: Admin can disable subadmins in the same group
-    Given user "subadmin" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been added to group "new-group"
     And the administrator has been added to group "new-group"
@@ -74,7 +74,7 @@ Feature: disable user
     And user "subadmin" should be disabled
 
   Scenario: Admin user cannot disable himself
-    Given user "another-admin" has been created with default attributes
+    Given user "another-admin" has been created with default attributes and 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"
@@ -82,15 +82,15 @@ Feature: disable user
     And user "another-admin" should be enabled
 
   Scenario: disable an user with a regular user
-    Given user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
     When user "user1" disables user "user2" using the provisioning API
     Then the OCS status code should be "997"
     And the HTTP status code should be "401"
     And user "user2" should be enabled
 
   Scenario: Subadmin should not be able to disable himself
-    Given user "subadmin" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been added to group "new-group"
     And user "subadmin" has been made a subadmin of group "new-group"
@@ -101,7 +101,7 @@ Feature: disable user
 
   @smokeTest
   Scenario: Making a web request with a disabled user
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And user "user0" has been disabled
     When user "user0" sends HTTP method "GET" to URL "/index.php/apps/files"
     Then the HTTP status code should be "403"
\ No newline at end of file
diff --git a/tests/acceptance/features/apiProvisioning-v1/editUser.feature b/tests/acceptance/features/apiProvisioning-v1/editUser.feature
index 025ac72b7ad6..797fa6c896b4 100644
--- a/tests/acceptance/features/apiProvisioning-v1/editUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/editUser.feature
@@ -9,7 +9,7 @@ Feature: edit users
 
   @smokeTest
   Scenario: the administrator can edit a user email
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and 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"
@@ -17,14 +17,14 @@ Feature: edit users
 
   @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
+    Given user "brand-new-user" has been created with default attributes and 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
+    Given user "brand-new-user" has been created with default attributes and 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"
@@ -32,14 +32,14 @@ Feature: edit users
 
   @smokeTest
   Scenario: the administrator can edit a user quota
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and 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
+    Given user "brand-new-user" has been created with default attributes and 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 "100"
     And the HTTP status code should be "200"
@@ -50,8 +50,8 @@ Feature: edit users
 
   @smokeTest
   Scenario: a subadmin should be able to edit the user information in their group
-    Given user "subadmin" has been created with default attributes
-    And user "brand-new-user" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
+    And user "brand-new-user" has been created with default attributes and skeleton files
     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"
@@ -63,7 +63,7 @@ Feature: edit users
     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
+    Given user "brand-new-user" has been created with default attributes and 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"
@@ -72,7 +72,7 @@ Feature: edit users
     And the email address of user "brand-new-user" should be "brand-new-user@example.com"
 
   Scenario: a normal user should be able to change their display name
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     When user "brand-new-user" changes the display name of user "brand-new-user" to "Alan Border" using the provisioning API
     Then the OCS status code should be "100"
     And the HTTP status code should be "200"
@@ -81,7 +81,7 @@ Feature: edit users
     And the display name of user "brand-new-user" should be "Alan Border"
 
   Scenario: a normal user should not be able to change their quota
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and 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"
diff --git a/tests/acceptance/features/apiProvisioning-v1/enableApp.feature b/tests/acceptance/features/apiProvisioning-v1/enableApp.feature
index 4ddc0f2a1bc5..893a8704a6f0 100644
--- a/tests/acceptance/features/apiProvisioning-v1/enableApp.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/enableApp.feature
@@ -17,7 +17,7 @@ Feature: enable an app
     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
+    Given user "subadmin" has been created with default attributes and skeleton files
     And group "newgroup" has been created
     And user "subadmin" has been made a subadmin of group "newgroup"
     And app "comments" has been disabled
@@ -27,7 +27,7 @@ Feature: enable an app
     And app "comments" should be disabled
 
   Scenario: normal user tries to enable an app
-    Given user "newuser" has been created with default attributes
+    Given user "newuser" has been created with default attributes and skeleton files
     And app "comments" has been disabled
     When user "newuser" enables app "comments"
     Then the OCS status code should be "997"
diff --git a/tests/acceptance/features/apiProvisioning-v1/enableUser.feature b/tests/acceptance/features/apiProvisioning-v1/enableUser.feature
index 12206944c20d..f9724041ed9d 100644
--- a/tests/acceptance/features/apiProvisioning-v1/enableUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/enableUser.feature
@@ -9,7 +9,7 @@ Feature: enable user
 
   @smokeTest
   Scenario: admin enables an user
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has been disabled
     When the administrator enables user "user1" using the provisioning API
     Then the OCS status code should be "100"
@@ -17,7 +17,7 @@ Feature: enable user
     And user "user1" should be enabled
 
   Scenario: admin enables another admin user
-    Given user "another-admin" has been created with default attributes
+    Given user "another-admin" has been created with default attributes and 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
@@ -26,7 +26,7 @@ Feature: enable user
     And user "another-admin" should be enabled
 
   Scenario: admin enables subadmins in the same group
-    Given user "subadmin" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been added to group "new-group"
     And the administrator has been added to group "new-group"
@@ -38,15 +38,15 @@ Feature: enable user
     And user "subadmin" should be enabled
 
   Scenario: admin tries to enable himself
-    And user "another-admin" has been created with default attributes
+    And user "another-admin" has been created with default attributes and 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 user "another-admin" should be disabled
 
   Scenario: normal user tries to enable other user
-    Given user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
     And user "user2" has been disabled
     When user "user1" tries to enable user "user2" using the provisioning API
     Then the OCS status code should be "997"
@@ -54,7 +54,7 @@ Feature: enable user
     And user "user2" should be disabled
 
   Scenario: subadmin tries to enable himself
-    Given user "subadmin" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been added to group "new-group"
     And user "subadmin" has been made a subadmin of group "new-group"
@@ -65,6 +65,6 @@ Feature: enable user
     And user "subadmin" should be disabled
 
   Scenario: Making a web request with an enabled user
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     When user "user0" sends HTTP method "GET" to URL "/index.php/apps/files"
     Then the HTTP status code should be "200"
\ No newline at end of file
diff --git a/tests/acceptance/features/apiProvisioning-v1/getSubAdmins.feature b/tests/acceptance/features/apiProvisioning-v1/getSubAdmins.feature
index 6317c65c431e..b0382033e1c9 100644
--- a/tests/acceptance/features/apiProvisioning-v1/getSubAdmins.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/getSubAdmins.feature
@@ -9,7 +9,7 @@ Feature: get subadmins
 
   @smokeTest
   Scenario: admin gets subadmin users of a group
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "brand-new-user" has been made a subadmin of group "new-group"
     When the administrator gets all the subadmins of group "new-group" using the provisioning API
@@ -19,7 +19,7 @@ Feature: get subadmins
     And the HTTP status code should be "200"
 
   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
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "not-group" has been deleted
     When the administrator gets all the subadmins of group "not-group" using the provisioning API
     Then the OCS status code should be "101"
@@ -27,8 +27,8 @@ Feature: get subadmins
     And the API should not return any data
 
   Scenario: subadmin tries to get other subadmins of the same group
-    Given user "subadmin" has been created with default attributes
-    And user "newsubadmin" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
+    And user "newsubadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     And user "newsubadmin" has been made a subadmin of group "new-group"
@@ -38,8 +38,8 @@ Feature: get subadmins
     And the API should not return any data
 
   Scenario: normal user tries to get the subadmins of the group
-    Given user "newuser" has been created with default attributes
-    And user "subadmin" has been created with default attributes
+    Given user "newuser" has been created with default attributes and skeleton files
+    And user "subadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     When user "newuser" gets all the subadmins of group "new-group" using the provisioning API
diff --git a/tests/acceptance/features/apiProvisioning-v1/getUser.feature b/tests/acceptance/features/apiProvisioning-v1/getUser.feature
index 82ba59f1e246..f64d326ea846 100644
--- a/tests/acceptance/features/apiProvisioning-v1/getUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/getUser.feature
@@ -9,7 +9,7 @@ Feature: get user
 
   @smokeTest
   Scenario: admin gets an existing user
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and 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
@@ -26,7 +26,7 @@ Feature: get user
 
   @smokeTest
   Scenario: a subadmin gets information of a user in their group
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username | displayname |
       | subadmin | Sub Admin   |
       | newuser  | New User    |
@@ -40,8 +40,8 @@ Feature: get user
     And the quota definition returned by the API should be "default"
 
   Scenario: a subadmin tries to get information of a user not in their group
-    Given user "subadmin" has been created with default attributes
-    And user "newuser" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
+    And user "newuser" has been created with default attributes and skeleton files
     And group "newgroup" has been created
     And user "subadmin" has been made a subadmin of group "newgroup"
     When user "subadmin" retrieves the information of user "newuser" using the provisioning API
@@ -50,8 +50,8 @@ Feature: get user
     And the API should not return any data
 
   Scenario: a normal user tries to get information of another user
-    Given user "newuser" has been created with default attributes
-    And user "anotheruser" has been created with default attributes
+    Given user "newuser" has been created with default attributes and skeleton files
+    And user "anotheruser" has been created with default attributes and skeleton files
     When user "anotheruser" retrieves the information of user "newuser" using the provisioning API
     Then the OCS status code should be "997"
     And the HTTP status code should be "401"
@@ -59,7 +59,7 @@ Feature: get user
 
   @smokeTest
   Scenario: a normal user gets their own information
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username | displayname |
       | newuser  | New User    |
     When user "newuser" retrieves the information of user "newuser" using the provisioning API
diff --git a/tests/acceptance/features/apiProvisioning-v1/getUsers.feature b/tests/acceptance/features/apiProvisioning-v1/getUsers.feature
index 0972074b4e02..6da886b0ef02 100644
--- a/tests/acceptance/features/apiProvisioning-v1/getUsers.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/getUsers.feature
@@ -9,7 +9,7 @@ Feature: get users
 
   @smokeTest
   Scenario: admin gets all users
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and 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"
@@ -19,8 +19,8 @@ Feature: get users
 
   @smokeTest
   Scenario: subadmin gets the users in their group
-    Given user "brand-new-user" has been created with default attributes
-    And user "another-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
+    And user "another-new-user" has been created with default attributes and skeleton files
     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"
@@ -31,8 +31,8 @@ Feature: get users
     And the HTTP status code should be "200"
 
   Scenario: normal user tries to get other users
-    Given user "normaluser" has been created with default attributes
-    And user "newuser" has been created with default attributes
+    Given user "normaluser" has been created with default attributes and skeleton files
+    And user "newuser" has been created with default attributes and skeleton files
     When user "normaluser" 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"
diff --git a/tests/acceptance/features/apiProvisioning-v1/removeSubAdmin.feature b/tests/acceptance/features/apiProvisioning-v1/removeSubAdmin.feature
index 0d612f169acb..68ffbd49b18f 100644
--- a/tests/acceptance/features/apiProvisioning-v1/removeSubAdmin.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/removeSubAdmin.feature
@@ -9,7 +9,7 @@ Feature: remove subadmin
 
   @smokeTest
   Scenario: admin removes subadmin from a group
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "brand-new-user" has been made a subadmin of group "new-group"
     When the administrator removes user "brand-new-user" from being a subadmin of group "new-group" using the provisioning API
@@ -18,10 +18,10 @@ Feature: remove subadmin
     And user "brand-new-user" should not be a subadmin of group "new-group"
 
   Scenario: subadmin tries to remove other subadmin in the group
-    Given user "subadmin" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
-    And user "newsubadmin" has been created with default attributes
+    And user "newsubadmin" has been created with default attributes and skeleton files
     And user "newsubadmin" has been made a subadmin of group "new-group"
     When user "subadmin" removes user "newsubadmin" from being a subadmin of group "new-group" using the provisioning API
     Then the OCS status code should be "997"
@@ -29,8 +29,8 @@ Feature: remove subadmin
     And user "newsubadmin" should be a subadmin of group "new-group"
 
   Scenario: normal user tries to remove subadmin in the group
-    Given user "subadmin" has been created with default attributes
-    And user "newuser" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
+    And user "newuser" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     And user "newuser" has been added to group "new-group"
diff --git a/tests/acceptance/features/apiProvisioning-v2/addUser.feature b/tests/acceptance/features/apiProvisioning-v2/addUser.feature
index 3ff1abe60d86..9355d576bedb 100644
--- a/tests/acceptance/features/apiProvisioning-v2/addUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/addUser.feature
@@ -17,14 +17,14 @@ Feature: add user
     And user "brand-new-user" should be able to access a skeleton file
 
   Scenario: admin tries to create an existing user
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and 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
+    Given user "brand-new-user" has been created with default attributes and 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"
@@ -86,7 +86,7 @@ Feature: add 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
+    Given user "brand-new-user" has been created with default attributes and 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"
diff --git a/tests/acceptance/features/apiProvisioning-v2/apiProvisioningUsingAppPassword.feature b/tests/acceptance/features/apiProvisioning-v2/apiProvisioningUsingAppPassword.feature
index 2ef410076c65..d02deca49174 100644
--- a/tests/acceptance/features/apiProvisioning-v2/apiProvisioningUsingAppPassword.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/apiProvisioningUsingAppPassword.feature
@@ -9,7 +9,7 @@ Feature: access user provisioning API using app password
 
   @smokeTest
   Scenario: admin deletes the user
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "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
@@ -19,8 +19,8 @@ Feature: access user provisioning API using app password
     And user "brand-new-user" should not exist
 
   Scenario: subadmin gets users in their group
-    Given user "brand-new-user" has been created with default attributes
-    And user "another-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
+    And user "another-new-user" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "another-new-user" has been added to group "new-group"
     And user "brand-new-user" has been made a subadmin of group "new-group"
@@ -34,7 +34,7 @@ Feature: access user provisioning API using app password
 
   @smokeTest
   Scenario: normal user gets their own information using the app password
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username | displayname |
       | newuser  | New User    |
     And a new client token for "newuser" has been generated
@@ -45,8 +45,8 @@ Feature: access user provisioning API using app password
     And the display name returned by the API should be "New User"
 
   Scenario: subadmin tries to get users of other group
-    Given user "brand-new-user" has been created with default attributes
-    And user "another-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
+    And user "another-new-user" has been created with default attributes and skeleton files
     And group "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"
@@ -59,8 +59,8 @@ Feature: access user provisioning API using app password
     And the HTTP status code should be "200"
 
   Scenario: normal user tries to get other user information using the app password
-    Given user "newuser" has been created with default attributes
-    And user "anotheruser" has been created with default attributes
+    Given user "newuser" has been created with default attributes and skeleton files
+    And user "anotheruser" has been created with default attributes and skeleton files
     And a new client token for "newuser" has been generated
     And a new browser session for "newuser" has been started
     And the user has generated a new app password named "my-client"
diff --git a/tests/acceptance/features/apiProvisioning-v2/createSubAdmin.feature b/tests/acceptance/features/apiProvisioning-v2/createSubAdmin.feature
index 56a0d8401637..77bf13d95af9 100644
--- a/tests/acceptance/features/apiProvisioning-v2/createSubAdmin.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/createSubAdmin.feature
@@ -9,7 +9,7 @@ Feature: create a subadmin
 
   @smokeTest
   Scenario: admin creates a subadmin
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "new-group" has been created
     When the administrator makes user "brand-new-user" a subadmin of group "new-group" using the provisioning API
     Then the OCS status code should be "200"
@@ -25,7 +25,7 @@ Feature: create a subadmin
     And user "not-user" should not be a subadmin of group "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
+    Given user "brand-new-user" has been created with default attributes and 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"
@@ -33,8 +33,8 @@ Feature: create a subadmin
 
   @issue-31276
   Scenario: subadmin of a group tries to make another user subadmin of their group
-    Given user "subadmin" has been created with default attributes
-    And user "brand-new-user" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
+    And user "brand-new-user" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     And user "brand-new-user" has been added to group "new-group"
diff --git a/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature b/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature
index 7123410daf8f..3418f77237d6 100644
--- a/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature
@@ -9,14 +9,14 @@ Feature: delete users
 
   @smokeTest
   Scenario: Delete a user
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and 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, and specify the user name in different case
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and 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"
@@ -24,8 +24,8 @@ Feature: delete users
 
   @smokeTest
   Scenario: subadmin deletes a user in their group
-    Given user "subadmin" has been created with default attributes
-    And user "brand-new-user" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
+    And user "brand-new-user" has been created with default attributes and skeleton files
     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"
@@ -36,8 +36,8 @@ Feature: delete users
 
   @issue-31276
   Scenario: normal user tries to delete a user
-    Given user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
     When user "user1" deletes user "user2" using the provisioning API
     Then the OCS status code should be "997"
     #And the OCS status code should be "401"
diff --git a/tests/acceptance/features/apiProvisioning-v2/disableApp.feature b/tests/acceptance/features/apiProvisioning-v2/disableApp.feature
index 898c61aa71eb..6ded89010d0e 100644
--- a/tests/acceptance/features/apiProvisioning-v2/disableApp.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/disableApp.feature
@@ -17,7 +17,7 @@ Feature: disable an app
 
   @issue-31276
   Scenario: subadmin tries to disable an app
-    Given user "subadmin" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
     And group "newgroup" has been created
     And user "subadmin" has been made a subadmin of group "newgroup"
     And app "comments" has been enabled
@@ -29,7 +29,7 @@ Feature: disable an app
 
   @issue-31276
   Scenario: normal user tries to disable an app
-    Given user "newuser" has been created with default attributes
+    Given user "newuser" has been created with default attributes and skeleton files
     And app "comments" has been enabled
     When user "newuser" disables app "comments"
     Then the OCS status code should be "997"
diff --git a/tests/acceptance/features/apiProvisioning-v2/disableUser.feature b/tests/acceptance/features/apiProvisioning-v2/disableUser.feature
index 051bdc319a84..37e65e6f113e 100644
--- a/tests/acceptance/features/apiProvisioning-v2/disableUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/disableUser.feature
@@ -9,7 +9,7 @@ Feature: disable user
 
   @smokeTest
   Scenario: admin disables an user
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     When the administrator disables user "user1" using the provisioning API
     Then the OCS status code should be "200"
     And the HTTP status code should be "200"
@@ -17,8 +17,8 @@ Feature: disable user
 
   @smokeTest
   Scenario: Subadmin should be able to disable an user in their group
-    Given user "subadmin" has been created with default attributes
-    And user "user1" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been added to group "new-group"
     And user "user1" has been added to group "new-group"
@@ -30,8 +30,8 @@ Feature: disable user
 
   @issue-31276
   Scenario: Subadmin should not be able to disable an user not in their group
-    Given user "subadmin" has been created with default attributes
-    And user "user1" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And group "another-group" has been created
     And user "subadmin" has been added to group "new-group"
@@ -45,8 +45,8 @@ Feature: disable user
 
   @issue-31276
   Scenario: Subadmins should not be able to disable users that have admin permissions in their group
-    Given user "another-admin" has been created with default attributes
-    And user "subadmin" has been created with default attributes
+    Given user "another-admin" has been created with default attributes and skeleton files
+    And user "subadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "another-admin" has been added to group "admin"
     And user "subadmin" has been added to group "new-group"
@@ -59,7 +59,7 @@ Feature: disable user
     And user "another-admin" should be enabled
 
   Scenario: Admin can disable another admin user
-    Given user "another-admin" has been created with default attributes
+    Given user "another-admin" has been created with default attributes and 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"
@@ -67,7 +67,7 @@ Feature: disable user
     And user "another-admin" should be disabled
 
   Scenario: Admin can disable subadmins in the same group
-    Given user "subadmin" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been added to group "new-group"
     And the administrator has been added to group "new-group"
@@ -78,7 +78,7 @@ Feature: disable user
     And user "subadmin" should be disabled
 
   Scenario: Admin user cannot disable himself
-    Given user "another-admin" has been created with default attributes
+    Given user "another-admin" has been created with default attributes and 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"
@@ -87,8 +87,8 @@ Feature: disable user
 
   @issue-31276
   Scenario: disable an user with a regular user
-    Given user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
     When user "user1" disables user "user2" using the provisioning API
     Then the OCS status code should be "997"
     #And the OCS status code should be "401"
@@ -96,7 +96,7 @@ Feature: disable user
     And user "user2" should be enabled
 
   Scenario: Subadmin should not be able to disable himself
-    Given user "subadmin" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been added to group "new-group"
     And user "subadmin" has been made a subadmin of group "new-group"
@@ -107,7 +107,7 @@ Feature: disable user
 
   @smokeTest
   Scenario: Making a web request with a disabled user
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And user "user0" has been disabled
     When user "user0" sends HTTP method "GET" to URL "/index.php/apps/files"
     And the HTTP status code should be "403"
\ No newline at end of file
diff --git a/tests/acceptance/features/apiProvisioning-v2/editUser.feature b/tests/acceptance/features/apiProvisioning-v2/editUser.feature
index 43c43caaea08..508ba8911945 100644
--- a/tests/acceptance/features/apiProvisioning-v2/editUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/editUser.feature
@@ -9,7 +9,7 @@ Feature: edit users
 
   @smokeTest
   Scenario: the administrator can edit a user email
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and 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"
@@ -17,14 +17,14 @@ Feature: edit users
 
   @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
+    Given user "brand-new-user" has been created with default attributes and 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
+    Given user "brand-new-user" has been created with default attributes and 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"
@@ -32,14 +32,14 @@ Feature: edit users
 
   @smokeTest
   Scenario: the administrator can edit a user quota
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and 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
+    Given user "brand-new-user" has been created with default attributes and 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"
@@ -50,8 +50,8 @@ Feature: edit users
 
   @smokeTest
   Scenario: a subadmin should be able to edit the user information in their group
-    Given user "subadmin" has been created with default attributes
-    And user "brand-new-user" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
+    And user "brand-new-user" has been created with default attributes and skeleton files
     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"
@@ -63,7 +63,7 @@ Feature: edit users
     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
+    Given user "brand-new-user" has been created with default attributes and 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"
@@ -72,7 +72,7 @@ Feature: edit users
     And the email address of user "brand-new-user" should be "brand-new-user@example.com"
 
   Scenario: a normal user should be able to change their display name
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     When user "brand-new-user" changes the display name of user "brand-new-user" to "Alan Border" using the provisioning API
     Then the OCS status code should be "200"
     And the HTTP status code should be "200"
@@ -81,7 +81,7 @@ Feature: edit users
     And the display name of user "brand-new-user" should be "Alan Border"
 
   Scenario: a normal user should not be able to change their quota
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and 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"
diff --git a/tests/acceptance/features/apiProvisioning-v2/enableApp.feature b/tests/acceptance/features/apiProvisioning-v2/enableApp.feature
index 4fc0137ff1a9..5883b5c42843 100644
--- a/tests/acceptance/features/apiProvisioning-v2/enableApp.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/enableApp.feature
@@ -17,7 +17,7 @@ Feature: enable an app
 
   @issue-31276
   Scenario: subadmin tries to enable an app
-    Given user "subadmin" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
     And group "newgroup" has been created
     And user "subadmin" has been made a subadmin of group "newgroup"
     And app "comments" has been disabled
@@ -29,7 +29,7 @@ Feature: enable an app
 
   @issue-31276
   Scenario: normal user tries to enable an app
-    Given user "newuser" has been created with default attributes
+    Given user "newuser" has been created with default attributes and skeleton files
     And app "comments" has been disabled
     When user "newuser" enables app "comments"
     Then the OCS status code should be "997"
diff --git a/tests/acceptance/features/apiProvisioning-v2/enableUser.feature b/tests/acceptance/features/apiProvisioning-v2/enableUser.feature
index eccaa258e680..ba11c97ee519 100644
--- a/tests/acceptance/features/apiProvisioning-v2/enableUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/enableUser.feature
@@ -9,7 +9,7 @@ Feature: enable user
 
   @smokeTest
   Scenario: admin enables an user
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has been disabled
     When the administrator enables user "user1" using the provisioning API
     Then the OCS status code should be "200"
@@ -17,7 +17,7 @@ Feature: enable user
     And user "user1" should be enabled
 
   Scenario: admin enables another admin user
-    Given user "another-admin" has been created with default attributes
+    Given user "another-admin" has been created with default attributes and 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
@@ -26,7 +26,7 @@ Feature: enable user
     And user "another-admin" should be enabled
 
   Scenario: admin enables subadmins in the same group
-    Given user "subadmin" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been added to group "new-group"
     And the administrator has been added to group "new-group"
@@ -38,7 +38,7 @@ Feature: enable user
     And user "subadmin" should be enabled
 
   Scenario: admin tries to enable himself
-    Given user "another-admin" has been created with default attributes
+    Given user "another-admin" has been created with default attributes and 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
@@ -46,8 +46,8 @@ Feature: enable user
 
   @issue-31276
   Scenario: normal user tries to enable other user
-    Given user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
     And user "user2" has been disabled
     When user "user1" tries to enable user "user2" using the provisioning API
     Then the OCS status code should be "997"
@@ -56,7 +56,7 @@ Feature: enable user
     And user "user2" should be disabled
 
   Scenario: subadmin tries to enable himself
-    Given user "subadmin" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been added to group "new-group"
     And user "subadmin" has been made a subadmin of group "new-group"
@@ -67,6 +67,6 @@ Feature: enable user
     And user "subadmin" should be disabled
 
   Scenario: Making a web request with an enabled user
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     When user "user0" sends HTTP method "GET" to URL "/index.php/apps/files"
     Then the HTTP status code should be "200"
\ No newline at end of file
diff --git a/tests/acceptance/features/apiProvisioning-v2/getSubAdmins.feature b/tests/acceptance/features/apiProvisioning-v2/getSubAdmins.feature
index 40aadb525fc4..a2ae13adec51 100644
--- a/tests/acceptance/features/apiProvisioning-v2/getSubAdmins.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/getSubAdmins.feature
@@ -9,7 +9,7 @@ Feature: get subadmins
 
   @smokeTest
   Scenario: admin gets subadmin users of a group
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "brand-new-user" has been made a subadmin of group "new-group"
     When the administrator gets all the subadmins of group "new-group" using the provisioning API
@@ -19,7 +19,7 @@ Feature: get subadmins
     And the HTTP status code should be "200"
 
   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
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "not-group" has been deleted
     When the administrator gets all the subadmins of group "not-group" using the provisioning API
     Then the OCS status code should be "400"
@@ -28,8 +28,8 @@ Feature: get subadmins
 
   @issue-31276
   Scenario: subadmin tries to get other subadmins of the same group
-    Given user "subadmin" has been created with default attributes
-    And user "newsubadmin" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
+    And user "newsubadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     And user "newsubadmin" has been made a subadmin of group "new-group"
@@ -41,8 +41,8 @@ Feature: get subadmins
 
   @issue-31276
   Scenario: normal user tries to get the subadmins of the group
-    Given user "newuser" has been created with default attributes
-    And user "subadmin" has been created with default attributes
+    Given user "newuser" has been created with default attributes and skeleton files
+    And user "subadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     When user "newuser" gets all the subadmins of group "new-group" using the provisioning API
diff --git a/tests/acceptance/features/apiProvisioning-v2/getUser.feature b/tests/acceptance/features/apiProvisioning-v2/getUser.feature
index 7a02fe97c077..a0a5e56faeea 100644
--- a/tests/acceptance/features/apiProvisioning-v2/getUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/getUser.feature
@@ -9,7 +9,7 @@ Feature: get user
 
   @smokeTest
   Scenario: admin gets an existing user
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and 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
@@ -26,7 +26,7 @@ Feature: get user
 
   @smokeTest
   Scenario: a subadmin gets information of a user in their group
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username | displayname |
       | subadmin | Sub Admin   |
       | newuser  | New User    |
@@ -40,8 +40,8 @@ Feature: get user
     And the quota definition returned by the API should be "default"
 
   Scenario: a subadmin tries to get information of a user not in their group
-    Given user "subadmin" has been created with default attributes
-    And user "newuser" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
+    And user "newuser" has been created with default attributes and skeleton files
     And group "newgroup" has been created
     And user "subadmin" has been made a subadmin of group "newgroup"
     When user "subadmin" retrieves the information of user "newuser" using the provisioning API
@@ -51,8 +51,8 @@ Feature: get user
 
   @issue-31276
   Scenario: a normal user tries to get information of another user
-    Given user "newuser" has been created with default attributes
-    And user "anotheruser" has been created with default attributes
+    Given user "newuser" has been created with default attributes and skeleton files
+    And user "anotheruser" has been created with default attributes and skeleton files
     When user "anotheruser" retrieves the information of user "newuser" using the provisioning API
     Then the OCS status code should be "997"
     #And the OCS status code should be "401"
@@ -61,7 +61,7 @@ Feature: get user
 
   @smokeTest
   Scenario: a normal user gets their own information
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username | displayname |
       | newuser  | New User    |
     When user "newuser" retrieves the information of user "newuser" using the provisioning API
diff --git a/tests/acceptance/features/apiProvisioning-v2/getUsers.feature b/tests/acceptance/features/apiProvisioning-v2/getUsers.feature
index 9237fcec5f2d..d2e1a5ee7e09 100644
--- a/tests/acceptance/features/apiProvisioning-v2/getUsers.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/getUsers.feature
@@ -9,7 +9,7 @@ Feature: get users
 
   @smokeTest
   Scenario: admin gets all users
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and 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"
@@ -19,8 +19,8 @@ Feature: get users
 
   @smokeTest
   Scenario: subadmin gets the users in their group
-    Given user "brand-new-user" has been created with default attributes
-    And user "another-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
+    And user "another-new-user" has been created with default attributes and skeleton files
     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"
@@ -32,8 +32,8 @@ Feature: get users
 
   @issue-31276
   Scenario: normal user tries to get other users
-    Given user "normaluser" has been created with default attributes
-    And user "newuser" has been created with default attributes
+    Given user "normaluser" has been created with default attributes and skeleton files
+    And user "newuser" has been created with default attributes and skeleton files
     When user "normaluser" gets the list of all users using the provisioning API
     Then the OCS status code should be "997"
     #And the OCS status code should be "401"
diff --git a/tests/acceptance/features/apiProvisioning-v2/removeSubAdmin.feature b/tests/acceptance/features/apiProvisioning-v2/removeSubAdmin.feature
index 665e0d2e7d18..63a068e02f1f 100644
--- a/tests/acceptance/features/apiProvisioning-v2/removeSubAdmin.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/removeSubAdmin.feature
@@ -9,7 +9,7 @@ Feature: remove subadmin
 
   @smokeTest
   Scenario: admin removes subadmin from a group
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "brand-new-user" has been made a subadmin of group "new-group"
     When the administrator removes user "brand-new-user" from being a subadmin of group "new-group" using the provisioning API
@@ -19,10 +19,10 @@ Feature: remove subadmin
 
   @issue-31276
   Scenario: subadmin tries to remove other subadmin in the group
-    Given user "subadmin" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
-    And user "newsubadmin" has been created with default attributes
+    And user "newsubadmin" has been created with default attributes and skeleton files
     And user "newsubadmin" has been made a subadmin of group "new-group"
     When user "subadmin" removes user "newsubadmin" from being a subadmin of group "new-group" using the provisioning API
     Then the OCS status code should be "997"
@@ -32,8 +32,8 @@ Feature: remove subadmin
 
   @issue-31276
   Scenario: normal user tries to remove subadmin in the group
-    Given user "subadmin" has been created with default attributes
-    And user "newuser" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
+    And user "newuser" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     And user "newuser" has been added to group "new-group"
diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature
index 30872315b94f..6f3311e7edc0 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v1/addGroup.feature
@@ -104,14 +104,14 @@ Feature: add groups
     And group "new-group" should exist
 
   Scenario: normal user tries to create a group
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     When user "brand-new-user" tries to send a group creation request for group "new-group" using the provisioning API
     Then the OCS status code should be "997"
     And the HTTP status code should be "401"
     And group "new-group" should not exist
 
   Scenario: subadmin tries to create a group
-    Given user "subadmin" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     When user "subadmin" tries to send a group creation request for group "another-group" using the provisioning API
diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature
index b733eb202344..5b4bfc602f3e 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature
@@ -9,7 +9,7 @@ Feature: add users to group
 
   @smokeTest
   Scenario Outline: adding a user to a group
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "<group_id>" has been created
     When the administrator adds user "brand-new-user" to group "<group_id>" using the provisioning API
     Then the OCS status code should be "100"
@@ -21,7 +21,7 @@ Feature: add users to group
       | नेपाली        | Unicode group name          |
 
   Scenario Outline: adding a user to a group
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "<group_id>" has been created
     When the administrator adds user "brand-new-user" to group "<group_id>" using the provisioning API
     Then the OCS status code should be "100"
@@ -48,7 +48,7 @@ Feature: add users to group
 
   @issue-31015
   Scenario Outline: 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
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     # After fixing issue-31015, change the following step to "has been created"
     And the administrator sends a group creation request for group "<group_id>" using the provisioning API
     #And group "<group_id>" has been created
@@ -66,7 +66,7 @@ Feature: add users to group
       | priv/subadmins/1 | Subadmins mentioned not at the end |
 
   Scenario Outline: adding a user to 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
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "<group_id1>" has been created
     And group "<group_id2>" has been created
     And group "<group_id3>" has been created
@@ -83,14 +83,14 @@ Feature: add users to group
       | brand-new-user | NEW-GROUP | New-Group | new-group |
 
   Scenario: normal user tries to add himself to a group
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     When user "brand-new-user" tries to add himself to group "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: admin tries to add user to a group which does not exist
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "not-group" has been deleted
     When the administrator tries to add user "brand-new-user" to group "not-group" using the provisioning API
     Then the OCS status code should be "102"
@@ -98,7 +98,7 @@ Feature: add users to group
     And the API should not return any data
 
   Scenario: admin tries to add user to a group without sending the group
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and 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"
@@ -113,8 +113,8 @@ Feature: add users to group
     And the API should not return any data
 
   Scenario: a subadmin cannot add users to groups the subadmin is responsible for
-    Given user "subadmin" has been created with default attributes
-    And user "brand-new-user" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
+    And user "brand-new-user" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     When user "subadmin" tries to add user "brand-new-user" to group "new-group" using the provisioning API
@@ -123,8 +123,8 @@ Feature: add users to group
     And user "brand-new-user" should not belong to group "new-group"
 
   Scenario: a subadmin cannot add users to groups the subadmin is not responsible for
-    Given user "other-subadmin" has been created with default attributes
-    And user "brand-new-user" has been created with default attributes
+    Given user "other-subadmin" has been created with default attributes and skeleton files
+    And user "brand-new-user" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And group "other-group" has been created
     And user "other-subadmin" has been made a subadmin of group "other-group"
diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/deleteGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/deleteGroup.feature
index 762c88abb8fd..6bc289f2c466 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v1/deleteGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v1/deleteGroup.feature
@@ -84,7 +84,7 @@ Feature: delete groups
       | 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
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "brand-new-user" has been added to group "new-group"
     When user "brand-new-user" tries to delete group "new-group" using the provisioning API
@@ -93,7 +93,7 @@ Feature: delete groups
     And group "new-group" should exist
 
   Scenario: subadmin of the group tries to delete the group
-    Given user "subadmin" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     When user "subadmin" tries to delete group "new-group" using the provisioning API
diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/getGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/getGroup.feature
index 838f61b891a7..de496b949164 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v1/getGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v1/getGroup.feature
@@ -9,8 +9,8 @@ Feature: get group
 
   @smokeTest
   Scenario: admin gets users in the group
-    Given user "brand-new-user" has been created with default attributes
-    And user "123" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
+    And user "123" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "brand-new-user" has been added to group "new-group"
     And user "123" has been added to group "new-group"
@@ -50,9 +50,9 @@ Feature: get group
 
   @smokeTest
   Scenario: subadmin gets users in a group they are responsible for
-    Given user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
-    And user "subadmin" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
+    And user "subadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     And user "user1" has been added to group "new-group"
@@ -65,7 +65,7 @@ Feature: get group
       | user2 |
 
   Scenario: subadmin tries to get users in a group they are not responsible for
-    Given user "subadmin" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And group "another-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
@@ -74,7 +74,7 @@ Feature: get group
     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
+    Given user "newuser" has been created with default attributes and skeleton files
     And group "new-group" has been created
     When user "newuser" gets all the members of group "new-group" using the provisioning API
     Then the OCS status code should be "997"
diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/getSubAdminGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v1/getSubAdminGroups.feature
index 7fc059941f51..c0843bcc0339 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v1/getSubAdminGroups.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v1/getSubAdminGroups.feature
@@ -9,7 +9,7 @@ Feature: get subadmin groups
 
   @smokeTest
   Scenario: admin gets subadmin groups of a user
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And group "😅 😆" has been created
     And user "brand-new-user" has been made a subadmin of group "new-group"
diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/getUserGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v1/getUserGroups.feature
index c819e5d34652..83ed73503d30 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v1/getUserGroups.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v1/getUserGroups.feature
@@ -9,7 +9,7 @@ Feature: get user groups
 
   @smokeTest
   Scenario: admin gets groups of an user
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "unused-group" has been created
     And group "new-group" has been created
     And group "0" has been created
@@ -37,7 +37,7 @@ Feature: get user groups
 	# Note: when the issue is fixed, use this scenario and delete the scenario above.
   @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
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "unused-group" has been created
     And group "new-group" has been created
     And group "0" has been created
@@ -79,8 +79,8 @@ Feature: get user groups
 
   @smokeTest
   Scenario: subadmin tries to get other groups of a user in their group
-    Given user "newuser" has been created with default attributes
-    And user "subadmin" has been created with default attributes
+    Given user "newuser" has been created with default attributes and skeleton files
+    And user "subadmin" has been created with default attributes and skeleton files
     And group "newgroup" has been created
     And group "anothergroup" has been created
     And user "subadmin" has been made a subadmin of group "newgroup"
@@ -93,8 +93,8 @@ Feature: get user groups
     And the HTTP status code should be "200"
 
   Scenario: normal user tries to get the groups of another user
-    Given user "newuser" has been created with default attributes
-    And user "anotheruser" has been created with default attributes
+    Given user "newuser" has been created with default attributes and skeleton files
+    And user "anotheruser" has been created with default attributes and skeleton files
     And group "newgroup" has been created
     And user "newuser" has been added to group "newgroup"
     When user "anotheruser" gets all the groups of user "newuser" using the provisioning API
@@ -103,7 +103,7 @@ Feature: get user groups
     And the API should not return any data
 
   Scenario: admin gets groups of an user who is not in any groups
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and 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"
diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature
index 63812f0709f6..19010ee50c76 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature
@@ -9,7 +9,7 @@ Feature: remove a user from a group
 
   @smokeTest
   Scenario Outline: admin removes a user from a group
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "<group_id>" has been created
     And user "brand-new-user" has been added to group "<group_id>"
     When the administrator removes user "brand-new-user" from group "<group_id>" using the provisioning API
@@ -23,7 +23,7 @@ Feature: remove a user from a group
       | नेपाली      | Unicode group name          |
 
   Scenario Outline: admin removes a user from a group
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "<group_id>" has been created
     And user "brand-new-user" has been added to group "<group_id>"
     When the administrator removes user "brand-new-user" from group "<group_id>" using the provisioning API
@@ -52,7 +52,7 @@ Feature: remove a user from a group
 
   @issue-31015
   Scenario Outline: 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
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     # After fixing issue-31015, change the following step to "has been created"
     And the administrator sends a group creation request for group "<group_id>" using the provisioning API
     #And group "<group_id>" has been created
@@ -72,7 +72,7 @@ Feature: remove a user from a group
       | priv/subadmins/1 | Subadmins mentioned not at the end |
 
   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
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "<group_id1>" has been created
     And group "<group_id2>" has been created
     And group "<group_id3>" has been created
@@ -92,7 +92,7 @@ Feature: remove a user from a group
       | brand-new-user | NEW-GROUP | New-Group | new-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
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "not-group" has been deleted
     When the administrator removes user "brand-new-user" from group "not-group" using the provisioning API
     Then the OCS status code should be "102"
@@ -101,8 +101,8 @@ Feature: remove a user from a group
 
   @smokeTest
   Scenario: a subadmin can remove users from groups the subadmin is responsible for
-    Given user "subadmin" has been created with default attributes
-    And user "brand-new-user" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
+    And user "brand-new-user" has been created with default attributes and skeleton files
     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"
@@ -112,8 +112,8 @@ Feature: remove a user from a group
     And user "brand-new-user" should not belong to group "new-group"
 
   Scenario: a subadmin cannot remove users from groups the subadmin is not responsible for
-    Given user "other-subadmin" has been created with default attributes
-    And user "brand-new-user" has been created with default attributes
+    Given user "other-subadmin" has been created with default attributes and skeleton files
+    And user "brand-new-user" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And group "other-group" has been created
     And user "brand-new-user" has been added to group "new-group"
@@ -124,8 +124,8 @@ Feature: remove a user from a group
     And user "brand-new-user" should belong to group "new-group"
 
   Scenario: normal user tries to remove a user in their group
-    Given user "newuser" has been created with default attributes
-    And user "anotheruser" has been created with default attributes
+    Given user "newuser" has been created with default attributes and skeleton files
+    And user "anotheruser" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "newuser" has been added to group "new-group"
     And user "anotheruser" has been added to group "new-group"
diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/addGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/addGroup.feature
index f5b69933cf70..9f4a283ba9f9 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v2/addGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v2/addGroup.feature
@@ -106,7 +106,7 @@ Feature: add groups
 
   @issue-31276
   Scenario: normal user tries to create a group
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     When user "brand-new-user" tries to send a group creation request for group "new-group" using the provisioning API
     Then the OCS status code should be "997"
     #And the OCS status code should be "401"
@@ -114,7 +114,7 @@ Feature: add groups
     And group "new-group" should not exist
 
   Scenario: subadmin tries to create a group
-    Given user "subadmin" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     When user "subadmin" tries to send a group creation request for group "another-group" using the provisioning API
diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature
index d93e9e415b4e..271fb7bd967a 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature
@@ -9,7 +9,7 @@ Feature: add users to group
 
   @smokeTest
   Scenario Outline: adding a user to a group
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "<group_id>" has been created
     When the administrator adds user "brand-new-user" to group "<group_id>" using the provisioning API
     Then the OCS status code should be "200"
@@ -21,7 +21,7 @@ Feature: add users to group
       | नेपाली      | Unicode group name          |
 
   Scenario Outline: adding a user to a group
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "<group_id>" has been created
     When the administrator adds user "brand-new-user" to group "<group_id>" using the provisioning API
     Then the OCS status code should be "200"
@@ -48,7 +48,7 @@ Feature: add users to group
 
   @issue-31015
   Scenario Outline: 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
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     # After fixing issue-31015, change the following step to "has been created"
     And the administrator sends a group creation request for group "<group_id>" using the provisioning API
     #And group "<group_id>" has been created
@@ -66,7 +66,7 @@ Feature: add users to group
       | priv/subadmins/1 | Subadmins mentioned not at the end |
 
   Scenario Outline: adding a user to 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
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "<group_id1>" has been created
     And group "<group_id2>" has been created
     And group "<group_id3>" has been created
@@ -84,7 +84,7 @@ Feature: add users to group
 
   @issue-31276
   Scenario: normal user tries to add himself to a group
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     When user "brand-new-user" tries to add himself to group "new-group" using the provisioning API
     Then the OCS status code should be "997"
     #And the OCS status code should be "401"
@@ -92,7 +92,7 @@ Feature: add users to group
     And the API should not return any data
 
   Scenario: admin tries to add user to a group which does not exist
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "not-group" has been deleted
     When the administrator tries to add user "brand-new-user" to group "not-group" using the provisioning API
     Then the OCS status code should be "400"
@@ -100,7 +100,7 @@ Feature: add users to group
     And the API should not return any data
 
   Scenario: admin tries to add user to a group without sending the group
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and 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"
@@ -115,8 +115,8 @@ Feature: add users to group
     And the API should not return any data
 
   Scenario: subadmin adds users to groups the subadmin is responsible for
-    Given user "subadmin" has been created with default attributes
-    And user "brand-new-user" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
+    And user "brand-new-user" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     When user "subadmin" tries to add user "brand-new-user" to group "new-group" using the provisioning API
@@ -125,8 +125,8 @@ Feature: add users to group
     And user "brand-new-user" should not belong to group "new-group"
 
   Scenario: subadmin tries to add user to groups the subadmin is not responsible for
-    Given user "other-subadmin" has been created with default attributes
-    And user "brand-new-user" has been created with default attributes
+    Given user "other-subadmin" has been created with default attributes and skeleton files
+    And user "brand-new-user" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And group "other-group" has been created
     And user "other-subadmin" has been made a subadmin of group "other-group"
diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/deleteGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/deleteGroup.feature
index b3cf27c0aa6c..cffc05d3ee5f 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v2/deleteGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v2/deleteGroup.feature
@@ -85,7 +85,7 @@ Feature: delete groups
 
   @issue-31276
   Scenario: normal user tries to delete the group
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "brand-new-user" has been added to group "new-group"
     When user "brand-new-user" tries to delete group "new-group" using the provisioning API
@@ -96,7 +96,7 @@ Feature: delete groups
 
   @issue-31276
   Scenario: subadmin of the group tries to delete the group
-    Given user "subadmin" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     When user "subadmin" tries to delete group "new-group" using the provisioning API
diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/getGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/getGroup.feature
index 9b2a13fa0300..9b581a43ecee 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v2/getGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v2/getGroup.feature
@@ -9,8 +9,8 @@ Feature: get group
 
   @smokeTest
   Scenario: admin gets users in the group
-    Given user "brand-new-user" has been created with default attributes
-    And user "123" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
+    And user "123" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "brand-new-user" has been added to group "new-group"
     And user "123" has been added to group "new-group"
@@ -50,9 +50,9 @@ Feature: get group
 
   @smokeTest
   Scenario: subadmin gets users in a group they are responsible for
-    Given user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
-    And user "subadmin" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
+    And user "subadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     And user "user1" has been added to group "new-group"
@@ -66,7 +66,7 @@ Feature: get group
 
   @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
+    Given user "subadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And group "another-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
@@ -77,7 +77,7 @@ Feature: get group
 
   @issue-31276
   Scenario: normal user tries to get users in their group
-    Given user "newuser" has been created with default attributes
+    Given user "newuser" has been created with default attributes and skeleton files
     And group "new-group" has been created
     When user "newuser" gets all the members of group "new-group" using the provisioning API
     Then the OCS status code should be "997"
diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/getSubAdminGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v2/getSubAdminGroups.feature
index 865b2d3a9182..7e81ac2525a9 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v2/getSubAdminGroups.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v2/getSubAdminGroups.feature
@@ -9,7 +9,7 @@ Feature: get subadmin groups
 
   @smokeTest
   Scenario: admin gets subadmin groups of a user
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And group "😅 😆" has been created
     And user "brand-new-user" has been made a subadmin of group "new-group"
diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/getUserGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v2/getUserGroups.feature
index bfbd49cf7207..7ca3691eb185 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v2/getUserGroups.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v2/getUserGroups.feature
@@ -9,7 +9,7 @@ Feature: get user groups
 
   @smokeTest
   Scenario: admin gets groups of an user
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "unused-group" has been created
     And group "new-group" has been created
     And group "0" has been created
@@ -37,7 +37,7 @@ Feature: get user groups
 	# Note: when the issue is fixed, use this scenario and delete the scenario above.
   @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
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "unused-group" has been created
     And group "new-group" has been created
     And group "0" has been created
@@ -79,8 +79,8 @@ Feature: get user groups
 
   @smokeTest
   Scenario: subadmin tries to get other groups of a user in their group
-    Given user "newuser" has been created with default attributes
-    And user "subadmin" has been created with default attributes
+    Given user "newuser" has been created with default attributes and skeleton files
+    And user "subadmin" has been created with default attributes and skeleton files
     And group "newgroup" has been created
     And group "anothergroup" has been created
     And user "subadmin" has been made a subadmin of group "newgroup"
@@ -94,8 +94,8 @@ Feature: get user groups
 
   @issue-31276
   Scenario: normal user tries to get the groups of another user
-    Given user "newuser" has been created with default attributes
-    And user "anotheruser" has been created with default attributes
+    Given user "newuser" has been created with default attributes and skeleton files
+    And user "anotheruser" has been created with default attributes and skeleton files
     And group "newgroup" has been created
     And user "newuser" has been added to group "newgroup"
     When user "anotheruser" gets all the groups of user "newuser" using the provisioning API
diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature
index 972ef0399471..75a99dcbaa03 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature
@@ -9,7 +9,7 @@ Feature: remove a user from a group
 
   @smokeTest
   Scenario Outline: admin removes a user from a group
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "<group_id>" has been created
     And user "brand-new-user" has been added to group "<group_id>"
     When the administrator removes user "brand-new-user" from group "<group_id>" using the provisioning API
@@ -23,7 +23,7 @@ Feature: remove a user from a group
       | नेपाली      | Unicode group name          |
 
    Scenario Outline: admin removes a user from a group
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "<group_id>" has been created
     And user "brand-new-user" has been added to group "<group_id>"
     When the administrator removes user "brand-new-user" from group "<group_id>" using the provisioning API
@@ -52,7 +52,7 @@ Feature: remove a user from a group
 
   @issue-31015
   Scenario Outline: 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
+    Given user "brand-new-user" has been created with default attributes and skeleton files
       # After fixing issue-31015, change the following step to "has been created"
     And the administrator sends a group creation request for group "<group_id>" using the provisioning API
     #And group "<group_id>" has been created
@@ -72,7 +72,7 @@ Feature: remove a user from a group
       | priv/subadmins/1 | Subadmins mentioned not at the end |
 
   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
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "<group_id1>" has been created
     And group "<group_id2>" has been created
     And group "<group_id3>" has been created
@@ -92,7 +92,7 @@ Feature: remove a user from a group
       | brand-new-user | NEW-GROUP | New-Group | new-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
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "not-group" has been deleted
     When the administrator removes user "brand-new-user" from group "not-group" using the provisioning API
     Then the OCS status code should be "400"
@@ -101,8 +101,8 @@ Feature: remove a user from a group
 
   @smokeTest
   Scenario: a subadmin can remove users from groups the subadmin is responsible for
-    Given user "subadmin" has been created with default attributes
-    And user "brand-new-user" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
+    And user "brand-new-user" has been created with default attributes and skeleton files
     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"
@@ -112,8 +112,8 @@ Feature: remove a user from a group
     And user "brand-new-user" should not belong to group "new-group"
 
   Scenario: a subadmin cannot remove users from groups the subadmin is not responsible for
-    Given user "other-subadmin" has been created with default attributes
-    And user "brand-new-user" has been created with default attributes
+    Given user "other-subadmin" has been created with default attributes and skeleton files
+    And user "brand-new-user" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And group "other-group" has been created
     And user "brand-new-user" has been added to group "new-group"
@@ -125,8 +125,8 @@ Feature: remove a user from a group
 
   @issue-31276
   Scenario: normal user tries to remove a user in their group
-    Given user "newuser" has been created with default attributes
-    And user "anotheruser" has been created with default attributes
+    Given user "newuser" has been created with default attributes and skeleton files
+    And user "anotheruser" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "newuser" has been added to group "new-group"
     And user "anotheruser" has been added to group "new-group"
diff --git a/tests/acceptance/features/apiShareManagement/acceptShares.feature b/tests/acceptance/features/apiShareManagement/acceptShares.feature
index bcb6de88bf82..1fdb38588b8a 100644
--- a/tests/acceptance/features/apiShareManagement/acceptShares.feature
+++ b/tests/acceptance/features/apiShareManagement/acceptShares.feature
@@ -7,9 +7,9 @@ Feature: accept/decline shares coming from internal users
   Background:
     Given using OCS API version "1"
     And using new DAV path
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
     And user "user2" has been added to group "grp1"
diff --git a/tests/acceptance/features/apiShareManagement/disableSharing.feature b/tests/acceptance/features/apiShareManagement/disableSharing.feature
index 43238431f673..7f98007c687a 100644
--- a/tests/acceptance/features/apiShareManagement/disableSharing.feature
+++ b/tests/acceptance/features/apiShareManagement/disableSharing.feature
@@ -6,8 +6,8 @@ Feature: sharing
 
   Background:
     Given using old DAV path
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
 
   @smokeTest
   Scenario Outline: user tries to share a file with another user when the sharing api has been disabled
@@ -98,7 +98,7 @@ Feature: sharing
   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 "<ocs_api_version>"
     And group "grp1" has been created
-    And user "user2" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
     And user "user2" has been added to group "grp1"
     And user "user1" has been added to group "grp1"
     When parameter "shareapi_only_share_with_group_members" of app "core" has been set to "yes"
@@ -114,7 +114,7 @@ Feature: sharing
     Given using OCS API version "<ocs_api_version>"
     And group "grp2" has been created
     And group "grp1" has been created
-    And user "user3" has been created with default attributes
+    And user "user3" has been created with default attributes and skeleton files
     And user "user3" has been added to group "grp2"
     And user "user1" has been added to group "grp1"
     When parameter "shareapi_only_share_with_group_members" of app "core" has been set to "yes"
@@ -143,7 +143,7 @@ Feature: sharing
   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 "<ocs_api_version>"
     And group "grp1" has been created
-    And user "user2" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
     And user "user2" has been added to group "grp1"
     And user "user1" has been added to group "grp1"
     When parameter "shareapi_allow_group_sharing" of app "core" has been set to "no"
diff --git a/tests/acceptance/features/apiShareManagement/mergeShare.feature b/tests/acceptance/features/apiShareManagement/mergeShare.feature
index b70145b48d2d..858375e2250d 100644
--- a/tests/acceptance/features/apiShareManagement/mergeShare.feature
+++ b/tests/acceptance/features/apiShareManagement/mergeShare.feature
@@ -4,8 +4,8 @@ Feature: sharing
   Background:
     Given using OCS API version "1"
     And using old DAV path
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
 
diff --git a/tests/acceptance/features/apiShareManagement/moveReceivedShare.feature b/tests/acceptance/features/apiShareManagement/moveReceivedShare.feature
index a8158b3a03bf..de65ee327fc7 100644
--- a/tests/acceptance/features/apiShareManagement/moveReceivedShare.feature
+++ b/tests/acceptance/features/apiShareManagement/moveReceivedShare.feature
@@ -4,9 +4,9 @@ Feature: sharing
   Background:
     Given using OCS API version "1"
     And using old DAV path
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
 
   Scenario: Keep usergroup shares (#22143)
     Given group "grp1" has been created
diff --git a/tests/acceptance/features/apiShareManagement/multilinksharing.feature b/tests/acceptance/features/apiShareManagement/multilinksharing.feature
index 1a2107a891aa..87efa0431f34 100644
--- a/tests/acceptance/features/apiShareManagement/multilinksharing.feature
+++ b/tests/acceptance/features/apiShareManagement/multilinksharing.feature
@@ -3,7 +3,7 @@ Feature: multilinksharing
 
   Background:
     Given using old DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And as user "user0"
 
   @smokeTest
diff --git a/tests/acceptance/features/apiShareManagement/reShare.feature b/tests/acceptance/features/apiShareManagement/reShare.feature
index 0dd952db91a9..09354bc74f43 100644
--- a/tests/acceptance/features/apiShareManagement/reShare.feature
+++ b/tests/acceptance/features/apiShareManagement/reShare.feature
@@ -3,12 +3,12 @@ Feature: sharing
 
   Background:
     Given using old DAV path
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
 
   Scenario Outline: User is not allowed to reshare file
     Given using OCS API version "<ocs_api_version>"
-    And user "user2" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
     And user "user0" has created a share with settings
       | path        | /textfile0.txt |
       | shareType   | 0              |
@@ -28,7 +28,7 @@ Feature: sharing
 
   Scenario Outline: User is not allowed to reshare file with more permissions
     Given using OCS API version "<ocs_api_version>"
-    And user "user2" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
     And user "user0" has created a share with settings
       | path        | /textfile0.txt |
       | shareType   | 0              |
@@ -48,7 +48,7 @@ Feature: sharing
 
   Scenario Outline: Do not allow reshare to exceed permissions
     Given using OCS API version "<ocs_api_version>"
-    And user "user2" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
     And user "user0" has created folder "/TMP"
     And user "user0" has created a share with settings
       | path        | /TMP  |
@@ -71,8 +71,8 @@ Feature: sharing
       | 2               | 404              |
 
   Scenario: Reshared files can be still accessed if a user in the middle removes it.
-    Given user "user2" has been created with default attributes
-    And user "user3" has been created with default attributes
+    Given user "user2" has been created with default attributes and skeleton files
+    And user "user3" has been created with default attributes and skeleton files
     And user "user0" has shared file "textfile0.txt" with user "user1"
     And user "user1" has moved file "/textfile0 (2).txt" to "/textfile0_shared.txt"
     And user "user1" has shared file "textfile0_shared.txt" with user "user2"
@@ -113,7 +113,7 @@ Feature: sharing
 
   Scenario Outline: resharing a file is not allowed when allow resharing has been disabled
     Given using OCS API version "<ocs_api_version>"
-    And user "user2" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
     And user "user0" has created a share with settings
       | path        | /textfile0.txt |
       | shareType   | 0              |
diff --git a/tests/acceptance/features/apiShareManagementBasic/createShare.feature b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
index a4c8d17f9e95..874c76a1c030 100644
--- a/tests/acceptance/features/apiShareManagementBasic/createShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
@@ -3,7 +3,7 @@ Feature: sharing
 
   Background:
     Given using old DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
 
   @smokeTest
   @skipOnEncryptionType:user-keys @issue-32322
@@ -238,7 +238,7 @@ Feature: sharing
 
   Scenario Outline: Share of folder and sub-folder to same user - core#20645
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And group "grp4" has been created
     And user "user1" has been added to group "grp4"
     When user "user0" shares file "/PARENT" with user "user1" using the sharing API
@@ -261,8 +261,8 @@ Feature: sharing
   @smokeTest
   Scenario Outline: Share of folder to a group
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
     And user "user2" has been added to group "grp1"
@@ -315,8 +315,8 @@ Feature: sharing
   @smokeTest
   Scenario: unique target names for incoming shares
     Given using OCS API version "1"
-    And user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
     And user "user0" has created folder "/foo"
     And user "user1" has created folder "/foo"
     When user "user0" shares file "/foo" with user "user2" using the sharing API
@@ -327,7 +327,7 @@ Feature: sharing
 
   Scenario Outline: sharing again an own file while belonging to a group
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
     And user "user1" has shared file "welcome.txt" with group "grp1"
@@ -622,8 +622,8 @@ Feature: sharing
 
   Scenario Outline: Share of folder to a group with emoji in the name
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
     And group "😀 😁" has been created
     And user "user1" has been added to group "😀 😁"
     And user "user2" has been added to group "😀 😁"
diff --git a/tests/acceptance/features/apiShareManagementBasic/deleteShare.feature b/tests/acceptance/features/apiShareManagementBasic/deleteShare.feature
index baaf26517c8c..1bcdb6613e81 100644
--- a/tests/acceptance/features/apiShareManagementBasic/deleteShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/deleteShare.feature
@@ -5,8 +5,8 @@ Feature: sharing
     Given using old DAV path
 
   Scenario Outline: Delete all group shares
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And using OCS API version "<ocs_api_version>"
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
@@ -23,7 +23,7 @@ Feature: sharing
 
   @smokeTest
   Scenario Outline: delete a share
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And user "user1" has been created with default attributes and without skeleton files
     And using OCS API version "<ocs_api_version>"
     And user "user0" has shared file "textfile0.txt" with user "user1"
@@ -86,7 +86,7 @@ Feature: sharing
   @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 "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And user "user1" has been created with default attributes and without skeleton files
     And user "user0" has created folder "/shared"
     And user "user0" has moved file "/textfile0.txt" to "/shared/shared_file.txt"
@@ -101,7 +101,7 @@ Feature: sharing
   @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 "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And user "user1" has been created with default attributes and without skeleton files
     And user "user0" has created folder "/shared"
     And user "user0" has created folder "/shared/sub"
@@ -124,7 +124,7 @@ Feature: sharing
       | username |
       | user0    |
       | user1    |
-    And user "user2" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
     And user "user2" has been added to group "grp1"
     And user "user1" has been added to group "grp1"
     And user "user2" has shared file "/PARENT/parent.txt" with group "grp1"
@@ -142,7 +142,7 @@ Feature: sharing
 
   Scenario: sharee of a read-only share folder tries to delete the shared folder
     Given using OCS API version "1"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And user "user1" has been created with default attributes and without skeleton files
     And user "user0" has created folder "/shared"
     And user "user0" has moved file "/textfile0.txt" to "/shared/shared_file.txt"
@@ -153,7 +153,7 @@ Feature: sharing
 
   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 "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And user "user1" has been created with default attributes and without skeleton files
     And user "user0" has created folder "/shared"
     And user "user0" has moved file "/textfile0.txt" to "/shared/shared_file.txt"
diff --git a/tests/acceptance/features/apiShareManagementBasic/updateShare.feature b/tests/acceptance/features/apiShareManagementBasic/updateShare.feature
index 3a7d24fca566..c588cf134ad4 100644
--- a/tests/acceptance/features/apiShareManagementBasic/updateShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/updateShare.feature
@@ -4,7 +4,7 @@ Feature: sharing
   Background:
     Given using OCS API version "1"
     And using old DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
 
   @smokeTest
   Scenario Outline: Allow modification of reshare
@@ -245,7 +245,7 @@ Feature: sharing
 
   Scenario Outline: keep group permissions in sync
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
     And user "user0" has shared file "textfile0.txt" with group "grp1"
@@ -431,7 +431,7 @@ Feature: sharing
   Scenario Outline: Increasing permissions is allowed for owner
     Given using OCS API version "<ocs_api_version>"
     And user "user1" has been created with default attributes and without skeleton files
-    And user "user2" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
     And group "grp1" has been created
     And user "user2" has been added to group "grp1"
     And user "user1" has been added to group "grp1"
diff --git a/tests/acceptance/features/apiShareOperations/accessToShare.feature b/tests/acceptance/features/apiShareOperations/accessToShare.feature
index 0b83137316de..b1e32e2db01b 100644
--- a/tests/acceptance/features/apiShareOperations/accessToShare.feature
+++ b/tests/acceptance/features/apiShareOperations/accessToShare.feature
@@ -3,8 +3,8 @@ Feature: sharing
 
   Background:
     Given using old DAV path
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
 
   @smokeTest
   Scenario Outline: Sharee can see the share
diff --git a/tests/acceptance/features/apiShareOperations/changingFilesShare.feature b/tests/acceptance/features/apiShareOperations/changingFilesShare.feature
index 6adab561d552..86848dc6c2f4 100644
--- a/tests/acceptance/features/apiShareOperations/changingFilesShare.feature
+++ b/tests/acceptance/features/apiShareOperations/changingFilesShare.feature
@@ -4,8 +4,8 @@ Feature: sharing
   Background:
     Given using OCS API version "1"
     And using old DAV path
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
 
   @smokeTest
   Scenario: moving a file into a share as recipient
diff --git a/tests/acceptance/features/apiShareOperations/downloadFromShare.feature b/tests/acceptance/features/apiShareOperations/downloadFromShare.feature
index 2e08d50286f9..b20b3de2165a 100644
--- a/tests/acceptance/features/apiShareOperations/downloadFromShare.feature
+++ b/tests/acceptance/features/apiShareOperations/downloadFromShare.feature
@@ -4,7 +4,7 @@ Feature: sharing
   Background:
     Given using OCS API version "1"
     And using old DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
 
   @smokeTest @public_link_share-feature-required
   Scenario: Downloading from upload-only share is forbidden
@@ -16,8 +16,8 @@ Feature: sharing
     And the HTTP status code should be "404"
 
   Scenario: Share a file by multiple channels and download from sub-folder and direct file share
-    Given user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
     And user "user2" has been added to group "grp1"
@@ -37,7 +37,7 @@ Feature: sharing
 
   @smokeTest
   Scenario: Download a file that is in a folder contained in a folder that has been shared with a user with default permissions
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     When user "user0" creates a share using the sharing API with settings
       | path      | PARENT |
       | shareType | user   |
@@ -45,7 +45,7 @@ Feature: sharing
     Then user "user1" should be able to download the range "bytes=1-7" of file "/PARENT (2)/CHILD/child.txt" using the sharing API and the content should be "wnCloud"
 
   Scenario: Download a file that is in a folder contained in a folder that has been shared with a group with default permissions
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
     When user "user0" has shared folder "PARENT" with group "grp1"
@@ -59,7 +59,7 @@ Feature: sharing
     Then the public should be able to download the range "bytes=1-7" of file "/CHILD/child.txt" from inside the last public shared folder with password "%public%" and the content should be "wnCloud"
 
   Scenario: Download a file that is in a folder contained in a folder that has been shared with a user with Read/Write permission
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     When user "user0" creates a share using the sharing API with settings
       | path        | PARENT |
       | shareType   | user   |
@@ -68,7 +68,7 @@ Feature: sharing
     Then user "user1" should be able to download the range "bytes=1-7" of file "/PARENT (2)/CHILD/child.txt" using the sharing API and the content should be "wnCloud"
 
   Scenario: Download a file that is in a folder contained in a folder that has been shared with a group with Read/Write permission
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
     When user "user0" creates a share using the sharing API with settings
@@ -87,7 +87,7 @@ Feature: sharing
     Then the public should be able to download the range "bytes=1-7" of file "/CHILD/child.txt" from inside the last public shared folder with password "%public%" and the content should be "wnCloud"
 
   Scenario: Download a file that is in a folder contained in a folder that has been shared with a user with Read only permission
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     When user "user0" creates a share using the sharing API with settings
       | path        | PARENT |
       | shareType   | user   |
@@ -96,7 +96,7 @@ Feature: sharing
     Then user "user1" should be able to download the range "bytes=1-7" of file "/PARENT (2)/CHILD/child.txt" using the sharing API and the content should be "wnCloud"
 
   Scenario: Download a file that is in a folder contained in a folder that has been shared with a group with Read only permission
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
     When user "user0" creates a share using the sharing API with settings
diff --git a/tests/acceptance/features/apiShareOperations/getWebDAVSharePermissions.feature b/tests/acceptance/features/apiShareOperations/getWebDAVSharePermissions.feature
index 32ac3037e747..9d85147003cb 100644
--- a/tests/acceptance/features/apiShareOperations/getWebDAVSharePermissions.feature
+++ b/tests/acceptance/features/apiShareOperations/getWebDAVSharePermissions.feature
@@ -3,8 +3,8 @@ Feature: sharing
 
   Background:
     Given using OCS API version "1"
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
 
   @smokeTest
   Scenario Outline: Correct webdav share-permissions for owned file
diff --git a/tests/acceptance/features/apiShareOperations/gettingShares.feature b/tests/acceptance/features/apiShareOperations/gettingShares.feature
index 897220e1162d..e1564710d4d1 100644
--- a/tests/acceptance/features/apiShareOperations/gettingShares.feature
+++ b/tests/acceptance/features/apiShareOperations/gettingShares.feature
@@ -3,8 +3,8 @@ Feature: sharing
 
   Background:
     Given using old DAV path
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
 
   @smokeTest
   Scenario Outline: getting all shares of a user using that user
@@ -35,8 +35,8 @@ Feature: sharing
   @smokeTest
   Scenario Outline: getting all shares of a file
     Given using OCS API version "<ocs_api_version>"
-    And user "user2" has been created with default attributes
-    And user "user3" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
+    And user "user3" has been created with default attributes and skeleton files
     And user "user0" has shared file "textfile0.txt" with user "user1"
     And user "user0" has shared file "textfile0.txt" with user "user2"
     When user "user0" gets all the shares from the file "textfile0.txt" using the sharing API
@@ -53,8 +53,8 @@ Feature: sharing
   @smokeTest
   Scenario Outline: getting all shares of a file with reshares
     Given using OCS API version "<ocs_api_version>"
-    And user "user2" has been created with default attributes
-    And user "user3" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
+    And user "user3" has been created with default attributes and skeleton files
     And user "user0" has shared file "textfile0.txt" with user "user1"
     And user "user1" has shared file "textfile0 (2).txt" with user "user2"
     When user "user0" gets all the shares with reshares from the file "textfile0.txt" using the sharing API
@@ -72,7 +72,7 @@ Feature: sharing
   Scenario Outline: User's own shares reshared to him don't appear when getting "shared with me" shares
     Given using OCS API version "<ocs_api_version>"
     And group "grp1" has been created
-    And user "user2" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
     And user "user2" has been added to group "grp1"
     And user "user2" has created folder "/shared"
     And user "user2" has moved file "/textfile0.txt" to "/shared/shared_file.txt"
@@ -120,7 +120,7 @@ Feature: sharing
 
   Scenario Outline: Get a share with a user that didn't receive the share
     Given using OCS API version "<ocs_api_version>"
-    And user "user2" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
     And user "user0" has shared file "textfile0.txt" with user "user1"
     When user "user2" gets the info of the last share using the sharing API
     Then the OCS status code should be "404"
@@ -133,7 +133,7 @@ Feature: sharing
   @skipOnLDAP
   Scenario: Share of folder to a group, remove user from that group
     Given using OCS API version "1"
-    And user "user2" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
     And group "group0" has been created
     And user "user1" has been added to group "group0"
     And user "user2" has been added to group "group0"
diff --git a/tests/acceptance/features/apiShareOperations/uploadToShare.feature b/tests/acceptance/features/apiShareOperations/uploadToShare.feature
index 6a0f8902931c..c8b6125acec6 100644
--- a/tests/acceptance/features/apiShareOperations/uploadToShare.feature
+++ b/tests/acceptance/features/apiShareOperations/uploadToShare.feature
@@ -3,7 +3,7 @@ Feature: sharing
 
   Background:
     Given using OCS API version "1"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
 
   @smokeTest @public_link_share-feature-required
   Scenario: Uploading same file to a public upload-only share multiple times
@@ -39,7 +39,7 @@ Feature: sharing
     And the HTTP status code should be "403"
 
   Scenario: Uploading file to a user read-only share folder does not work
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user0" has created a share with settings
       | path        | FOLDER |
       | shareType   | user   |
@@ -50,7 +50,7 @@ Feature: sharing
 
   Scenario Outline: Uploading file to a group read-only share folder does not work
     Given using <dav-path> DAV path
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
     And user "user0" has created a share with settings
@@ -86,7 +86,7 @@ Feature: sharing
 
   Scenario Outline: Uploading file to a user upload-only share folder works
     Given using <dav-path> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has created a share with settings
       | path        | FOLDER |
       | shareType   | user   |
@@ -101,7 +101,7 @@ Feature: sharing
 
   Scenario Outline: Uploading file to a group upload-only share folder works
     Given using <dav-path> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
     And user "user0" has created a share with settings
@@ -129,7 +129,7 @@ Feature: sharing
   @smokeTest
   Scenario Outline: Uploading file to a user read/write share folder works
     Given using <dav-path> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has created a share with settings
       | path        | FOLDER |
       | shareType   | user   |
@@ -144,7 +144,7 @@ Feature: sharing
 
   Scenario Outline: Uploading file to a group read/write share folder works
     Given using <dav-path> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
     And user "user0" has created a share with settings
@@ -162,7 +162,7 @@ Feature: sharing
   @smokeTest
   Scenario Outline: Check quota of owners parent directory of a shared file
     Given using <dav-path> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And the quota of user "user1" has been set to "0"
     And user "user0" has moved file "/welcome.txt" to "/myfile.txt"
     And user "user0" has shared file "myfile.txt" with user "user1"
@@ -185,7 +185,7 @@ Feature: sharing
 
   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> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has created a share with settings
       | path        | FOLDER |
       | shareType   | user   |
@@ -201,7 +201,7 @@ Feature: sharing
 
   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> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
     And user "user0" has created a share with settings
@@ -228,7 +228,7 @@ Feature: sharing
 
   Scenario Outline: Uploading to a user shared folder with upload-only permission when the sharer has unsufficient quota does not work
     Given using <dav-path> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has created a share with settings
       | path        | FOLDER |
       | shareType   | user   |
@@ -244,7 +244,7 @@ Feature: sharing
 
   Scenario Outline: Uploading to a group shared folder with upload-only permission when the sharer has unsufficient quota does not work
     Given using <dav-path> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
     And user "user0" has created a share with settings
@@ -300,7 +300,7 @@ Feature: sharing
 
   Scenario: Uploading a file in to a shared folder without edit permissions
     Given using new DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" creates folder "/READ_ONLY" using the WebDAV API
     And user "user0" has created a share with settings
       | path        | /READ_ONLY |
diff --git a/tests/acceptance/features/apiSharees/sharees.feature b/tests/acceptance/features/apiSharees/sharees.feature
index 5fc96a7551f7..4f848faf4e11 100644
--- a/tests/acceptance/features/apiSharees/sharees.feature
+++ b/tests/acceptance/features/apiSharees/sharees.feature
@@ -2,7 +2,7 @@
 Feature: sharees
 
   Background:
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
       | sharee1  |
@@ -453,7 +453,7 @@ Feature: sharees
   @skipOnLDAP
   Scenario Outline: Enumerate only group members - only show partial results from member groups
     Given using OCS API version "<ocs-api-version>"
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username | displayname |
       | another  | Another     |
     And user "Another" has been added to group "ShareeGroup2"
diff --git a/tests/acceptance/features/apiSharingNotifications/sharingNotifications.feature b/tests/acceptance/features/apiSharingNotifications/sharingNotifications.feature
index 2c517c46001f..5fd1ecfa3d12 100644
--- a/tests/acceptance/features/apiSharingNotifications/sharingNotifications.feature
+++ b/tests/acceptance/features/apiSharingNotifications/sharingNotifications.feature
@@ -8,7 +8,7 @@ Feature: Display notifications when receiving a share
     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 these users have been created with default attributes and skeleton files:
       | username |
       | user0    |
       | user1    |
diff --git a/tests/acceptance/features/apiTags/assignTags.feature b/tests/acceptance/features/apiTags/assignTags.feature
index 666362b553c2..2898a33342a5 100644
--- a/tests/acceptance/features/apiTags/assignTags.feature
+++ b/tests/acceptance/features/apiTags/assignTags.feature
@@ -4,7 +4,7 @@ Feature: Assign tags to file/folder
   So that I can organize the files/folders easily
 
   Background:
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username |
       | user0    |
       | user1    |
diff --git a/tests/acceptance/features/apiTags/assignTagsGroup.feature b/tests/acceptance/features/apiTags/assignTagsGroup.feature
index 45f2cebfe79d..cb75dfbd03ca 100644
--- a/tests/acceptance/features/apiTags/assignTagsGroup.feature
+++ b/tests/acceptance/features/apiTags/assignTagsGroup.feature
@@ -3,7 +3,7 @@ Feature: Title of your feature
   I want to use this template for my feature file
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And as user "user1"
 
   Scenario: User can assign tags when in the tag's groups
diff --git a/tests/acceptance/features/apiTags/createTags.feature b/tests/acceptance/features/apiTags/createTags.feature
index 4430997c28cf..4bb81c626e5c 100644
--- a/tests/acceptance/features/apiTags/createTags.feature
+++ b/tests/acceptance/features/apiTags/createTags.feature
@@ -5,7 +5,7 @@ Feature: Creation of tags
   So that I could categorize my files
 
   Background:
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username |
       | user0    |
       | user1    |
diff --git a/tests/acceptance/features/apiTags/deleteTags.feature b/tests/acceptance/features/apiTags/deleteTags.feature
index 77ff70349698..5cb00d6f009b 100644
--- a/tests/acceptance/features/apiTags/deleteTags.feature
+++ b/tests/acceptance/features/apiTags/deleteTags.feature
@@ -4,7 +4,7 @@ Feature: Deletion of tags
   I want to delete the tags that are already created
 
   Background:
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And as user "user0"
 
   @smokeTest
diff --git a/tests/acceptance/features/apiTags/editTags.feature b/tests/acceptance/features/apiTags/editTags.feature
index b6638a5d4e4f..dd351d97a465 100644
--- a/tests/acceptance/features/apiTags/editTags.feature
+++ b/tests/acceptance/features/apiTags/editTags.feature
@@ -4,7 +4,7 @@ Feature: Editing the tags
   I want to be able to change the tags I have created
 
   Background:
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And as user "user0"
 
   @smokeTest
diff --git a/tests/acceptance/features/apiTags/retreiveTags.feature b/tests/acceptance/features/apiTags/retreiveTags.feature
index 4da46497422e..b6f8d2642468 100644
--- a/tests/acceptance/features/apiTags/retreiveTags.feature
+++ b/tests/acceptance/features/apiTags/retreiveTags.feature
@@ -2,7 +2,7 @@
 Feature: tags
 
   Background:
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username |
       | user0    |
       | user1    |
diff --git a/tests/acceptance/features/apiTags/unassignTags.feature b/tests/acceptance/features/apiTags/unassignTags.feature
index 04725768f5af..8da20a46e8a9 100644
--- a/tests/acceptance/features/apiTags/unassignTags.feature
+++ b/tests/acceptance/features/apiTags/unassignTags.feature
@@ -4,7 +4,7 @@ Feature: Unassigning tags from file/folder
   I want to be able to remove tags from file/folder
 
   Background:
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username |
       | user0    |
       | user1    |
diff --git a/tests/acceptance/features/apiTrashbin/trashbinDelete.feature b/tests/acceptance/features/apiTrashbin/trashbinDelete.feature
index c1af28d7bc9f..e08cdd2edc09 100644
--- a/tests/acceptance/features/apiTrashbin/trashbinDelete.feature
+++ b/tests/acceptance/features/apiTrashbin/trashbinDelete.feature
@@ -11,7 +11,7 @@ Feature: files and folders can be deleted from the trashbin
   @smokeTest
   Scenario Outline: Trashbin can be emptied
     Given using <dav-path> DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And a new browser session for "user0" has been started
     And user "user0" has deleted file "/textfile0.txt"
     And user "user0" has deleted file "/textfile1.txt"
diff --git a/tests/acceptance/features/apiTrashbin/trashbinFilesFolders.feature b/tests/acceptance/features/apiTrashbin/trashbinFilesFolders.feature
index 8894a3d47b34..914d63ff20e7 100644
--- a/tests/acceptance/features/apiTrashbin/trashbinFilesFolders.feature
+++ b/tests/acceptance/features/apiTrashbin/trashbinFilesFolders.feature
@@ -11,7 +11,7 @@ Feature: files and folders exist in the trashbin after being deleted
   @smokeTest
   Scenario Outline: deleting a file moves it to trashbin
     Given using <dav-path> DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     When user "user0" deletes file "/textfile0.txt" using the WebDAV API
     Then as "user0" file "/textfile0.txt" should exist in trash
     But as "user0" file "/textfile0.txt" should not exist
@@ -22,7 +22,7 @@ Feature: files and folders exist in the trashbin after being deleted
 
   Scenario Outline: deleting a folder moves it to trashbin
     Given using <dav-path> DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And user "user0" has created folder "/tmp"
     When user "user0" deletes folder "/tmp" using the WebDAV API
     Then as "user0" folder "/tmp" should exist in trash
@@ -33,7 +33,7 @@ Feature: files and folders exist in the trashbin after being deleted
 
   Scenario Outline: deleting a file in a folder moves it to the trashbin root
     Given using <dav-path> DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And user "user0" has created folder "/new-folder"
     And user "user0" has moved file "/textfile0.txt" to "/new-folder/new-file.txt"
     When user "user0" deletes file "/new-folder/new-file.txt" using the WebDAV API
@@ -47,8 +47,8 @@ Feature: files and folders exist in the trashbin after being deleted
 
   Scenario Outline: deleting a file in a shared folder moves it to the trashbin root
     Given using <dav-path> DAV path
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/shared"
     And user "user0" has moved file "/textfile0.txt" to "/shared/shared_file.txt"
     And user "user0" has shared folder "/shared" with user "user1"
@@ -63,8 +63,8 @@ Feature: files and folders exist in the trashbin after being deleted
 
   Scenario Outline: deleting a shared folder moves it to trashbin
     Given using <dav-path> DAV path
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/shared"
     And user "user0" has moved file "/textfile0.txt" to "/shared/shared_file.txt"
     And user "user0" has shared folder "/shared" with user "user1"
@@ -77,8 +77,8 @@ Feature: files and folders exist in the trashbin after being deleted
 
   Scenario Outline: deleting a received folder doesn't move it to trashbin
     Given using <dav-path> DAV path
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/shared"
     And user "user0" has moved file "/textfile0.txt" to "/shared/shared_file.txt"
     And user "user0" has shared folder "/shared" with user "user1"
@@ -92,8 +92,8 @@ Feature: files and folders exist in the trashbin after being deleted
 
   Scenario Outline: deleting a file in a received folder moves it to trashbin
     Given using <dav-path> DAV path
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/shared"
     And user "user0" has moved file "/textfile0.txt" to "/shared/shared_file.txt"
     And user "user0" has shared folder "/shared" with user "user1"
@@ -112,7 +112,7 @@ Feature: files and folders exist in the trashbin after being deleted
   # thus testing the required behavior.
   Scenario Outline: trashbin can store two files with the same name but different origins when the files are deleted close together in time
     Given using <dav-path> DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And user "user0" has created folder "/folderA"
     And user "user0" has created folder "/folderB"
     And user "user0" has created folder "/folderC"
@@ -141,7 +141,7 @@ Feature: files and folders exist in the trashbin after being deleted
   # Note: the underlying acceptance test code ensures that each delete step is separated by a least 1 second
   Scenario Outline: trashbin can store two files with the same name but different origins when the deletes are separated by at least 1 second
     Given using <dav-path> DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And user "user0" has created folder "/folderA"
     And user "user0" has created folder "/folderB"
     And user "user0" has copied file "/textfile0.txt" to "/folderA/textfile0.txt"
@@ -163,7 +163,7 @@ Feature: files and folders exist in the trashbin after being deleted
   Scenario Outline: Deleting a folder into external storage moves it to the trashbin
     Given using <dav-path> DAV path
     And the administrator has invoked occ command "files:scan --all"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And user "user0" has created folder "/local_storage/tmp"
     And user "user0" has moved file "/textfile0.txt" to "/local_storage/tmp/textfile0.txt"
     When user "user0" deletes folder "/local_storage/tmp" using the WebDAV API
diff --git a/tests/acceptance/features/apiTrashbin/trashbinRestore.feature b/tests/acceptance/features/apiTrashbin/trashbinRestore.feature
index 7d917b729c4f..610c190bef7d 100644
--- a/tests/acceptance/features/apiTrashbin/trashbinRestore.feature
+++ b/tests/acceptance/features/apiTrashbin/trashbinRestore.feature
@@ -10,8 +10,8 @@ Feature: Restore deleted files/folders
 
   Scenario Outline: deleting a file in a received folder when restored it comes back to the original path
     Given using <dav-path> DAV path
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/shared"
     And user "user0" has moved file "/textfile0.txt" to "/shared/shared_file.txt"
     And user "user0" has shared folder "/shared" with user "user1"
@@ -31,7 +31,7 @@ Feature: Restore deleted files/folders
   @smokeTest
   Scenario Outline: A deleted file can be restored
     Given using <dav-path> DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And user "user0" has deleted file "/textfile0.txt"
     And as "user0" file "/textfile0.txt" should exist in trash
     And user "user0" has logged in to a web-style session
@@ -53,7 +53,7 @@ Feature: Restore deleted files/folders
 
   Scenario Outline: A file deleted from a folder can be restored to the original folder
     Given using <dav-path> DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And user "user0" has created folder "/new-folder"
     And user "user0" has moved file "/textfile0.txt" to "/new-folder/new-file.txt"
     And user "user0" has deleted file "/new-folder/new-file.txt"
@@ -68,7 +68,7 @@ Feature: Restore deleted files/folders
 
   Scenario Outline: A file deleted from a folder is restored to root if the original folder does not exist
     Given using <dav-path> DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And user "user0" has created folder "/new-folder"
     And user "user0" has moved file "/textfile0.txt" to "/new-folder/new-file.txt"
     And user "user0" has deleted file "/new-folder/new-file.txt"
@@ -84,7 +84,7 @@ Feature: Restore deleted files/folders
 
   Scenario Outline: A file deleted from a folder is restored to the original folder if the original folder was deleted and restored
     Given using <dav-path> DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And user "user0" has created folder "/new-folder"
     And user "user0" has moved file "/textfile0.txt" to "/new-folder/new-file.txt"
     And user "user0" has deleted file "/new-folder/new-file.txt"
@@ -101,7 +101,7 @@ Feature: Restore deleted files/folders
 
   Scenario Outline: A file deleted from a folder is restored to the original folder if the original folder was deleted and recreated
     Given using <dav-path> DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And user "user0" has created folder "/new-folder"
     And user "user0" has moved file "/textfile0.txt" to "/new-folder/new-file.txt"
     And user "user0" has deleted file "/new-folder/new-file.txt"
@@ -122,7 +122,7 @@ Feature: Restore deleted files/folders
   Scenario Outline: Deleting a file into external storage moves it to the trashbin and can be restored
     Given using <dav-path> DAV path
     And the administrator has invoked occ command "files:scan --all"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And user "user0" has created folder "/local_storage/tmp"
     And user "user0" has moved file "/textfile0.txt" to "/local_storage/tmp/textfile0.txt"
     And user "user0" has deleted file "/local_storage/tmp/textfile0.txt"
@@ -145,7 +145,7 @@ Feature: Restore deleted files/folders
   Scenario: Deleting an updated file into external storage moves it to the trashbin and can be restored
     Given using old DAV path
     And the administrator has invoked occ command "files:scan --all"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And user "user0" has created folder "/local_storage/tmp"
     And user "user0" has moved file "/textfile0.txt" to "/local_storage/tmp/textfile0.txt"
     And user "user0" has uploaded chunk file "1" of "1" with "AA" to "/local_storage/tmp/textfile0.txt"
@@ -162,7 +162,7 @@ Feature: Restore deleted files/folders
   Scenario: Deleting an updated file into external storage moves it to the trashbin and can be restored
     Given using new DAV path
     And the administrator has invoked occ command "files:scan --all"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And user "user0" has created folder "/local_storage/tmp"
     And user "user0" has moved file "/textfile0.txt" to "/local_storage/tmp/textfile0.txt"
     And user "user0" has uploaded the following chunks to "/local_storage/tmp/textfile0.txt" with new chunking
diff --git a/tests/acceptance/features/apiVersions/fileVersions.feature b/tests/acceptance/features/apiVersions/fileVersions.feature
index 05cc03151be4..441228284fcf 100644
--- a/tests/acceptance/features/apiVersions/fileVersions.feature
+++ b/tests/acceptance/features/apiVersions/fileVersions.feature
@@ -5,7 +5,7 @@ Feature: dav-versions
   Background:
     Given using OCS API version "2"
     And using new DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And file "/davtest.txt" has been deleted for user "user0"
 
   Scenario: Upload file and no version is available
@@ -94,14 +94,14 @@ Feature: dav-versions
     And as user "user0" the webdav checksum of "/davtest.txt" via propfind should match "SHA1:acfa6b1565f9710d4d497c6035d5c069bd35a8e8 MD5:45a72715acdd5019c5be30bdbb75233e ADLER32:1ecd03df"
 
   Scenario: User cannot access meta folder of a file which is owned by somebody else
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user0" has uploaded file with content "123" to "/davtest.txt"
     And we save it into "FILEID"
     When user "user1" sends HTTP method "PROPFIND" to URL "/remote.php/dav/meta/<<FILEID>>"
     Then the HTTP status code should be "404"
 
   Scenario: User can access meta folder of a file which is owned by somebody else but shared with that user
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user0" has uploaded file with content "123" to "/davtest.txt"
     And user "user0" has uploaded file with content "456789" to "/davtest.txt"
     And we save it into "FILEID"
@@ -113,7 +113,7 @@ Feature: dav-versions
     Then the version folder of fileId "<<FILEID>>" for user "user1" should contain "1" element
 
   Scenario: sharer of a file can see the old version information when the sharee changes the content of the file
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user0" has uploaded file with content "user0 content" to "sharefile.txt"
     And user "user0" has shared file "sharefile.txt" with user "user1"
     When user "user1" has uploaded file with content "user1 content" to "/sharefile.txt"
@@ -121,7 +121,7 @@ Feature: dav-versions
     And the version folder of file "/sharefile.txt" for user "user0" should contain "1" element
 
   Scenario: sharer of a file can restore the original content of a shared file after the file has been modified by the sharee
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user0" has uploaded file with content "user0 content" to "sharefile.txt"
     And user "user0" has shared file "sharefile.txt" with user "user1"
     And user "user1" has uploaded file with content "user1 content" to "/sharefile.txt"
@@ -131,7 +131,7 @@ Feature: dav-versions
     And the content of file "/sharefile.txt" for user "user1" should be "user0 content"
 
   Scenario: sharer can restore a file inside a shared folder modified by sharee
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/sharingfolder"
     And user "user0" has shared folder "/sharingfolder" with user "user1"
     And user "user0" has uploaded file with content "user0 content" to "/sharingfolder/sharefile.txt"
@@ -142,7 +142,7 @@ Feature: dav-versions
     And the content of file "/sharingfolder/sharefile.txt" for user "user1" should be "user0 content"
 
   Scenario: sharee can restore a file inside a shared folder modified by sharee
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/sharingfolder"
     And user "user0" has shared folder "/sharingfolder" with user "user1"
     And user "user0" has uploaded file with content "user0 content" to "/sharingfolder/sharefile.txt"
@@ -153,7 +153,7 @@ Feature: dav-versions
     And the content of file "/sharingfolder/sharefile.txt" for user "user1" should be "user0 content"
 
   Scenario: sharer can restore a file inside a shared folder created by sharee and modified by sharer
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/sharingfolder"
     And user "user0" has shared folder "/sharingfolder" with user "user1"
     And user "user1" has uploaded file with content "user1 content" to "/sharingfolder/sharefile.txt"
@@ -164,7 +164,7 @@ Feature: dav-versions
     And the content of file "/sharingfolder/sharefile.txt" for user "user1" should be "user1 content"
 
   Scenario: sharee can restore a file inside a shared folder created by sharee and modified by sharer
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/sharingfolder"
     And user "user0" has shared folder "/sharingfolder" with user "user1"
     And user "user1" has uploaded file with content "user1 content" to "/sharingfolder/sharefile.txt"
@@ -175,7 +175,7 @@ Feature: dav-versions
     And the content of file "/sharingfolder/sharefile.txt" for user "user1" should be "user1 content"
 
   Scenario: sharer can restore a file inside a shared folder created by sharee and modified by sharee
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/sharingfolder"
     And user "user0" has shared folder "/sharingfolder" with user "user1"
     And user "user1" has uploaded file with content "old content" to "/sharingfolder/sharefile.txt"
@@ -186,7 +186,7 @@ Feature: dav-versions
     And the content of file "/sharingfolder/sharefile.txt" for user "user1" should be "old content"
 
   Scenario: sharee can restore a file inside a shared folder created by sharer and modified by sharer
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/sharingfolder"
     And user "user0" has shared folder "/sharingfolder" with user "user1"
     And user "user0" has uploaded file with content "old content" to "/sharingfolder/sharefile.txt"
@@ -197,7 +197,7 @@ Feature: dav-versions
     And the content of file "/sharingfolder/sharefile.txt" for user "user1" should be "old content"
 
   Scenario: sharee can restore a file inside a shared folder created by sharer and modified by sharer, when the folder has been moved by the sharee
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/sharingfolder"
     And user "user0" has shared folder "/sharingfolder" with user "user1"
     And user "user0" has uploaded file with content "old content" to "/sharingfolder/sharefile.txt"
@@ -210,7 +210,7 @@ Feature: dav-versions
     And the content of file "/received/sharingfolder/sharefile.txt" for user "user1" should be "old content"
 
   Scenario: sharee can restore a shared file created and modified by sharer, when the file has been moved by the sharee (file is at the top level of the sharer)
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user0" has uploaded file with content "old content" to "/sharefile.txt"
     And user "user0" has uploaded file with content "new content" to "/sharefile.txt"
     And user "user0" has shared file "/sharefile.txt" with user "user1"
@@ -222,7 +222,7 @@ Feature: dav-versions
     And the content of file "/received/sharefile.txt" for user "user1" should be "old content"
 
   Scenario: sharee can restore a shared file created and modified by sharer, when the file has been moved by the sharee (file is inside a folder of the sharer)
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/sharingfolder"
     And user "user0" has uploaded file with content "old content" to "/sharingfolder/sharefile.txt"
     And user "user0" has uploaded file with content "new content" to "/sharingfolder/sharefile.txt"
@@ -235,8 +235,8 @@ Feature: dav-versions
     And the content of file "/received/sharefile.txt" for user "user1" should be "old content"
 
   Scenario: sharer can restore a file inside a group shared folder modified by sharee
-    Given user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
     And user "user2" has been added to group "grp1"
diff --git a/tests/acceptance/features/apiWebdavLocks/exclusiveLocks.feature b/tests/acceptance/features/apiWebdavLocks/exclusiveLocks.feature
index bb7d63c5650c..7628fd00f9b1 100644
--- a/tests/acceptance/features/apiWebdavLocks/exclusiveLocks.feature
+++ b/tests/acceptance/features/apiWebdavLocks/exclusiveLocks.feature
@@ -2,7 +2,7 @@
 Feature: there can be only one exclusive lock on a resource
 
   Background:
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
 
   Scenario Outline: a second lock cannot be set on a folder when its exclusively locked
     Given using <dav-path> DAV path
@@ -86,7 +86,7 @@ Feature: there can be only one exclusive lock on a resource
 
   Scenario Outline: a share receiver cannot lock a resource exclusively locked by itself
     Given using <dav-path> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has shared file "textfile0.txt" with user "user1"
     And user "user1" has locked file "textfile0 (2).txt" setting following properties
       | lockscope | exclusive |
@@ -104,7 +104,7 @@ Feature: there can be only one exclusive lock on a resource
 
   Scenario Outline: a share receiver cannot lock a resource exclusively locked by the owner
     Given using <dav-path> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has shared file "textfile0.txt" with user "user1"
     And user "user0" has locked file "textfile0.txt" setting following properties
       | lockscope | exclusive |
@@ -122,7 +122,7 @@ Feature: there can be only one exclusive lock on a resource
 
   Scenario Outline: a share owner cannot lock a resource exclusively locked by a share receiver
     Given using <dav-path> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has shared file "textfile0.txt" with user "user1"
     And user "user1" has locked file "textfile0 (2).txt" setting following properties
       | lockscope | exclusive |
diff --git a/tests/acceptance/features/apiWebdavLocks/folder.feature b/tests/acceptance/features/apiWebdavLocks/folder.feature
index 5f22a6ca35f1..cf3d90f1b67d 100644
--- a/tests/acceptance/features/apiWebdavLocks/folder.feature
+++ b/tests/acceptance/features/apiWebdavLocks/folder.feature
@@ -2,7 +2,7 @@
 Feature: lock folders
 
   Background:
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
 
   Scenario Outline: upload to a locked folder
     Given using <dav-path> DAV path
diff --git a/tests/acceptance/features/apiWebdavLocks/publicLink.feature b/tests/acceptance/features/apiWebdavLocks/publicLink.feature
index 2aa2757a7dfb..48a46fc1b129 100644
--- a/tests/acceptance/features/apiWebdavLocks/publicLink.feature
+++ b/tests/acceptance/features/apiWebdavLocks/publicLink.feature
@@ -2,7 +2,7 @@
 Feature: persistent-locking in case of a public link
 
   Background:
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
 
   Scenario Outline: Uploading a file into a locked public folder
     Given using <dav-path> DAV path
diff --git a/tests/acceptance/features/apiWebdavLocks/publicLinkLockdiscovery.feature b/tests/acceptance/features/apiWebdavLocks/publicLinkLockdiscovery.feature
index 5f3401ecd244..79dd359dd0f4 100644
--- a/tests/acceptance/features/apiWebdavLocks/publicLinkLockdiscovery.feature
+++ b/tests/acceptance/features/apiWebdavLocks/publicLinkLockdiscovery.feature
@@ -2,7 +2,7 @@
 Feature: LOCKDISCOVERY for public links
 
   Background:
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
 
   Scenario Outline: lockdiscovery root of public link when root is locked
     Given user "user0" has created a public link share of folder "PARENT" with change permission
diff --git a/tests/acceptance/features/apiWebdavLocks/requestsWithToken.feature b/tests/acceptance/features/apiWebdavLocks/requestsWithToken.feature
index ac009f869b50..c5a22a6200c1 100644
--- a/tests/acceptance/features/apiWebdavLocks/requestsWithToken.feature
+++ b/tests/acceptance/features/apiWebdavLocks/requestsWithToken.feature
@@ -2,7 +2,7 @@
 Feature: actions on a locked item are possible if the token is sent with the request
 
   Background:
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
 
   Scenario Outline: rename a file in a locked folder
     Given using <dav-path> DAV path
@@ -54,7 +54,7 @@ Feature: actions on a locked item are possible if the token is sent with the req
   @issue-34338
   Scenario Outline: share receiver cannot rename a file in a folder locked by the owner even when sending the locktoken
     Given using <dav-path> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has shared folder "PARENT" with user "user1"
     And user "user0" has locked folder "PARENT" setting following properties
       | lockscope | <lock-scope> |
@@ -88,7 +88,7 @@ Feature: actions on a locked item are possible if the token is sent with the req
   @issue-34360
   Scenario Outline: two users having both a shared lock can use the resource
     Given using <dav-path> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has shared file "textfile0.txt" with user "user1"
     And user "user0" has locked file "textfile0.txt" setting following properties
       | lockscope | shared |
diff --git a/tests/acceptance/features/apiWebdavLocks2/resharedShares.feature b/tests/acceptance/features/apiWebdavLocks2/resharedShares.feature
index 68af5beca863..d686d88fe1fa 100644
--- a/tests/acceptance/features/apiWebdavLocks2/resharedShares.feature
+++ b/tests/acceptance/features/apiWebdavLocks2/resharedShares.feature
@@ -2,7 +2,7 @@
 Feature: lock should propagate correctly if a share is reshared
 
   Background:
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
     | username |
     | user0    |
     | user1    |
diff --git a/tests/acceptance/features/apiWebdavLocks2/setTimeout.feature b/tests/acceptance/features/apiWebdavLocks2/setTimeout.feature
index 7f80ebfd3bdf..b479f1e0ac9a 100644
--- a/tests/acceptance/features/apiWebdavLocks2/setTimeout.feature
+++ b/tests/acceptance/features/apiWebdavLocks2/setTimeout.feature
@@ -2,7 +2,7 @@
 Feature: set timeouts of LOCKS
 
   Background:
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
 
   Scenario Outline: set timeout on folder
     Given using <dav-path> DAV path
@@ -33,7 +33,7 @@ Feature: set timeouts of LOCKS
 
   Scenario Outline: as owner set timeout on folder as receiver check it
     Given using <dav-path> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has shared folder "PARENT" with user "user1"
     When user "user0" locks folder "PARENT" using the WebDAV API setting following properties
       | lockscope | shared    |
@@ -62,7 +62,7 @@ Feature: set timeouts of LOCKS
 
   Scenario Outline: as share receiver set timeout on folder as owner check it
     Given using <dav-path> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has shared folder "PARENT" with user "user1"
     When user "user1" locks folder "PARENT (2)" using the WebDAV API setting following properties
       | lockscope | shared    |
diff --git a/tests/acceptance/features/apiWebdavLocks2/unlock.feature b/tests/acceptance/features/apiWebdavLocks2/unlock.feature
index 6befd1349cda..711d7a946824 100644
--- a/tests/acceptance/features/apiWebdavLocks2/unlock.feature
+++ b/tests/acceptance/features/apiWebdavLocks2/unlock.feature
@@ -2,7 +2,7 @@
 Feature: UNLOCK locked items
 
   Background:
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     
   Scenario Outline: unlock a single lock set by the user itself
     Given using <dav-path> DAV path
@@ -48,7 +48,7 @@ Feature: UNLOCK locked items
 
   Scenario Outline: as share receiver unlocking a shared file locked by the file owner is not possible. To unlock use the owners locktoken
     Given using <dav-path> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has locked file "PARENT/parent.txt" setting following properties
       | lockscope | <lock-scope> |
     And user "user0" has shared file "PARENT/parent.txt" with user "user1"
@@ -65,7 +65,7 @@ Feature: UNLOCK locked items
 
   Scenario Outline: as share receiver unlocking a file in a share locked by the file owner is not possible. To unlock use the owners locktoken
     Given using <dav-path> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has locked file "PARENT/parent.txt" setting following properties
       | lockscope | <lock-scope> |
     And user "user0" has shared folder "PARENT" with user "user1"
@@ -82,7 +82,7 @@ Feature: UNLOCK locked items
 
   Scenario Outline: as share receiver unlocking a shared folder locked by the file owner is not possible. To unlock use the owners locktoken
     Given using <dav-path> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has locked folder "PARENT" setting following properties
       | lockscope | <lock-scope> |
     And user "user0" has shared folder "PARENT" with user "user1"
@@ -103,7 +103,7 @@ Feature: UNLOCK locked items
 
   Scenario Outline: as share receiver unlocking a shared file locked by the file owner is not possible. To unlock use the owners locktoken
     Given using <dav-path> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has locked file "PARENT/parent.txt" setting following properties
       | lockscope | <lock-scope> |
     And user "user0" has shared file "PARENT/parent.txt" with user "user1"
@@ -120,7 +120,7 @@ Feature: UNLOCK locked items
 
   Scenario Outline: as share receiver unlock a shared file
     Given using <dav-path> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has shared file "PARENT/parent.txt" with user "user1"
     And user "user1" has locked file "parent.txt" setting following properties
       | lockscope | <lock-scope> |
@@ -137,7 +137,7 @@ Feature: UNLOCK locked items
 
   Scenario Outline: as owner unlocking a shared file locked by the receiver is not possible. To unlock use the receivers locktoken
     Given using <dav-path> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has shared file "PARENT/parent.txt" with user "user1"
     And user "user1" has locked file "parent.txt" setting following properties
       | lockscope | <lock-scope> |
@@ -154,7 +154,7 @@ Feature: UNLOCK locked items
 
   Scenario Outline: as owner unlocking a file in a share that was locked by the share receiver is not possible. To unlock use the receivers locktoken
     Given using <dav-path> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has shared folder "PARENT" with user "user1"
     And user "user1" has locked file "PARENT (2)/parent.txt" setting following properties
       | lockscope | <lock-scope> |
@@ -171,7 +171,7 @@ Feature: UNLOCK locked items
 
   Scenario Outline: as owner unlocking a shared folder locked by the share receiver is not possible. To unlock use the receivers locktoken
     Given using <dav-path> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has shared folder "PARENT" with user "user1"
     And user "user1" has locked folder "PARENT (2)" setting following properties
       | lockscope | <lock-scope> |
diff --git a/tests/acceptance/features/apiWebdavMove/moveFile.feature b/tests/acceptance/features/apiWebdavMove/moveFile.feature
index 60409be02e2a..b01c7aea23ee 100644
--- a/tests/acceptance/features/apiWebdavMove/moveFile.feature
+++ b/tests/acceptance/features/apiWebdavMove/moveFile.feature
@@ -6,7 +6,7 @@ Feature: move (rename) file
 
   Background:
     Given using OCS API version "1"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
 
   @smokeTest
   Scenario Outline: Moving a file
@@ -66,7 +66,7 @@ Feature: move (rename) file
 
   Scenario Outline: Moving a file to a folder with no permissions
     Given using <dav_version> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user1" has created folder "/testshare"
     And user "user1" has created a share with settings
       | path        | testshare |
@@ -84,7 +84,7 @@ Feature: move (rename) file
 
   Scenario Outline: Moving a file to overwrite a file in a folder with no permissions
     Given using <dav_version> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user1" has created folder "/testshare"
     And user "user1" has created a share with settings
       | path        | testshare |
@@ -141,7 +141,7 @@ Feature: move (rename) file
 
   Scenario Outline: Checking file id after a move between received shares
     Given using <dav_version> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/folderA"
     And user "user0" has created folder "/folderB"
     And user "user0" has shared folder "/folderA" with user "user1"
diff --git a/tests/acceptance/features/apiWebdavMove/moveFileAsync.feature b/tests/acceptance/features/apiWebdavMove/moveFileAsync.feature
index 47a09df906c9..5f616acbaedf 100644
--- a/tests/acceptance/features/apiWebdavMove/moveFileAsync.feature
+++ b/tests/acceptance/features/apiWebdavMove/moveFileAsync.feature
@@ -6,7 +6,7 @@ Feature: move (rename) file
 
   Background:
     Given using new DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And the administrator has enabled async operations
 
   Scenario Outline: Moving a file
@@ -84,7 +84,7 @@ Feature: move (rename) file
       | /textfile1.txt |
 
   Scenario: Moving a file to a folder with no permissions
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has created folder "/testshare"
     And user "user1" has created a share with settings
       | path        | testshare |
@@ -102,7 +102,7 @@ Feature: move (rename) file
       | /textfile0.txt |
 
   Scenario: Moving a file to overwrite a file in a folder with no permissions
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has created folder "/testshare"
     And user "user1" has created a share with settings
       | path        | testshare |
@@ -189,7 +189,7 @@ Feature: move (rename) file
   Scenario Outline: enabling async operations does no difference to normal MOVE - Moving a file to a folder with no permissions
     Given the administrator has enabled async operations
     And using <dav_version> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user1" has created folder "/testshare"
     And user "user1" has created a share with settings
       | path        | testshare |
diff --git a/tests/acceptance/features/apiWebdavMove/moveFolder.feature b/tests/acceptance/features/apiWebdavMove/moveFolder.feature
index a2ed06ea7050..b899bee3b3a9 100644
--- a/tests/acceptance/features/apiWebdavMove/moveFolder.feature
+++ b/tests/acceptance/features/apiWebdavMove/moveFolder.feature
@@ -6,7 +6,7 @@ Feature: move (rename) folder
 
   Background:
     Given using OCS API version "1"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
 
   Scenario Outline: Renaming a folder to a backslash encoded should return an error
     Given using <dav_version> DAV path
diff --git a/tests/acceptance/features/apiWebdavOperations/deleteFile.feature b/tests/acceptance/features/apiWebdavOperations/deleteFile.feature
index 09de4237a682..428c498c9d76 100644
--- a/tests/acceptance/features/apiWebdavOperations/deleteFile.feature
+++ b/tests/acceptance/features/apiWebdavOperations/deleteFile.feature
@@ -6,7 +6,7 @@ Feature: delete file
 
   Background:
     Given using OCS API version "1"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
 
   @smokeTest
   Scenario Outline: delete a file
diff --git a/tests/acceptance/features/apiWebdavOperations/deleteFolder.feature b/tests/acceptance/features/apiWebdavOperations/deleteFolder.feature
index 928d105d6ad5..1dd971b6d958 100644
--- a/tests/acceptance/features/apiWebdavOperations/deleteFolder.feature
+++ b/tests/acceptance/features/apiWebdavOperations/deleteFolder.feature
@@ -6,7 +6,7 @@ Feature: delete folder
 
   Background:
     Given using OCS API version "1"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
 
   Scenario Outline: delete a folder
     Given using <dav_version> DAV path
diff --git a/tests/acceptance/features/apiWebdavOperations/deleteFolderContents.feature b/tests/acceptance/features/apiWebdavOperations/deleteFolderContents.feature
index b0a0b9792499..e6c4898db7cb 100644
--- a/tests/acceptance/features/apiWebdavOperations/deleteFolderContents.feature
+++ b/tests/acceptance/features/apiWebdavOperations/deleteFolderContents.feature
@@ -6,7 +6,7 @@ Feature: delete folder contents
 
   Background:
     Given using OCS API version "1"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
 
   Scenario Outline: Removing everything of a folder
     Given using <dav_version> DAV path
diff --git a/tests/acceptance/features/apiWebdavOperations/downloadFile.feature b/tests/acceptance/features/apiWebdavOperations/downloadFile.feature
index 0dc06a5fc8bd..af6ddc29b159 100644
--- a/tests/acceptance/features/apiWebdavOperations/downloadFile.feature
+++ b/tests/acceptance/features/apiWebdavOperations/downloadFile.feature
@@ -6,7 +6,7 @@ Feature: download file
 
   Background:
     Given using OCS API version "1"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
 
   @smokeTest
   Scenario Outline: download a file
diff --git a/tests/acceptance/features/apiWebdavOperations/refuseAccess.feature b/tests/acceptance/features/apiWebdavOperations/refuseAccess.feature
index 5b34480687d8..38f676805eea 100644
--- a/tests/acceptance/features/apiWebdavOperations/refuseAccess.feature
+++ b/tests/acceptance/features/apiWebdavOperations/refuseAccess.feature
@@ -22,7 +22,7 @@ Feature: refuse access
 
   Scenario Outline: A disabled user cannot use webdav
     Given using <dav_version> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user1" has been disabled
     When user "user1" downloads file "/welcome.txt" using the WebDAV API
     Then the HTTP status code should be "401"
diff --git a/tests/acceptance/features/apiWebdavOperations/search.feature b/tests/acceptance/features/apiWebdavOperations/search.feature
index 1e8ebe54ce13..fcae6258f205 100644
--- a/tests/acceptance/features/apiWebdavOperations/search.feature
+++ b/tests/acceptance/features/apiWebdavOperations/search.feature
@@ -5,7 +5,7 @@ Feature: Search
   So that I can find needed files quickly
 
   Background:
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And user "user0" has created folder "/just-a-folder"
     And user "user0" has created folder "/फनी näme"
     And user "user0" has created folder "/upload folder"
diff --git a/tests/acceptance/features/apiWebdavProperties/copyFile.feature b/tests/acceptance/features/apiWebdavProperties/copyFile.feature
index ea57b727e023..81bb63888548 100644
--- a/tests/acceptance/features/apiWebdavProperties/copyFile.feature
+++ b/tests/acceptance/features/apiWebdavProperties/copyFile.feature
@@ -6,7 +6,7 @@ Feature: copy file
 
   Background:
     Given using OCS API version "1"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
 
   @smokeTest
   Scenario Outline: Copying a file
@@ -44,7 +44,7 @@ Feature: copy file
 
   Scenario Outline: Copying a file to a folder with no permissions
     Given using <dav_version> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user1" has created folder "/testshare"
     And user "user1" has created a share with settings
       | path        | testshare |
@@ -62,7 +62,7 @@ Feature: copy file
 
   Scenario Outline: Copying a file to overwrite a file into a folder with no permissions
     Given using <dav_version> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user1" has created folder "/testshare"
     And user "user1" has created a share with settings
       | path        | testshare |
diff --git a/tests/acceptance/features/apiWebdavProperties/createFolder.feature b/tests/acceptance/features/apiWebdavProperties/createFolder.feature
index 51544debcc61..91c17a971b7e 100644
--- a/tests/acceptance/features/apiWebdavProperties/createFolder.feature
+++ b/tests/acceptance/features/apiWebdavProperties/createFolder.feature
@@ -6,7 +6,7 @@ Feature: create folder
 
   Background:
     Given using OCS API version "1"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
 
   Scenario Outline: create a folder
     Given using <dav_version> DAV path
diff --git a/tests/acceptance/features/apiWebdavProperties/getFileProperties.feature b/tests/acceptance/features/apiWebdavProperties/getFileProperties.feature
index 4fc8f76eb897..20e8283923f6 100644
--- a/tests/acceptance/features/apiWebdavProperties/getFileProperties.feature
+++ b/tests/acceptance/features/apiWebdavProperties/getFileProperties.feature
@@ -6,7 +6,7 @@ Feature: get file properties
 
   Background:
     Given using OCS API version "1"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
 
   @smokeTest
   Scenario Outline: Do a PROPFIND of various file names
@@ -71,7 +71,7 @@ Feature: get file properties
 
   Scenario Outline: A file that is shared to a user has a share-types property
     Given using <dav_version> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/test"
     And user "user0" has created a share with settings
       | path        | test  |
@@ -124,7 +124,7 @@ Feature: get file properties
   @skipOnLDAP @user_ldap-issue-268 @public_link_share-feature-required
   Scenario Outline: A file that is shared by user,group and link has a share-types property
     Given using <dav_version> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And group "grp2" has been created
     And user "user0" has created folder "/test"
     And user "user0" has created a share with settings
diff --git a/tests/acceptance/features/apiWebdavProperties/getQuota.feature b/tests/acceptance/features/apiWebdavProperties/getQuota.feature
index f9e7b52ea9f7..59220e541038 100644
--- a/tests/acceptance/features/apiWebdavProperties/getQuota.feature
+++ b/tests/acceptance/features/apiWebdavProperties/getQuota.feature
@@ -6,7 +6,7 @@ Feature: get quota
 
   Background:
     Given using OCS API version "1"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
 
   Scenario Outline: Retrieving folder quota when no quota is set
     Given using <dav_version> DAV path
@@ -29,7 +29,7 @@ Feature: get quota
 
   Scenario Outline: Retrieving folder quota of shared folder with quota when no quota is set for recipient
     Given using <dav_version> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has been given unlimited quota
     And the quota of user "user1" has been set to "10 MB"
     And user "user1" has created folder "/testquota"
@@ -60,7 +60,7 @@ Feature: get quota
 
   Scenario Outline: Retrieving folder quota when quota is set and a file was recieved
     Given using <dav_version> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And the quota of user "user1" has been set to "1 KB"
     And user "user0" has uploaded file "/user0.txt" of 93 bytes
     And user "user0" has shared file "user0.txt" with user "user1"
diff --git a/tests/acceptance/features/apiWebdavProperties/setFileProperties.feature b/tests/acceptance/features/apiWebdavProperties/setFileProperties.feature
index 3c13c2e5b5b4..2e6f17b42a2e 100644
--- a/tests/acceptance/features/apiWebdavProperties/setFileProperties.feature
+++ b/tests/acceptance/features/apiWebdavProperties/setFileProperties.feature
@@ -6,7 +6,7 @@ Feature: set file properties
 
   Background:
     Given using OCS API version "1"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
 
   @smokeTest
   Scenario Outline: Setting custom DAV property and reading it
@@ -47,7 +47,7 @@ Feature: set file properties
 
   Scenario Outline: Setting custom DAV property on a shared file as an owner and reading as a recipient
     Given using <dav_version> DAV path
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has uploaded file "filesForUpload/textfile.txt" to "/testcustompropshared.txt"
     And user "user0" has created a share with settings
       | path        | testcustompropshared.txt |
diff --git a/tests/acceptance/features/apiWebdavUpload/uploadFile.feature b/tests/acceptance/features/apiWebdavUpload/uploadFile.feature
index eeb57b9c5570..d60c8b8f943e 100644
--- a/tests/acceptance/features/apiWebdavUpload/uploadFile.feature
+++ b/tests/acceptance/features/apiWebdavUpload/uploadFile.feature
@@ -6,7 +6,7 @@ Feature: upload file
 
   Background:
     Given using OCS API version "1"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
 
   @smokeTest
   Scenario Outline: upload a file and check download content
diff --git a/tests/acceptance/features/apiWebdavUpload/uploadFileAsyncUsingNewChunking.feature b/tests/acceptance/features/apiWebdavUpload/uploadFileAsyncUsingNewChunking.feature
index 5decaaaca97c..ebee63d22f7b 100644
--- a/tests/acceptance/features/apiWebdavUpload/uploadFileAsyncUsingNewChunking.feature
+++ b/tests/acceptance/features/apiWebdavUpload/uploadFileAsyncUsingNewChunking.feature
@@ -6,7 +6,7 @@ Feature: upload file using new chunking
 
   Background:
     Given using new DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And the owncloud log level has been set to debug
     And the owncloud log has been cleared
     And the administrator has enabled async operations
diff --git a/tests/acceptance/features/apiWebdavUpload/uploadFileUsingNewChunking.feature b/tests/acceptance/features/apiWebdavUpload/uploadFileUsingNewChunking.feature
index 49403a96f5f0..6a371edf4617 100644
--- a/tests/acceptance/features/apiWebdavUpload/uploadFileUsingNewChunking.feature
+++ b/tests/acceptance/features/apiWebdavUpload/uploadFileUsingNewChunking.feature
@@ -7,7 +7,7 @@ Feature: upload file using new chunking
   Background:
     Given using OCS API version "1"
     And using new DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And the owncloud log level has been set to debug
     And the owncloud log has been cleared
 
diff --git a/tests/acceptance/features/apiWebdavUpload/uploadFileUsingOldChunking.feature b/tests/acceptance/features/apiWebdavUpload/uploadFileUsingOldChunking.feature
index f888baadeabc..6c25a549452c 100644
--- a/tests/acceptance/features/apiWebdavUpload/uploadFileUsingOldChunking.feature
+++ b/tests/acceptance/features/apiWebdavUpload/uploadFileUsingOldChunking.feature
@@ -7,7 +7,7 @@ Feature: upload file using old chunking
   Background:
     Given using OCS API version "1"
     And using old DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And the owncloud log level has been set to debug
     And the owncloud log has been cleared
 
diff --git a/tests/acceptance/features/bootstrap/Provisioning.php b/tests/acceptance/features/bootstrap/Provisioning.php
index 3ba11b843c2f..5b14d8c0e3c6 100644
--- a/tests/acceptance/features/bootstrap/Provisioning.php
+++ b/tests/acceptance/features/bootstrap/Provisioning.php
@@ -257,6 +257,7 @@ public function userHasBeenCreatedOnDatabaseBackend($user) {
 
 	/**
 	 * @Given /^user "([^"]*)" has been created with default attributes$/
+	 * @Given /^user "([^"]*)" has been created with default attributes and skeleton files$/
 	 *
 	 * @param string $user
 	 *
@@ -331,6 +332,7 @@ public function theseUsersHaveBeenCreatedWithoutSkeletonFiles(TableNode $table)
 
 	/**
 	 * @Given /^these users have been created\s?(with default attributes|)\s?(but not initialized|):$/
+	 * @Given /^these users have been created\s?(with default attributes and skeleton files|)\s?(but not initialized|):$/
 	 * expects a table of users with the heading
 	 * "|username|password|displayname|email|"
 	 * password, displayname & email are optional
diff --git a/tests/acceptance/features/cliBackground/backgroundQueue.feature b/tests/acceptance/features/cliBackground/backgroundQueue.feature
index 3ff3e87160b4..087f62bc0dd7 100644
--- a/tests/acceptance/features/cliBackground/backgroundQueue.feature
+++ b/tests/acceptance/features/cliBackground/backgroundQueue.feature
@@ -23,7 +23,7 @@ Feature: get status, delete and execute jobs in background queue
       | OC\Authentication\Token\DefaultTokenCleanupJob     |
 
   Scenario: delete one of the job in background queue
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And user "user0" has deleted file "/textfile0.txt"
     When the administrator deletes last background job "OC\Command\CommandJob" using the occ command
     Then the command should have been successful
diff --git a/tests/acceptance/features/cliMain/cliIncomingShares.feature b/tests/acceptance/features/cliMain/cliIncomingShares.feature
index 60823ead83c5..bf24f60f2a54 100644
--- a/tests/acceptance/features/cliMain/cliIncomingShares.feature
+++ b/tests/acceptance/features/cliMain/cliIncomingShares.feature
@@ -7,7 +7,7 @@ Feature: poll incoming shares
 
   Scenario: poll incoming share with a federation share of deep nested folders when there is a file change in remote end
     Given using server "REMOTE"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And user "user0" has created folder "/really/"
     And user "user0" has created folder "/really/very/"
     And user "user0" has created folder "/really/very/deeply/"
@@ -17,7 +17,7 @@ Feature: poll incoming shares
     And user "user0" has created folder "/really/very/deeply/nested/folder/with/sub/"
     And user "user0" has created folder "/really/very/deeply/nested/folder/with/sub/folders"
     And using server "LOCAL"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user1" has stored etag of element "/"
     And user "user0" from server "REMOTE" has shared "/really" with user "user1" from server "LOCAL"
     And user "user1" from server "LOCAL" has accepted the last pending share
@@ -29,10 +29,10 @@ Feature: poll incoming shares
 
   Scenario: poll incoming share with a federation share and no file change
     Given using server "REMOTE"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And user "user0" has created folder "/shareFolder/"
     And using server "LOCAL"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user1" has stored etag of element "/"
     And user "user0" from server "REMOTE" has shared "/shareFolder" with user "user1" from server "LOCAL"
     And user "user1" from server "LOCAL" has accepted the last pending share
@@ -43,11 +43,11 @@ Feature: poll incoming shares
 
   Scenario: poll incoming share multiple times
     Given using server "REMOTE"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And user "user0" has created folder "/shareFolder/"
     And using server "LOCAL"
     And user "user1" has stored etag of element "/"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" from server "REMOTE" has shared "/shareFolder" with user "user1" from server "LOCAL"
     And user "user1" from server "LOCAL" has accepted the last pending share
     And using server "LOCAL"
@@ -60,7 +60,7 @@ Feature: poll incoming shares
     Then the etag of element "/" of user "user1" should not have changed
 
   Scenario: poll incoming share when there is no share
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has stored etag of element "/"
     When the administrator invokes occ command "incoming-shares:poll"
     Then the etag of element "/" of user "user1" should not have changed
\ No newline at end of file
diff --git a/tests/acceptance/features/cliMain/files.feature b/tests/acceptance/features/cliMain/files.feature
index 173155fd9c2d..9c266a0e032c 100644
--- a/tests/acceptance/features/cliMain/files.feature
+++ b/tests/acceptance/features/cliMain/files.feature
@@ -3,7 +3,7 @@ Feature: Files Operations command
 
   Scenario: Adding a file to local storage and running scan should add files.
     Given using new DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And the administrator has set the external storage "local_storage" to be never scanned automatically
     # issue-33670: Need to re-scan. Config change doesn't come into effect until once scanned
     And the administrator has scanned the filesystem for all users
@@ -21,7 +21,7 @@ Feature: Files Operations command
 
   Scenario: Adding a file to local storage and running scan for a specific path should add files for only that path.
     Given using new DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And the administrator has set the external storage "local_storage" to be never scanned automatically
     And user "user0" has created folder "/local_storage/folder1"
     And user "user0" has created folder "/local_storage/folder2"
@@ -46,7 +46,7 @@ Feature: Files Operations command
 
   Scenario Outline: Adding a folder to local storage, sharing with groups and running scan for specific group should add files for users of that group
     Given using new DAV path
-    And these users have been created with default attributes:
+    And these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
       | user2    |
@@ -79,7 +79,7 @@ Feature: Files Operations command
 
   Scenario: Adding a folder to local storage, sharing with groups and running scan for a list of groups should add files for users in the groups
     Given using new DAV path
-    And these users have been created with default attributes:
+    And these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
       | user2    |
@@ -137,7 +137,7 @@ Feature: Files Operations command
 
   Scenario: administrator should be able to create a local mount for a specific user
     Given using new DAV path
-    And these users have been created with default attributes:
+    And these users have been created with default attributes and skeleton files:
       | username |
       | user0    |
       | user1    |
@@ -152,7 +152,7 @@ Feature: Files Operations command
 
   Scenario: Deleting a file from local storage and running scan for a specific path should remove the file.
     Given using new DAV path
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And user "user0" has uploaded file "filesForUpload/textfile.txt" to "/local_storage/hello1.txt"
     When user "user0" requests "/remote.php/dav/files/user0/local_storage" with "PROPFIND" using basic auth
     Then the propfind result should contain these entries:
@@ -168,7 +168,7 @@ Feature: Files Operations command
 
   Scenario: Adding a file on local storage and running file scan for a specific user should add file for only that user
     Given using new DAV path
-    And these users have been created with default attributes:
+    And these users have been created with default attributes and skeleton files:
       | username |
       | user0    |
       | user1    |
@@ -197,7 +197,7 @@ Feature: Files Operations command
 
   Scenario: Adding a file on local storage and running file scan for a specific group should add file for only the users of that group
     Given using new DAV path
-    And these users have been created with default attributes:
+    And these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
       | user2    |
@@ -238,7 +238,7 @@ Feature: Files Operations command
 
   Scenario: administrator should be able to add more than one user as the applicable user for a local mount
     Given using new DAV path
-    And these users have been created with default attributes:
+    And these users have been created with default attributes and skeleton files:
       | username |
       | user0    |
       | user1    |
@@ -252,7 +252,7 @@ Feature: Files Operations command
 
   Scenario: user should get access if the user is removed from the applicable user and the user was the only applicable user
     Given using new DAV path
-    And these users have been created with default attributes:
+    And these users have been created with default attributes and skeleton files:
       | username |
       | user0    |
       | user1    |
@@ -264,7 +264,7 @@ Feature: Files Operations command
 
   Scenario: user should not get access if the user is removed from the applicable user and the user was not the only applicable user
     Given using new DAV path
-    And these users have been created with default attributes:
+    And these users have been created with default attributes and skeleton files:
       | username |
       | user0    |
       | user1    |
@@ -277,7 +277,7 @@ Feature: Files Operations command
 
   Scenario: administrator should be able to create a local mount for a specific group
     Given using new DAV path
-    And these users have been created with default attributes:
+    And these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
       | user2    |
@@ -290,7 +290,7 @@ Feature: Files Operations command
 
   Scenario: administrator should be able to create a local mount for more than one group
     Given using new DAV path
-    And these users have been created with default attributes:
+    And these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
       | user2    |
@@ -308,7 +308,7 @@ Feature: Files Operations command
 
   Scenario: administrator should be able to create a local mount for a specific group and user
     Given using new DAV path
-    And these users have been created with default attributes:
+    And these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
       | user3    |
@@ -322,7 +322,7 @@ Feature: Files Operations command
 
   Scenario: removing group from applicable group of a local mount
     Given using new DAV path
-    And these users have been created with default attributes:
+    And these users have been created with default attributes and skeleton files:
       | username |
       | user0    |
       | user1    |
@@ -336,7 +336,7 @@ Feature: Files Operations command
 
   Scenario: user should get access if the group of the user is removed from the applicable group and that group was the only applicable group
     Given using new DAV path
-    And these users have been created with default attributes:
+    And these users have been created with default attributes and skeleton files:
       | username |
       | user0    |
       | user1    |
@@ -350,7 +350,7 @@ Feature: Files Operations command
 
   Scenario: user should not get access if the group of the user is removed from the applicable group and that group was not the only applicable group
     Given using new DAV path
-    And these users have been created with default attributes:
+    And these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
       | user3    |
diff --git a/tests/acceptance/features/cliMain/transfer-ownership.feature b/tests/acceptance/features/cliMain/transfer-ownership.feature
index e7a1c276be7d..0ae08e62825b 100644
--- a/tests/acceptance/features/cliMain/transfer-ownership.feature
+++ b/tests/acceptance/features/cliMain/transfer-ownership.feature
@@ -4,8 +4,8 @@ Feature: transfer-ownership
   @smokeTest
   @skipOnEncryptionType:user-keys
   Scenario: transferring ownership of a file
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has uploaded file "filesForUpload/textfile.txt" to "/somefile.txt"
     When the administrator transfers ownership from "user0" to "user1" using the occ command
     Then the command should have been successful
@@ -13,8 +13,8 @@ Feature: transfer-ownership
 
   @skipOnEncryptionType:user-keys
   Scenario: transferring ownership of a file after updating the file
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has uploaded file "filesForUpload/file_to_overwrite.txt" to "/PARENT/textfile0.txt"
     And user "user0" has uploaded the following "3" chunks to "/PARENT/textfile0.txt" with old chunking
       | 1 | AA |
@@ -26,8 +26,8 @@ Feature: transfer-ownership
 
   @skipOnEncryptionType:user-keys
   Scenario: transferring ownership of a folder
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/test"
     And user "user0" has uploaded file "filesForUpload/textfile.txt" to "/test/somefile.txt"
     When the administrator transfers ownership from "user0" to "user1" using the occ command
@@ -36,9 +36,9 @@ Feature: transfer-ownership
 
   @skipOnEncryptionType:user-keys
   Scenario: transferring ownership of file shares
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
     And user "user0" has uploaded file "filesForUpload/textfile.txt" to "/somefile.txt"
     And user "user0" has shared file "/somefile.txt" with user "user2" with permissions 19
     When the administrator transfers ownership from "user0" to "user1" using the occ command
@@ -47,9 +47,9 @@ Feature: transfer-ownership
 
   @skipOnEncryptionType:user-keys
   Scenario: transferring ownership of folder shared with third user
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
     And user "user0" has created folder "/test"
     And user "user0" has uploaded file "filesForUpload/textfile.txt" to "/test/somefile.txt"
     And user "user0" has shared folder "/test" with user "user2" with permissions 31
@@ -59,8 +59,8 @@ Feature: transfer-ownership
 
   @skipOnEncryptionType:user-keys
   Scenario: transferring ownership of folder shared with transfer recipient
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/test"
     And user "user0" has uploaded file "filesForUpload/textfile.txt" to "/test/somefile.txt"
     And user "user0" has shared folder "/test" with user "user1" with permissions 31
@@ -72,9 +72,9 @@ Feature: transfer-ownership
   @skipOnEncryptionType:user-keys
   Scenario: transferring ownership of folder doubly shared with third user
     Given group "group1" has been created
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
     And user "user2" has been added to group "group1"
     And user "user0" has created folder "/test"
     And user "user0" has uploaded file "filesForUpload/textfile.txt" to "/test/somefile.txt"
@@ -86,9 +86,9 @@ Feature: transfer-ownership
 
   @skipOnEncryptionType:user-keys
   Scenario: transferring ownership does not transfer received shares
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
     And user "user2" has created folder "/test"
     And user "user2" has shared folder "/test" with user "user0" with permissions 31
     When the administrator transfers ownership from "user0" to "user1" using the occ command
@@ -97,17 +97,17 @@ Feature: transfer-ownership
 
   @local_storage @skipOnEncryptionType:user-keys
   Scenario: transferring ownership does not transfer external storage
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     When the administrator transfers ownership from "user0" to "user1" using the occ command
     Then the command should have been successful
     And as "user1" folder "/local_storage" should not exist in the last received transfer folder
 
   @skipOnEncryptionType:user-keys
   Scenario: transferring ownership does not fail with shared trashed files
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
     And user "user0" has created folder "/sub"
     And user "user0" has created folder "/sub/test"
     And user "user0" has shared folder "/sub/test" with user "user2" with permissions 31
@@ -116,13 +116,13 @@ Feature: transfer-ownership
     Then the command should have been successful
 
   Scenario: transferring ownership fails with invalid source user
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     When the administrator transfers ownership from "invalid_user" to "user0" using the occ command
     Then the command output should contain the text "Unknown source user"
     And the command should have failed with exit code 1
 
   Scenario: transferring ownership fails with invalid destination user
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     When the administrator transfers ownership from "user0" to "invalid_user" using the occ command
     Then the command output should contain the text "Unknown destination user"
     And the command should have failed with exit code 1
@@ -130,8 +130,8 @@ Feature: transfer-ownership
   @smokeTest
   @skipOnEncryptionType:user-keys
   Scenario: transferring ownership of only a single folder containing a file
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/test"
     And user "user0" has uploaded file "filesForUpload/textfile.txt" to "/test/somefile.txt"
     When the administrator transfers ownership of path "test" from "user0" to "user1" using the occ command
@@ -139,8 +139,8 @@ Feature: transfer-ownership
     And the downloaded content when downloading file "/test/somefile.txt" for user "user1" with range "bytes=0-6" from the last received transfer folder should be "This is"
 
   Scenario: transferring ownership of only a single folder containing an empty folder
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/test"
     And user "user0" has created folder "/test/subfolder"
     When the administrator transfers ownership of path "test" from "user0" to "user1" using the occ command
@@ -149,8 +149,8 @@ Feature: transfer-ownership
     And as "user1" folder "/test/subfolder" should exist in the last received transfer folder
 
   Scenario: transferring ownership of an account containing only an empty folder
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has deleted everything from folder "/"
     And user "user0" has created folder "/test"
     When the administrator transfers ownership from "user0" to "user1" using the occ command
@@ -159,9 +159,9 @@ Feature: transfer-ownership
 
   @skipOnEncryptionType:user-keys
   Scenario: transferring ownership of file shares
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
     And user "user0" has created folder "/test"
     And user "user0" has uploaded file "filesForUpload/textfile.txt" to "/test/somefile.txt"
     And user "user0" has shared file "/test/somefile.txt" with user "user2" with permissions 19
@@ -171,9 +171,9 @@ Feature: transfer-ownership
 
   @skipOnEncryptionType:user-keys @public_link_share-feature-required
   Scenario: transferring ownership of folder shares which has public link
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
     And user "user0" has created folder "/test"
     And user "user0" has uploaded file "filesForUpload/textfile.txt" to "/test/somefile.txt"
     And user "user0" has shared folder "/test" with user "user2" with permissions 31
@@ -185,9 +185,9 @@ Feature: transfer-ownership
 
   @skipOnEncryptionType:user-keys
   Scenario: transferring ownership of folder shared with third user
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
     And user "user0" has created folder "/test"
     And user "user0" has uploaded file "filesForUpload/textfile.txt" to "/test/somefile.txt"
     And user "user0" has shared folder "/test" with user "user2" with permissions 31
@@ -197,8 +197,8 @@ Feature: transfer-ownership
 
   @skipOnEncryptionType:user-keys
   Scenario: transferring ownership of folder shared with transfer recipient
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/test"
     And user "user0" has uploaded file "filesForUpload/textfile.txt" to "/test/somefile.txt"
     And user "user0" has shared folder "/test" with user "user1" with permissions 31
@@ -210,9 +210,9 @@ Feature: transfer-ownership
   @skipOnEncryptionType:user-keys
   Scenario: transferring ownership of folder doubly shared with third user
     Given group "group1" has been created
-    And user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
     And user "user2" has been added to group "group1"
     And user "user0" has created folder "/test"
     And user "user0" has uploaded file "filesForUpload/textfile.txt" to "/test/somefile.txt"
@@ -223,9 +223,9 @@ Feature: transfer-ownership
     And the downloaded content when downloading file "/test/somefile.txt" for user "user2" with range "bytes=0-6" should be "This is"
 
   Scenario: transferring ownership does not transfer received shares
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
-    And user "user2" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and skeleton files
     And user "user2" has created folder "/test"
     And user "user0" has created folder "/sub"
     And user "user2" has shared folder "/test" with user "user0" with permissions 31
@@ -236,8 +236,8 @@ Feature: transfer-ownership
 
   @skipOnEncryptionType:user-keys @public_link_share-feature-required
   Scenario: transferring ownership of folder shared with transfer recipient and public link created of received share works
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/test"
     And user "user0" has created folder "/test/foo"
     And user "user0" has uploaded file "filesForUpload/textfile.txt" to "/test/somefile.txt"
@@ -252,37 +252,37 @@ Feature: transfer-ownership
 
   @local_storage
   Scenario: transferring ownership does not transfer external storage
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has created folder "/sub"
     When the administrator transfers ownership of path "sub" from "user0" to "user1" using the occ command
     Then the command should have been successful
     And as "user1" folder "/local_storage" should not exist in the last received transfer folder
 
   Scenario: transferring ownership fails with invalid source user
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And user "user0" has created folder "/sub"
     When the administrator transfers ownership of path "sub" from "invalid_user" to "user0" using the occ command
     Then the command output should contain the text "Unknown source user"
     And the command should have failed with exit code 1
 
   Scenario: transferring ownership fails with invalid destination user
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And user "user0" has created folder "/sub"
     When the administrator transfers ownership of path "sub" from "user0" to "invalid_user" using the occ command
     Then the command output should contain the text "Unknown destination user"
     And the command should have failed with exit code 1
 
   Scenario: transferring ownership fails with invalid path
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     When the administrator transfers ownership of path "test" from "user0" to "user1" using the occ command
     Then the command output should contain the text "Unknown path provided"
     And the command should have failed with exit code 1
 
   Scenario: transferring ownership fails with empty files
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has deleted everything from folder "/"
     When the administrator transfers ownership from "user0" to "user1" using the occ command
     Then the command output should contain the text "No files/folders to transfer"
diff --git a/tests/acceptance/features/cliProvisioning/addToGroup.feature b/tests/acceptance/features/cliProvisioning/addToGroup.feature
index bd3ddf5a8e12..f55d41e57849 100644
--- a/tests/acceptance/features/cliProvisioning/addToGroup.feature
+++ b/tests/acceptance/features/cliProvisioning/addToGroup.feature
@@ -6,7 +6,7 @@ Feature: add users to group
 
   @smokeTest
   Scenario Outline: adding a user to a group
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "<group_id>" has been created
     When the administrator adds user "brand-new-user" to group "<group_id>" using the occ command
     Then the command should have been successful
@@ -19,7 +19,7 @@ Feature: add users to group
       | नेपाली      | Unicode group name          |
 
   Scenario Outline: adding a user to 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
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "<group_id1>" has been created
     And group "<group_id2>" has been created
     And group "<group_id3>" has been created
@@ -36,7 +36,7 @@ Feature: add users to group
       | brand-new-user | NEW-GROUP | New-Group | new-group |
 
   Scenario: admin tries to add user to a group which does not exist
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "not-group" has been deleted
     When the administrator adds user "brand-new-user" to group "not-group" using the occ command
     Then the command should have failed with exit code 1
diff --git a/tests/acceptance/features/cliProvisioning/addUser.feature b/tests/acceptance/features/cliProvisioning/addUser.feature
index f84578a35fc1..5b64af2aa787 100644
--- a/tests/acceptance/features/cliProvisioning/addUser.feature
+++ b/tests/acceptance/features/cliProvisioning/addUser.feature
@@ -31,13 +31,13 @@ Feature: add a user using the using the occ command
       | email       | justauser@example.com |
 
   Scenario: admin tries to create an existing user
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     When the administrator tries to create a user "brand-new-user" using the occ command
     Then the command should have failed with exit code 1
     And the command output should contain the text 'The user "brand-new-user" already exists.'
 
   Scenario: admin tries to create an existing disabled user
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And user "brand-new-user" has been disabled
     When the administrator tries to create a user "brand-new-user" using the occ command
     Then the command should have failed with exit code 1
@@ -82,7 +82,7 @@ Feature: add a user using the using the occ command
     And the display name of user "brand-new-user" should be "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
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     When the administrator creates this user using the occ command:
       | username       |
       | Brand-New-User |
diff --git a/tests/acceptance/features/cliProvisioning/disableUser.feature b/tests/acceptance/features/cliProvisioning/disableUser.feature
index 5099bc955b5e..f016eb31619f 100644
--- a/tests/acceptance/features/cliProvisioning/disableUser.feature
+++ b/tests/acceptance/features/cliProvisioning/disableUser.feature
@@ -5,14 +5,14 @@ Feature: disable user
   So that I can remove access to files and resources for a user, without actually deleting the files and resources
 
   Scenario: admin disables an user
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     When the administrator disables user "user1" using the occ command
     Then the command should have been successful
     And the command output should contain the text 'The specified user is disabled'
     And user "user1" should be disabled
 
   Scenario: Admin can disable another admin user
-    Given user "another-admin" has been created with default attributes
+    Given user "another-admin" has been created with default attributes and skeleton files
     And user "another-admin" has been added to group "admin"
     When the administrator disables user "another-admin" using the occ command
     Then the command should have been successful
@@ -20,7 +20,7 @@ Feature: disable user
     And user "another-admin" should be disabled
 
   Scenario: Admin can disable subadmins in the same group
-    Given user "subadmin" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been added to group "new-group"
     And the administrator has been added to group "new-group"
diff --git a/tests/acceptance/features/cliProvisioning/editUser.feature b/tests/acceptance/features/cliProvisioning/editUser.feature
index 838e3daf5340..2f6e8a0aab6f 100644
--- a/tests/acceptance/features/cliProvisioning/editUser.feature
+++ b/tests/acceptance/features/cliProvisioning/editUser.feature
@@ -5,7 +5,7 @@ Feature: edit users
   So that I can keep the user information up-to-date
 
   Scenario: the administrator can edit a user email
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     When the administrator changes the email of user "brand-new-user" to "brand-new-user@example.com" using the occ command
     Then the command should have been successful
     And the command output should contain the text 'The email address of brand-new-user updated to brand-new-user@example.com'
@@ -14,7 +14,7 @@ Feature: edit users
       | email | brand-new-user@example.com |
 
   Scenario: the administrator can edit a user display name
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     When the administrator changes the display name of user "brand-new-user" to "A New User" using the occ command
     Then the command should have been successful
     And the command output should contain the text 'The displayname of brand-new-user updated to A New User'
@@ -24,7 +24,7 @@ Feature: edit users
 
   @issue-23603
   Scenario: the administrator can edit a user quota
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     When the administrator changes the quota of user "brand-new-user" to "12MB" using the occ command
     Then the command should have failed with exit code 1
     #Then the command should have been successful
diff --git a/tests/acceptance/features/cliProvisioning/enableUser.feature b/tests/acceptance/features/cliProvisioning/enableUser.feature
index d040c8f2352e..94afb8d4bd8a 100644
--- a/tests/acceptance/features/cliProvisioning/enableUser.feature
+++ b/tests/acceptance/features/cliProvisioning/enableUser.feature
@@ -5,7 +5,7 @@ Feature: enable user
   So that I can give a user access to their files and resources again if they are now authorized for that
 
   Scenario: admin enables an user
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has been disabled
     When administrator enables user "user1" using the occ command
     Then the command should have been successful
@@ -13,7 +13,7 @@ Feature: enable user
     And user "user1" should be enabled
 
   Scenario: admin enables another admin user
-    Given user "another-admin" has been created with default attributes
+    Given user "another-admin" has been created with default attributes and skeleton files
     And user "another-admin" has been added to group "admin"
     And user "another-admin" has been disabled
     When administrator enables user "another-admin" using the occ command
@@ -22,7 +22,7 @@ Feature: enable user
     And user "another-admin" should be enabled
 
   Scenario: admin enables subadmins in the same group
-    Given user "subadmin" has been created with default attributes
+    Given user "subadmin" has been created with default attributes and skeleton files
     And group "new-group" has been created
     And user "subadmin" has been added to group "new-group"
     And the administrator has been added to group "new-group"
diff --git a/tests/acceptance/features/cliProvisioning/getGroup.feature b/tests/acceptance/features/cliProvisioning/getGroup.feature
index f265d54bfdde..87c5cc41def8 100644
--- a/tests/acceptance/features/cliProvisioning/getGroup.feature
+++ b/tests/acceptance/features/cliProvisioning/getGroup.feature
@@ -21,7 +21,7 @@ Feature: get group
       | 123            | 123          |
 
   Scenario: admin gets user in the group who is disabled
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And the administrator has changed the display name of user "brand-new-user" to "Anne Brown"
     And user "brand-new-user" has been disabled
     And group "new-group" has been created
diff --git a/tests/acceptance/features/cliProvisioning/getUser.feature b/tests/acceptance/features/cliProvisioning/getUser.feature
index 2d206f22f6c9..a8df15f48e00 100644
--- a/tests/acceptance/features/cliProvisioning/getUser.feature
+++ b/tests/acceptance/features/cliProvisioning/getUser.feature
@@ -5,7 +5,7 @@ Feature: get user
   So that I can see the information
 
   Scenario: admin gets an existing user
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And the administrator has changed the display name of user "brand-new-user" to "Anne Brown"
     When the administrator retrieves the information of user "brand-new-user" in JSON format using the occ command
     Then the command should have been successful
diff --git a/tests/acceptance/features/cliProvisioning/getUserGroups.feature b/tests/acceptance/features/cliProvisioning/getUserGroups.feature
index 6c7799343e2d..6f4da6ff46ba 100644
--- a/tests/acceptance/features/cliProvisioning/getUserGroups.feature
+++ b/tests/acceptance/features/cliProvisioning/getUserGroups.feature
@@ -5,7 +5,7 @@ Feature: get user groups
   So that I can manage group membership
 
   Scenario: admin gets groups of an user
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "unused-group" has been created
     And group "new-group" has been created
     And group "0" has been created
@@ -28,7 +28,7 @@ Feature: get user groups
       | नेपाली               |
 
   Scenario: admin gets groups of an user who is not in any groups
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "unused-group" has been created
     When the administrator gets the groups of user "brand-new-user" in JSON format using the occ command
     Then the command should have been successful
diff --git a/tests/acceptance/features/cliProvisioning/removeFromGroup.feature b/tests/acceptance/features/cliProvisioning/removeFromGroup.feature
index 47d115273cac..049a23006679 100644
--- a/tests/acceptance/features/cliProvisioning/removeFromGroup.feature
+++ b/tests/acceptance/features/cliProvisioning/removeFromGroup.feature
@@ -5,7 +5,7 @@ Feature: remove a user from a group
   So that I can manage user access to group resources
 
   Scenario Outline: admin removes a user from a group
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "<group_id>" has been created
     And user "brand-new-user" has been added to group "<group_id>"
     When the administrator removes user "brand-new-user" from group "<group_id>" using the occ command
@@ -19,7 +19,7 @@ Feature: remove a user from a group
       | नेपाली      | Unicode group name          |
 
   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
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "<group_id1>" has been created
     And group "<group_id2>" has been created
     And group "<group_id3>" has been created
@@ -39,14 +39,14 @@ Feature: remove a user from a group
       | brand-new-user | NEW-GROUP | New-Group | new-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
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "not-group" has been deleted
     When the administrator removes user "brand-new-user" from group "not-group" using the occ command
     Then the command should have failed with exit code 1
     And the command output should contain the text 'Group "not-group" does not exist'
 
   Scenario: admin tries to remove a user from a group which the user is not a member of
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     And group "new-group" has been created
     When the administrator removes user "brand-new-user" from group "new-group" using the occ command
     Then the command should have been successful
diff --git a/tests/acceptance/features/cliProvisioning/resetUserPassword.feature b/tests/acceptance/features/cliProvisioning/resetUserPassword.feature
index 74383dd5ed44..b91a88a5f9cf 100644
--- a/tests/acceptance/features/cliProvisioning/resetUserPassword.feature
+++ b/tests/acceptance/features/cliProvisioning/resetUserPassword.feature
@@ -65,7 +65,7 @@ Feature: reset user password
     And the command output should contain the text 'User does not exist'
 
   Scenario: admin should be able to reset their own password
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username       | displayname    |
       | brand-new-user | Brand New User |
     When the administrator resets their own password to "%alt1%" using the occ command
diff --git a/tests/acceptance/features/cliProvisioning/userLastSeen.feature b/tests/acceptance/features/cliProvisioning/userLastSeen.feature
index f5ce04afe229..eb82b80c92f9 100644
--- a/tests/acceptance/features/cliProvisioning/userLastSeen.feature
+++ b/tests/acceptance/features/cliProvisioning/userLastSeen.feature
@@ -5,13 +5,13 @@ Feature: get user last seen
   So that I can see when the user has last logged in to the owncloud server
 
   Scenario: admin gets last seen of a user
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     When the administrator retrieves the time when user "brand-new-user" was last seen using the occ command
     Then the command should have been successful
     And the command output of user last seen should be recently
 
   Scenario: admin gets last seen of a user who has not been initialized
-    Given these users have been created with default attributes but not initialized:
+    Given these users have been created with default attributes and skeleton files but not initialized:
       | username       |
       | brand-new-user |
     When the administrator retrieves the time when user "brand-new-user" was last seen using the occ command
diff --git a/tests/acceptance/features/cliProvisioning/userReport.feature b/tests/acceptance/features/cliProvisioning/userReport.feature
index 7400564a5ba0..b8c5f3bfd0d7 100644
--- a/tests/acceptance/features/cliProvisioning/userReport.feature
+++ b/tests/acceptance/features/cliProvisioning/userReport.feature
@@ -5,7 +5,7 @@ Feature: get user report
   So that I can see the total number of users in an ownCloud server
 
   Scenario: admin gets the user report
-    Given these users have been created with default attributes but not initialized:
+    Given these users have been created with default attributes and skeleton files but not initialized:
       | username         |
       | brand-new-user-1 |
       | brand-new-user-2 |
@@ -14,7 +14,7 @@ Feature: get user report
     And the total users returned by the command should be 3
 
   Scenario: admin gets the user report when the user is disabled
-    Given these users have been created with default attributes but not initialized:
+    Given these users have been created with default attributes and skeleton files but not initialized:
       | username         |
       | brand-new-user-1 |
       | brand-new-user-2 |
@@ -24,7 +24,7 @@ Feature: get user report
     And the total users returned by the command should be 3
 
   Scenario: admin gets the user report when a user has been created and deleted
-    Given these users have been created with default attributes but not initialized:
+    Given these users have been created with default attributes and skeleton files but not initialized:
       | username         |
       | brand-new-user-1 |
       | brand-new-user-2 |
diff --git a/tests/acceptance/features/cliProvisioning/userSettings.feature b/tests/acceptance/features/cliProvisioning/userSettings.feature
index 316bdbeee5b5..00f23b21daef 100644
--- a/tests/acceptance/features/cliProvisioning/userSettings.feature
+++ b/tests/acceptance/features/cliProvisioning/userSettings.feature
@@ -5,7 +5,7 @@ Feature: user settings
   So that I can set specific settings for a specific user
 
   Scenario: admin changes user language
-    Given user "brand-new-user" has been created with default attributes
+    Given user "brand-new-user" has been created with default attributes and skeleton files
     When the administrator changes the language of user "brand-new-user" to "fr" using the occ command
     Then the command should have been successful
     And the language of user "brand-new-user" returned by the occ command should be "fr"
\ No newline at end of file
diff --git a/tests/acceptance/features/cliTrashbin/trashbin.feature b/tests/acceptance/features/cliTrashbin/trashbin.feature
index 77e7dc5322b0..446fdca25266 100644
--- a/tests/acceptance/features/cliTrashbin/trashbin.feature
+++ b/tests/acceptance/features/cliTrashbin/trashbin.feature
@@ -5,7 +5,7 @@ Feature: files and folders can be deleted from the trashbin
   So that I can control user trashbin space and which files are kept in that space
 
   Scenario: delete files and folder of a user from the trashbin
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And user "user0" has deleted file "/textfile0.txt"
     And user "user0" has deleted file "/textfile1.txt"
     And user "user0" has deleted folder "/PARENT"
@@ -17,8 +17,8 @@ Feature: files and folders can be deleted from the trashbin
     And as "user0" the folder with original path "/PARENT" should not exist in trash
 
   Scenario: delete files and folder of all user from the trashbin
-    Given user "user0" has been created with default attributes
-    And user "user1" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and skeleton files
     And user "user0" has deleted file "/textfile0.txt"
     And user "user1" has deleted file "/textfile1.txt"
     And user "user1" has deleted folder "/PARENT"
diff --git a/tests/acceptance/features/webUIAdminSettings/adminStorageSettings.feature b/tests/acceptance/features/webUIAdminSettings/adminStorageSettings.feature
index 709e36a3befa..0795c8cf0920 100644
--- a/tests/acceptance/features/webUIAdminSettings/adminStorageSettings.feature
+++ b/tests/acceptance/features/webUIAdminSettings/adminStorageSettings.feature
@@ -89,7 +89,7 @@ Feature: admin storage settings
     And folder "local_storage1" should be listed on the webUI
 
   Scenario: administrator deletes local storage mount
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And the administrator has browsed to the admin storage settings page
     And the administrator has enabled the external storage
     And the administrator has created the local storage mount "local_storage1" from the admin storage settings page
@@ -98,7 +98,7 @@ Feature: admin storage settings
     Then folder "local_storage1" should not be listed on the webUI
 
   Scenario: local storage mount is deleted when the last user applicable to it is deleted
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And the administrator has browsed to the admin storage settings page
     And the administrator has enabled the external storage
     And the administrator has created the local storage mount "local_storage1" from the admin storage settings page
@@ -108,7 +108,7 @@ Feature: admin storage settings
     Then the last created local storage mount should not be listed on the webUI
 
   Scenario: local storage mount is not deleted when the last group applicable to it is deleted but the member of the deleted group should not have access to it
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And group "newgroup" has been created
     And user "user0" has been added to group "newgroup"
     And the administrator has browsed to the admin storage settings page
diff --git a/tests/acceptance/features/webUIComments/comments.feature b/tests/acceptance/features/webUIComments/comments.feature
index edc9afde8645..53f5cc5d77c5 100644
--- a/tests/acceptance/features/webUIComments/comments.feature
+++ b/tests/acceptance/features/webUIComments/comments.feature
@@ -6,7 +6,7 @@ Feature: Add, delete and edit comments in files and folders
   So that I can provide more information about the file/folder
 
   Background:
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
       | user2    |
diff --git a/tests/acceptance/features/webUICreateDelete/deleteFilesFolders.feature b/tests/acceptance/features/webUICreateDelete/deleteFilesFolders.feature
index 02c52c1456ba..bcd49ca1202b 100644
--- a/tests/acceptance/features/webUICreateDelete/deleteFilesFolders.feature
+++ b/tests/acceptance/features/webUICreateDelete/deleteFilesFolders.feature
@@ -5,7 +5,7 @@ Feature: deleting files and folders
   So that I can keep my filing system clean and tidy
 
   Background:
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
     And user "user1" has logged in using the webUI
diff --git a/tests/acceptance/features/webUIFavorites/favoritesFile.feature b/tests/acceptance/features/webUIFavorites/favoritesFile.feature
index ddbc77a67a2a..dcfbd85f7c43 100644
--- a/tests/acceptance/features/webUIFavorites/favoritesFile.feature
+++ b/tests/acceptance/features/webUIFavorites/favoritesFile.feature
@@ -6,7 +6,7 @@ Feature: Mark file as favorite
   So that I can find my favorite file/folder easily
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the files page
 
diff --git a/tests/acceptance/features/webUIFavorites/unfavoriteFile.feature b/tests/acceptance/features/webUIFavorites/unfavoriteFile.feature
index a06706c981b9..4b6adc33e2b2 100644
--- a/tests/acceptance/features/webUIFavorites/unfavoriteFile.feature
+++ b/tests/acceptance/features/webUIFavorites/unfavoriteFile.feature
@@ -6,7 +6,7 @@ Feature: Unmark file/folder as favorite
   So that I can remove my favorite file/folder from favorite page
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the files page
 
diff --git a/tests/acceptance/features/webUIFiles/browseDirectlyToDetailsTab.feature b/tests/acceptance/features/webUIFiles/browseDirectlyToDetailsTab.feature
index 2a44593c1142..3d92dd8cba7b 100644
--- a/tests/acceptance/features/webUIFiles/browseDirectlyToDetailsTab.feature
+++ b/tests/acceptance/features/webUIFiles/browseDirectlyToDetailsTab.feature
@@ -5,7 +5,7 @@ Feature: browse directly to details tab
   So that I can see the details immediately without needing to click in the UI
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
 
   @smokeTest
diff --git a/tests/acceptance/features/webUIFiles/fileDetails.feature b/tests/acceptance/features/webUIFiles/fileDetails.feature
index 00a38d72d804..d6a48cdfafbd 100644
--- a/tests/acceptance/features/webUIFiles/fileDetails.feature
+++ b/tests/acceptance/features/webUIFiles/fileDetails.feature
@@ -5,7 +5,7 @@ Feature: User can open the details panel for any file or folder
   So that the details of the file or folder are visible to me
 
   Background:
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
     And user "user1" has logged in using the webUI
@@ -55,7 +55,7 @@ Feature: User can open the details panel for any file or folder
 
   @comments-app-required
   Scenario: user shares a file and then the details dialog should work in a Shared with others page
-    Given user "user2" has been created with default attributes
+    Given user "user2" has been created with default attributes and skeleton files
     And the user has shared folder "simple-folder" with user "User Two" using the webUI
     When the user browses to the shared-with-others page
     Then folder "simple-folder" should be listed on the webUI
@@ -70,7 +70,7 @@ Feature: User can open the details panel for any file or folder
 
   @comments-app-required
   Scenario: the recipient user should be able to view different areas of details panel in Shared with you page
-    Given user "user2" has been created with default attributes
+    Given user "user2" has been created with default attributes and skeleton files
     And the user has shared folder "simple-folder" with user "User Two" using the webUI
     And the user re-logs in as "user2" using the webUI
     When the user browses to the shared-with-you page
diff --git a/tests/acceptance/features/webUIFiles/hiddenFile.feature b/tests/acceptance/features/webUIFiles/hiddenFile.feature
index 98b7a73eac76..fe42e0cbd90f 100644
--- a/tests/acceptance/features/webUIFiles/hiddenFile.feature
+++ b/tests/acceptance/features/webUIFiles/hiddenFile.feature
@@ -6,7 +6,7 @@ Feature: Hide file/folders
   So that I can choose to see the files that I want.
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the files page
 
diff --git a/tests/acceptance/features/webUIFiles/scrollMenuIntoView.feature b/tests/acceptance/features/webUIFiles/scrollMenuIntoView.feature
index 3ac8293c3299..d95fc7cbe494 100644
--- a/tests/acceptance/features/webUIFiles/scrollMenuIntoView.feature
+++ b/tests/acceptance/features/webUIFiles/scrollMenuIntoView.feature
@@ -5,7 +5,7 @@ Feature: scroll menu of actions that can be done on a file into view
   So that I can manage and work with my files
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the files page
 
diff --git a/tests/acceptance/features/webUIFiles/search.feature b/tests/acceptance/features/webUIFiles/search.feature
index b44a972d0657..cfe90c72a76b 100644
--- a/tests/acceptance/features/webUIFiles/search.feature
+++ b/tests/acceptance/features/webUIFiles/search.feature
@@ -6,7 +6,7 @@ Feature: Search
   So that I can find needed files quickly
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the files page
 
@@ -77,15 +77,15 @@ Feature: Search
     And file "lorem.txt" with path "/simple-folder" should be listed in the tags page on the webUI
 
   Scenario: Search for a shared file
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     When user "user0" shares file "/lorem.txt" with user "user1" using the sharing API
     And the user reloads the current page of the webUI
     And the user searches for "lorem" using the webUI
     Then file "lorem (2).txt" should be listed on the webUI
 
   Scenario: Search for a re-shared file
-    Given user "user2" has been created with default attributes
-    And user "user0" has been created with default attributes
+    Given user "user2" has been created with default attributes and skeleton files
+    And user "user0" has been created with default attributes and skeleton files
     When user "user2" shares file "/lorem.txt" with user "user0" using the sharing API
     And user "user0" shares file "/lorem (2).txt" with user "user1" using the sharing API
     And the user reloads the current page of the webUI
@@ -93,7 +93,7 @@ Feature: Search
     Then file "lorem (2).txt" should be listed on the webUI
 
   Scenario: Search for a shared folder
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     When user "user0" shares folder "simple-folder" with user "user1" using the sharing API
     And the user reloads the current page of the webUI
     And the user searches for "simple" using the webUI
diff --git a/tests/acceptance/features/webUIFiles/versions.feature b/tests/acceptance/features/webUIFiles/versions.feature
index 55aa77644bf0..5120f7829623 100644
--- a/tests/acceptance/features/webUIFiles/versions.feature
+++ b/tests/acceptance/features/webUIFiles/versions.feature
@@ -7,7 +7,7 @@ Feature: Versions of a file
   So that I can have more control over the files
 
   Background:
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username |
       | user0    |
 
@@ -31,7 +31,7 @@ Feature: Versions of a file
     Then the content of file "lorem-file.txt" for user "user0" should be "lorem content"
 
   Scenario: sharee can see the versions of a file
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user0" has uploaded file with content "lorem content" to "/lorem-file.txt"
     And user "user0" has uploaded file with content "lorem" to "/lorem-file.txt"
     And user "user0" has uploaded file with content "new lorem content" to "/lorem-file.txt"
@@ -55,7 +55,7 @@ Feature: Versions of a file
 
   @skipOnStorage:ceph @files_primary_s3-issue-155
   Scenario: file versions cannot be seen on the webUI only for user whose versions is deleted
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user0" has uploaded file with content "lorem content" to "/lorem-file.txt"
     And user "user0" has uploaded file with content "lorem" to "/lorem-file.txt"
     And user "user1" has uploaded file with content "lorem content" to "/lorem-file.txt"
@@ -73,7 +73,7 @@ Feature: Versions of a file
 
   @skipOnStorage:ceph @files_primary_s3-issue-155
   Scenario: file versions cannot be seen on the webUI for all users after deleting versions for all users
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user0" has uploaded file with content "lorem content" to "/lorem-file.txt"
     And user "user0" has uploaded file with content "lorem" to "/lorem-file.txt"
     And user "user1" has uploaded file with content "lorem content" to "/lorem-file.txt"
diff --git a/tests/acceptance/features/webUILogin/login.feature b/tests/acceptance/features/webUILogin/login.feature
index 08c4dc6a8781..95f31f8d150f 100644
--- a/tests/acceptance/features/webUILogin/login.feature
+++ b/tests/acceptance/features/webUILogin/login.feature
@@ -10,7 +10,7 @@ Feature: login users
 
   @TestAlsoOnExternalUserBackend
   Scenario: simple user login
-    Given these users have been created with default attributes but not initialized:
+    Given these users have been created with default attributes and skeleton files but not initialized:
       | username |
       | user1    |
     When user "user1" logs in using the webUI
diff --git a/tests/acceptance/features/webUILogin/resetPassword.feature b/tests/acceptance/features/webUILogin/resetPassword.feature
index 0ae0001d55b8..f93fb6a6799b 100644
--- a/tests/acceptance/features/webUILogin/resetPassword.feature
+++ b/tests/acceptance/features/webUILogin/resetPassword.feature
@@ -5,7 +5,7 @@ Feature: reset the password
   So that I can login to my account again after forgetting the password
 
   Background:
-    Given these users have been created with default attributes but not initialized:
+    Given these users have been created with default attributes and skeleton files but not initialized:
       | username |
       | user1    |
     And the user has browsed to the login page
diff --git a/tests/acceptance/features/webUILogin/resetPasswordUsingEmail.feature b/tests/acceptance/features/webUILogin/resetPasswordUsingEmail.feature
index 98d8e1e781d3..6a1814685255 100644
--- a/tests/acceptance/features/webUILogin/resetPasswordUsingEmail.feature
+++ b/tests/acceptance/features/webUILogin/resetPasswordUsingEmail.feature
@@ -5,7 +5,7 @@ Feature: reset the password using an email address
   So that I can login to my account again after forgetting the password
 
   Background:
-    Given these users have been created with default attributes but not initialized:
+    Given these users have been created with default attributes and skeleton files but not initialized:
       | username |
       | user1    |
     And the user has browsed to the login page
diff --git a/tests/acceptance/features/webUIMoveFilesFolders/moveFiles.feature b/tests/acceptance/features/webUIMoveFilesFolders/moveFiles.feature
index 11e4d70d881a..0daad9ea3e7b 100644
--- a/tests/acceptance/features/webUIMoveFilesFolders/moveFiles.feature
+++ b/tests/acceptance/features/webUIMoveFilesFolders/moveFiles.feature
@@ -5,7 +5,7 @@ Feature: move files
   So that I can organise my data structure
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the files page
 
diff --git a/tests/acceptance/features/webUIMoveFilesFolders/moveFolders.feature b/tests/acceptance/features/webUIMoveFilesFolders/moveFolders.feature
index 51dac1ffa180..a226ceab6da9 100644
--- a/tests/acceptance/features/webUIMoveFilesFolders/moveFolders.feature
+++ b/tests/acceptance/features/webUIMoveFilesFolders/moveFolders.feature
@@ -5,7 +5,7 @@ Feature: move folders
   So that I can organise my data structure
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the files page
 
diff --git a/tests/acceptance/features/webUIPersonalSettings/accessToChangeFullNameThroughConfig.feature b/tests/acceptance/features/webUIPersonalSettings/accessToChangeFullNameThroughConfig.feature
index 4b0fffa502d6..97f853a25941 100644
--- a/tests/acceptance/features/webUIPersonalSettings/accessToChangeFullNameThroughConfig.feature
+++ b/tests/acceptance/features/webUIPersonalSettings/accessToChangeFullNameThroughConfig.feature
@@ -5,7 +5,7 @@ Feature: Control access to edit fullname of user through config file
   So that users can edit their fullname after getting permission from administrator
 
   Scenario: Admin gives access to users to change their full name
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
     When the administrator updates system config key "allow_user_to_change_display_name" with value "true" and type "boolean" using the occ command
     And the user browses to the personal general settings page
@@ -16,7 +16,7 @@ Feature: Control access to edit fullname of user through config file
       | displayname | my#very&weird?नेपालि%name |
 
   Scenario: Admin doesnot give access to users to change their full name
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
     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 user browses to the personal general settings page
diff --git a/tests/acceptance/features/webUIPersonalSettings/changeOwnEmailAddress.feature b/tests/acceptance/features/webUIPersonalSettings/changeOwnEmailAddress.feature
index fe2251b58651..08fafc260f07 100644
--- a/tests/acceptance/features/webUIPersonalSettings/changeOwnEmailAddress.feature
+++ b/tests/acceptance/features/webUIPersonalSettings/changeOwnEmailAddress.feature
@@ -5,7 +5,7 @@ Feature: Change own email address on the personal settings page
   So that I can be reached by the owncloud server
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the personal general settings page
 
diff --git a/tests/acceptance/features/webUIPersonalSettings/changeOwnFullName.feature b/tests/acceptance/features/webUIPersonalSettings/changeOwnFullName.feature
index f0b433da7246..1d0a958910a7 100644
--- a/tests/acceptance/features/webUIPersonalSettings/changeOwnFullName.feature
+++ b/tests/acceptance/features/webUIPersonalSettings/changeOwnFullName.feature
@@ -5,7 +5,7 @@ Feature: Change own full name on the personal settings page
   So that other users can recognize me by it
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the personal general settings page
 
diff --git a/tests/acceptance/features/webUIPersonalSettings/changePasswordFromSetting.feature b/tests/acceptance/features/webUIPersonalSettings/changePasswordFromSetting.feature
index 89841d7115de..26ceca9f4785 100644
--- a/tests/acceptance/features/webUIPersonalSettings/changePasswordFromSetting.feature
+++ b/tests/acceptance/features/webUIPersonalSettings/changePasswordFromSetting.feature
@@ -5,7 +5,7 @@ Feature: Change Login Password
   So that I can login with my new password
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the personal general settings page
 
diff --git a/tests/acceptance/features/webUIPersonalSettings/personalGeneralSettings.feature b/tests/acceptance/features/webUIPersonalSettings/personalGeneralSettings.feature
index 7c8b99e21137..e3a45922b1af 100644
--- a/tests/acceptance/features/webUIPersonalSettings/personalGeneralSettings.feature
+++ b/tests/acceptance/features/webUIPersonalSettings/personalGeneralSettings.feature
@@ -5,7 +5,7 @@ Feature: personal general settings
   So that I can personalise the User Interface
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the personal general settings page
 
diff --git a/tests/acceptance/features/webUIPersonalSettings/personalSecuritySettings.feature b/tests/acceptance/features/webUIPersonalSettings/personalSecuritySettings.feature
index 82c6ea933db8..f0f163536f35 100644
--- a/tests/acceptance/features/webUIPersonalSettings/personalSecuritySettings.feature
+++ b/tests/acceptance/features/webUIPersonalSettings/personalSecuritySettings.feature
@@ -5,7 +5,7 @@ Feature: personal security settings
   So that I can enable, allow and deny access to and from other storage systems or resources
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the personal security settings page
 
diff --git a/tests/acceptance/features/webUIRenameFiles/renameFiles.feature b/tests/acceptance/features/webUIRenameFiles/renameFiles.feature
index 80da702205be..293497ee90c8 100644
--- a/tests/acceptance/features/webUIRenameFiles/renameFiles.feature
+++ b/tests/acceptance/features/webUIRenameFiles/renameFiles.feature
@@ -5,7 +5,7 @@ Feature: rename files
   So that I can organise my data structure
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the files page
 
diff --git a/tests/acceptance/features/webUIRenameFiles/renameFilesInsideProblematicFolderName.feature b/tests/acceptance/features/webUIRenameFiles/renameFilesInsideProblematicFolderName.feature
index da9bc783913f..a2929b6edd2b 100644
--- a/tests/acceptance/features/webUIRenameFiles/renameFilesInsideProblematicFolderName.feature
+++ b/tests/acceptance/features/webUIRenameFiles/renameFilesInsideProblematicFolderName.feature
@@ -5,7 +5,7 @@ Feature: Renaming files inside a folder with problematic name
   So that I can recognize my file easily
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
 
   Scenario Outline: Rename the existing file inside a problematic folder
diff --git a/tests/acceptance/features/webUIRenameFolders/renameFolders.feature b/tests/acceptance/features/webUIRenameFolders/renameFolders.feature
index 64d83cf5e92d..fde71f0d8afe 100644
--- a/tests/acceptance/features/webUIRenameFolders/renameFolders.feature
+++ b/tests/acceptance/features/webUIRenameFolders/renameFolders.feature
@@ -5,7 +5,7 @@ Feature: rename folders
   So that I can organise my data structure
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the files page
 
diff --git a/tests/acceptance/features/webUIRestrictSharing/disableSharing.feature b/tests/acceptance/features/webUIRestrictSharing/disableSharing.feature
index d12d1890784c..74148b605049 100644
--- a/tests/acceptance/features/webUIRestrictSharing/disableSharing.feature
+++ b/tests/acceptance/features/webUIRestrictSharing/disableSharing.feature
@@ -5,7 +5,7 @@ Feature: disable sharing
   So that users cannot share files
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
 
   @TestAlsoOnExternalUserBackend
   @smokeTest
diff --git a/tests/acceptance/features/webUIRestrictSharing/restrictReSharing.feature b/tests/acceptance/features/webUIRestrictSharing/restrictReSharing.feature
index 040c60f8630d..b938a687f626 100644
--- a/tests/acceptance/features/webUIRestrictSharing/restrictReSharing.feature
+++ b/tests/acceptance/features/webUIRestrictSharing/restrictReSharing.feature
@@ -6,7 +6,7 @@ Feature: restrict resharing
   I want to be able to forbid a user that received a share from me to share it further
 
   Background:
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
       | user2    |
diff --git a/tests/acceptance/features/webUIRestrictSharing/restrictSharing.feature b/tests/acceptance/features/webUIRestrictSharing/restrictSharing.feature
index f566c7140324..271ecf63a7ba 100644
--- a/tests/acceptance/features/webUIRestrictSharing/restrictSharing.feature
+++ b/tests/acceptance/features/webUIRestrictSharing/restrictSharing.feature
@@ -5,7 +5,7 @@ Feature: restrict Sharing
   So that users can only share files with specific users and groups
 
   Background:
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
       | user2    |
diff --git a/tests/acceptance/features/webUISharingAcceptShares/acceptShares.feature b/tests/acceptance/features/webUISharingAcceptShares/acceptShares.feature
index bad08fd14a37..a683b40d35dd 100644
--- a/tests/acceptance/features/webUISharingAcceptShares/acceptShares.feature
+++ b/tests/acceptance/features/webUISharingAcceptShares/acceptShares.feature
@@ -6,7 +6,7 @@ Feature: accept/decline shares coming from internal users
 
   Background:
     Given user "user1" has been created with default attributes and without skeleton files
-    Given user "user2" has been created with default attributes
+    Given user "user2" has been created with default attributes and skeleton files
     And these groups have been created:
       | groupname |
       | grp1      |
@@ -45,7 +45,7 @@ Feature: accept/decline shares coming from internal users
 
   Scenario: receive shares with same name from different users
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been disabled
-    And user "user3" has been created with default attributes
+    And user "user3" has been created with default attributes and skeleton files
     And user "user2" has shared folder "/simple-folder" with user "user1"
     And user "user3" has shared folder "/simple-folder" with user "user1"
     When user "user1" logs in using the webUI
diff --git a/tests/acceptance/features/webUISharingAutocompletion/shareAutocompletion.feature b/tests/acceptance/features/webUISharingAutocompletion/shareAutocompletion.feature
index 6b732727a72a..208f8319f2c2 100644
--- a/tests/acceptance/features/webUISharingAutocompletion/shareAutocompletion.feature
+++ b/tests/acceptance/features/webUISharingAutocompletion/shareAutocompletion.feature
@@ -6,7 +6,7 @@ Feature: Autocompletion of share-with names
 
   Background:
     # Users that are in the special known users already
-    Given these users have been created with default attributes but not initialized:
+    Given these users have been created with default attributes and skeleton files but not initialized:
       | username    |
       | user1       |
       | regularuser |
@@ -182,7 +182,7 @@ Feature: Autocompletion of share-with names
 
   @skipOnLDAP
   Scenario: autocompletion of a pattern where the username of existing user contains the pattern somewhere in the middle
-    Given user "ivan" has been created with default attributes
+    Given user "ivan" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the files page
     And the user has opened the share dialog for folder "simple-folder"
@@ -200,7 +200,7 @@ Feature: Autocompletion of share-with names
 
   @skipOnLDAP
   Scenario: autocompletion of a pattern where the username of the existing user contains the pattern somewhere in the end
-    Given these users have been created with default attributes but not initialized:
+    Given these users have been created with default attributes and skeleton files but not initialized:
       | username     | displayname   |
       | regularuser3 | Guest User |
     And user "user1" has logged in using the webUI
@@ -291,7 +291,7 @@ Feature: Autocompletion of share-with names
 
   @skipOnLDAP
   Scenario: autocompletion of a pattern where the user name contains the pattern somewhere in the middle but accounts medial search is disabled
-    Given these users have been created with default attributes but not initialized:
+    Given these users have been created with default attributes and skeleton files but not initialized:
       | username | displayname |
       | ivan     | Ivan         |
     And user "user1" has logged in using the webUI
@@ -303,7 +303,7 @@ Feature: Autocompletion of share-with names
 
   @skipOnLDAP
   Scenario: autocompletion of a pattern where the user name contains the pattern somewhere in the end but accounts medial search is disabled
-    Given these users have been created with default attributes but not initialized:
+    Given these users have been created with default attributes and skeleton files but not initialized:
       | username     | displayname   |
       | regularuser3 | Guest User |
     And user "user1" has logged in using the webUI
@@ -315,7 +315,7 @@ Feature: Autocompletion of share-with names
 
   @skipOnLDAP
   Scenario: autocompletion of a pattern where the name of existing user contains the pattern somewhere in the middle but accounts medial search is disabled
-    Given these users have been created with default attributes but not initialized:
+    Given these users have been created with default attributes and skeleton files but not initialized:
       | username | displayname   |
       | user2    | finnance typo |
     And user "user1" has logged in using the webUI
@@ -327,7 +327,7 @@ Feature: Autocompletion of share-with names
 
   @skipOnLDAP
   Scenario: autocompletion of a pattern where the display name of existing user contains the pattern somewhere in the end but accounts medial search is disabled
-    Given these users have been created with default attributes but not initialized:
+    Given these users have been created with default attributes and skeleton files but not initialized:
       | username | displayname   |
       | user2    | Group User |
     And user "user1" has logged in using the webUI
@@ -339,7 +339,7 @@ Feature: Autocompletion of share-with names
 
   @skipOnLDAP
   Scenario: autocompletion of a pattern where the email of the existing user contains the pattern somewhere at the beginning but accounts medial search is disabled
-    Given these users have been created with default attributes but not initialized:
+    Given these users have been created with default attributes and skeleton files but not initialized:
       | username | displayname | email              |
       | user2    | User2       | hello2u2@oc.com.np |
     And user "user1" has logged in using the webUI
@@ -351,7 +351,7 @@ Feature: Autocompletion of share-with names
 
   @skipOnLDAP
   Scenario: autocompletion of a pattern where the email of the existing user contains the pattern somewhere at the middle but accounts medial search is disabled
-    Given these users have been created with default attributes but not initialized:
+    Given these users have been created with default attributes and skeleton files but not initialized:
       | username | displayname | email              |
       | user2    | User2       | net@oc.com.np |
     And user "user1" has logged in using the webUI
@@ -363,7 +363,7 @@ Feature: Autocompletion of share-with names
 
   @skipOnLDAP
   Scenario: autocompletion of a pattern where the email of the existing user contains the pattern somewhere at the end but accounts medial search is disabled
-    Given these users have been created with default attributes but not initialized:
+    Given these users have been created with default attributes and skeleton files but not initialized:
       | username | displayname | email        |
       | user2    | User2       | de@oc.com.np |
     And user "user1" has logged in using the webUI
diff --git a/tests/acceptance/features/webUISharingExternal/federationSharing.feature b/tests/acceptance/features/webUISharingExternal/federationSharing.feature
index 999a137c3f28..5c1a54afa26e 100644
--- a/tests/acceptance/features/webUISharingExternal/federationSharing.feature
+++ b/tests/acceptance/features/webUISharingExternal/federationSharing.feature
@@ -6,9 +6,9 @@ Feature: Federation Sharing - sharing with users on other cloud storages
 
   Background:
     Given using server "REMOTE"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And using server "LOCAL"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
     And parameter "auto_accept_trusted" of app "federatedfilesharing" has been set to "no"
 
@@ -24,7 +24,7 @@ Feature: Federation Sharing - sharing with users on other cloud storages
 
   Scenario: test the single steps of receiving a federation share
     Given using server "REMOTE"
-    And these users have been created with default attributes:
+    And these users have been created with default attributes and skeleton files:
       | username |
       | user2    |
       | user3    |
@@ -79,7 +79,7 @@ Feature: Federation Sharing - sharing with users on other cloud storages
       | /lorem%20(2).txt |
 
   Scenario: one user disabling user-based auto accepting while global is enabled has no effect on other users
-    Given user "user2" has been created with default attributes
+    Given user "user2" has been created with default attributes and skeleton files
     And parameter "autoAddServers" of app "federation" has been set to "1"
     And user "user1" from server "REMOTE" has shared "simple-folder" with user "user1" from server "LOCAL"
     And user "user1" from server "LOCAL" has accepted the last pending share
@@ -217,7 +217,7 @@ Feature: Federation Sharing - sharing with users on other cloud storages
 
   Scenario: receive same name federation share from two users
     Given using server "REMOTE"
-    And user "user2" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
     And user "user1" from server "REMOTE" has shared "/lorem.txt" with user "user1" from server "LOCAL"
     And user "user2" from server "REMOTE" has shared "/lorem.txt" with user "user1" from server "LOCAL"
     And the user has reloaded the current page of the webUI
diff --git a/tests/acceptance/features/webUISharingInternalGroups/shareWithGroups.feature b/tests/acceptance/features/webUISharingInternalGroups/shareWithGroups.feature
index 4374f76c042a..052fca801fc0 100644
--- a/tests/acceptance/features/webUISharingInternalGroups/shareWithGroups.feature
+++ b/tests/acceptance/features/webUISharingInternalGroups/shareWithGroups.feature
@@ -9,7 +9,7 @@ Feature: Sharing files and folders with internal groups
       | username |
       | user1    |
       | user2    |
-    And user "user3" has been created with default attributes
+    And user "user3" has been created with default attributes and skeleton files
     And these groups have been created:
       | groupname |
       | grp1      |
@@ -171,7 +171,7 @@ Feature: Sharing files and folders with internal groups
   @mailhog
   Scenario: user should not get an email notification if the user is added to the group after the mail notification was sent
     Given parameter "shareapi_allow_mail_notification" of app "core" has been set to "yes"
-    And user "user0" has been created with default attributes
+    And user "user0" has been created with default attributes and skeleton files
     And user "user3" has logged in using the webUI
     And user "user3" has shared file "lorem.txt" with group "grp1"
     And the user has opened the share dialog for file "lorem.txt"
diff --git a/tests/acceptance/features/webUISharingInternalGroups/shareWithGroupsEdgeCases.feature b/tests/acceptance/features/webUISharingInternalGroups/shareWithGroupsEdgeCases.feature
index 5223ce661beb..c6db86171c99 100644
--- a/tests/acceptance/features/webUISharingInternalGroups/shareWithGroupsEdgeCases.feature
+++ b/tests/acceptance/features/webUISharingInternalGroups/shareWithGroupsEdgeCases.feature
@@ -9,7 +9,7 @@ Feature: Sharing files and folders with internal groups
       | username |
       | user1    |
       | user2    |
-    And user "user3" has been created with default attributes
+    And user "user3" has been created with default attributes and skeleton files
     And these groups have been created:
       | groupname |
       | <group>   |
diff --git a/tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature b/tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature
index b138ca0e61dc..42abacc7e5b6 100644
--- a/tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature
+++ b/tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature
@@ -8,7 +8,7 @@ Feature: Sharing files and folders with internal users
   @TestAlsoOnExternalUserBackend
   @smokeTest
   Scenario: share a file & folder with another internal user
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
       | user2    |
@@ -27,7 +27,7 @@ Feature: Sharing files and folders with internal users
   @TestAlsoOnExternalUserBackend @skipOnFIREFOX
   Scenario: share a file with another internal user who overwrites and unshares the file
     Given user "user1" has been created with default attributes and without skeleton files
-    And user "user2" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
     And user "user2" has logged in using the webUI
     When the user renames file "lorem.txt" to "new-lorem.txt" using the webUI
     And the user shares file "new-lorem.txt" with user "User One" using the webUI
@@ -47,7 +47,7 @@ Feature: Sharing files and folders with internal users
   @TestAlsoOnExternalUserBackend
   Scenario: share a folder with another internal user who uploads, overwrites and deletes files
     Given user "user1" has been created with default attributes and without skeleton files
-    And user "user2" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
     And user "user2" has logged in using the webUI
     When the user renames folder "simple-folder" to "new-simple-folder" using the webUI
     And the user shares folder "new-simple-folder" with user "User One" using the webUI
@@ -76,7 +76,7 @@ Feature: Sharing files and folders with internal users
   @TestAlsoOnExternalUserBackend
   Scenario: share a folder with another internal user who unshares the folder
     Given user "user1" has been created with default attributes and without skeleton files
-    And user "user2" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
     And user "user2" has logged in using the webUI
     When the user renames folder "simple-folder" to "new-simple-folder" using the webUI
     And the user shares folder "new-simple-folder" with user "User One" using the webUI
@@ -93,7 +93,7 @@ Feature: Sharing files and folders with internal users
 
   @skipOnMICROSOFTEDGE @TestAlsoOnExternalUserBackend
   Scenario: share a folder with another internal user and prohibit deleting
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
       | user2    |
@@ -108,7 +108,7 @@ Feature: Sharing files and folders with internal users
   @skipOnFIREFOX
   Scenario: share a folder with other user and then it should be listed on Shared with You for other user
     Given user "user1" has been created with default attributes and without skeleton files
-    And user "user2" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
     And user "user2" has logged in using the webUI
     And the user has renamed folder "simple-folder" to "new-simple-folder" using the webUI
     And the user has renamed file "lorem.txt" to "ipsum.txt" using the webUI
@@ -121,7 +121,7 @@ Feature: Sharing files and folders with internal users
 
   Scenario: share a folder with other user and then it should be listed on Shared with Others page
     Given user "user1" has been created with default attributes and without skeleton files
-    And user "user2" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
     And user "user2" has logged in using the webUI
     And the user has shared file "lorem.txt" with user "User One" using the webUI
     And the user has shared folder "simple-folder" with user "User One" using the webUI
@@ -131,7 +131,7 @@ Feature: Sharing files and folders with internal users
 
   Scenario: share two file with same name but different paths
     Given user "user1" has been created with default attributes and without skeleton files
-    And user "user2" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
     And user "user2" has logged in using the webUI
     And the user has shared file "lorem.txt" with user "User One" using the webUI
     When the user opens folder "simple-folder" using the webUI
@@ -146,7 +146,7 @@ Feature: Sharing files and folders with internal users
       | username |
       | user1    |
       | user3    |
-    And user "user2" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
     And user "user1" has been added to group "grp1"
     And the administrator has browsed to the admin sharing settings page
     When the administrator enables exclude groups from sharing using the webUI
@@ -158,7 +158,7 @@ Feature: Sharing files and folders with internal users
       | username |
       | user1    |
       | user3    |
-    And user "user2" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
     And the administrator has browsed to the admin sharing settings page
@@ -167,7 +167,7 @@ Feature: Sharing files and folders with internal users
     Then user "user1" should not be able to share folder "simple-folder" with user "User Three" using the sharing API
 
   Scenario: member of a blacklisted from sharing group tries to re-share a file received as a share
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
       | user3    |
@@ -205,7 +205,7 @@ Feature: Sharing files and folders with internal users
       | user1    |
       | user2    |
       | user4    |
-    And user "user3" has been created with default attributes
+    And user "user3" has been created with default attributes and skeleton files
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
     And the administrator has browsed to the admin sharing settings page
@@ -233,7 +233,7 @@ Feature: Sharing files and folders with internal users
 
   Scenario: user tries to share a file from a group which is blacklisted from sharing using webUI from files page
     Given group "grp1" has been created
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user1" has been added to group "grp1"
     And the administrator has browsed to the admin sharing settings page
     And the administrator has enabled exclude groups from sharing from the admin sharing settings page
@@ -245,7 +245,7 @@ Feature: Sharing files and folders with internal users
 
   Scenario: user tries to re-share a file from a group which is blacklisted from sharing using webUI from shared with you page
     Given group "grp1" has been created
-    And these users have been created with default attributes:
+    And these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
       | user2    |
@@ -263,7 +263,7 @@ Feature: Sharing files and folders with internal users
     And user "user1" should not be able to share file "testimage (2).jpg" with user "User Three" using the sharing API
 
   Scenario: user shares the file/folder with another internal user and delete the share with user
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
       | user2    |
@@ -279,7 +279,7 @@ Feature: Sharing files and folders with internal users
   @mailhog
   Scenario: user should be able to send notification by email when allow share mail notification has been enabled
     Given parameter "shareapi_allow_mail_notification" of app "core" has been set to "yes"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user2" has been created with default attributes and without skeleton files
     And user "user1" has logged in using the webUI
     And user "user1" has shared file "lorem.txt" with user "user2"
@@ -294,7 +294,7 @@ Feature: Sharing files and folders with internal users
   @mailhog
   Scenario: user should get and error message when trying to send notification by email to a user who has not setup their email
     Given parameter "shareapi_allow_mail_notification" of app "core" has been set to "yes"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And these users have been created without skeleton files:
       | username | password |
       | user0    | 1234     |
@@ -309,7 +309,7 @@ Feature: Sharing files and folders with internal users
   @mailhog
   Scenario: user should not be able to send notification by email more than once
     Given parameter "shareapi_allow_mail_notification" of app "core" has been set to "yes"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user2" has been created with default attributes and without skeleton files
     And user "user1" has logged in using the webUI
     And user "user1" has shared file "lorem.txt" with user "user2"
@@ -322,7 +322,7 @@ Feature: Sharing files and folders with internal users
 
   Scenario: user should not be able to send notification by email when allow share mail notification has been disabled
     Given parameter "shareapi_allow_mail_notification" of app "core" has been set to "no"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     And user "user2" has been created with default attributes and without skeleton files
     And user "user1" has logged in using the webUI
     And user "user1" has shared file "lorem.txt" with user "user2"
@@ -331,7 +331,7 @@ Feature: Sharing files and folders with internal users
 
   @issue-35382
   Scenario: user shares a file with another user with uppercase username
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And these users have been created without skeleton files:
       | username |
       | SomeUser |
diff --git a/tests/acceptance/features/webUISharingNotifications/notificationLink.feature b/tests/acceptance/features/webUISharingNotifications/notificationLink.feature
index 6ecc0f18901f..bbe256f11b55 100644
--- a/tests/acceptance/features/webUISharingNotifications/notificationLink.feature
+++ b/tests/acceptance/features/webUISharingNotifications/notificationLink.feature
@@ -6,7 +6,7 @@ Feature: Display notifications when receiving a share and follow embedded links
 
   Background:
     Given app "notifications" has been enabled
-    And these users have been created with default attributes:
+    And these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
       | user2    |
diff --git a/tests/acceptance/features/webUISharingNotifications/shareWithGroups.feature b/tests/acceptance/features/webUISharingNotifications/shareWithGroups.feature
index bf2ba1f0a9b7..10a2335f2362 100644
--- a/tests/acceptance/features/webUISharingNotifications/shareWithGroups.feature
+++ b/tests/acceptance/features/webUISharingNotifications/shareWithGroups.feature
@@ -6,7 +6,7 @@ Feature: Sharing files and folders with internal groups
 
   Background:
     Given app "notifications" has been enabled
-    And these users have been created with default attributes:
+    And these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
       | user2    |
diff --git a/tests/acceptance/features/webUISharingNotifications/shareWithUsers.feature b/tests/acceptance/features/webUISharingNotifications/shareWithUsers.feature
index c6e48f010bbf..89128535459a 100644
--- a/tests/acceptance/features/webUISharingNotifications/shareWithUsers.feature
+++ b/tests/acceptance/features/webUISharingNotifications/shareWithUsers.feature
@@ -6,7 +6,7 @@ Feature: Sharing files and folders with internal users
 
   Background:
     Given app "notifications" has been enabled
-    And these users have been created with default attributes:
+    And these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
       | user2    |
diff --git a/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature b/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
index 809bb6e08144..4f882d7b7dc7 100644
--- a/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
+++ b/tests/acceptance/features/webUISharingPublic/shareByPublicLink.feature
@@ -9,7 +9,7 @@ Feature: Share by public link
   So that public sharing is limited according to organization policy
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
 
   @smokeTest
@@ -42,7 +42,7 @@ Feature: Share by public link
   @skipOnINTERNETEXPLORER @skipOnMICROSOFTEDGE @issue-30392
   Scenario: mount public link
     Given using server "REMOTE"
-    And user "user2" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
     When the user creates a new public link for folder "simple-folder" using the webUI
     And the user logs out of the webUI
     And the public accesses the last created public link using the webUI
@@ -57,7 +57,7 @@ Feature: Share by public link
   @skipOnINTERNETEXPLORER @skipOnMICROSOFTEDGE @issue-30392
   Scenario: mount public link and overwrite file
     Given using server "REMOTE"
-    And user "user2" has been created with default attributes
+    And user "user2" has been created with default attributes and skeleton files
     When the user creates a new public link for folder "simple-folder" using the webUI with
       | permission | read-write |
     And the user logs out of the webUI
diff --git a/tests/acceptance/features/webUITags/createTags.feature b/tests/acceptance/features/webUITags/createTags.feature
index 6add25f01558..87905cabcd65 100644
--- a/tests/acceptance/features/webUITags/createTags.feature
+++ b/tests/acceptance/features/webUITags/createTags.feature
@@ -5,7 +5,7 @@ Feature: Creation of tags for the files and folders
   So that I can find them easily
 
   Background:
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
     And the user has browsed to the login page
@@ -39,7 +39,7 @@ Feature: Creation of tags for the files and folders
 
   @skipOnFIREFOX
   Scenario: Create and add tag on a shared file
-    Given user "user2" has been created with default attributes
+    Given user "user2" has been created with default attributes and skeleton files
     When the user renames file "lorem.txt" to "coolnewfile.txt" using the webUI
     And the user browses directly to display the details of file "coolnewfile.txt" in folder ""
     And the user adds a tag "tag1" to the file using the webUI
diff --git a/tests/acceptance/features/webUITags/deleteTags.feature b/tests/acceptance/features/webUITags/deleteTags.feature
index 8e054681567c..b10c5fc3c93d 100644
--- a/tests/acceptance/features/webUITags/deleteTags.feature
+++ b/tests/acceptance/features/webUITags/deleteTags.feature
@@ -5,7 +5,7 @@ Feature: Deletion of existing tags from files and folders
   So that I can keep my filing system clean and tidy
 
   Background:
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
     And the user has browsed to the login page
@@ -13,7 +13,7 @@ Feature: Deletion of existing tags from files and folders
 
 @skipOnFIREFOX
   Scenario: Delete a tag in a shared file
-    Given user "user2" has been created with default attributes
+    Given user "user2" has been created with default attributes and skeleton files
     When the user renames file "lorem.txt" to "coolnewfile.txt" using the webUI
     And the user browses directly to display the details of file "coolnewfile.txt" in folder ""
     And the user adds a tag "tag1" to the file using the webUI
diff --git a/tests/acceptance/features/webUITags/editTags.feature b/tests/acceptance/features/webUITags/editTags.feature
index 9fe8738cb4a5..193497421de5 100644
--- a/tests/acceptance/features/webUITags/editTags.feature
+++ b/tests/acceptance/features/webUITags/editTags.feature
@@ -5,7 +5,7 @@ Feature: Edit tags for files and folders
   So that I can find them easily
 
   Background:
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
       | user2    |
diff --git a/tests/acceptance/features/webUITags/removeTags.feature b/tests/acceptance/features/webUITags/removeTags.feature
index 65b00ffecb59..b5b773ca6250 100644
--- a/tests/acceptance/features/webUITags/removeTags.feature
+++ b/tests/acceptance/features/webUITags/removeTags.feature
@@ -5,7 +5,7 @@ Feature: Removal of already existing tags from files and folders
   So that I can properly organize my filing system
 
   Background:
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
       | user2    |
diff --git a/tests/acceptance/features/webUITags/tagsSuggestion.feature b/tests/acceptance/features/webUITags/tagsSuggestion.feature
index 944744bf79c4..7991fbd6e197 100644
--- a/tests/acceptance/features/webUITags/tagsSuggestion.feature
+++ b/tests/acceptance/features/webUITags/tagsSuggestion.feature
@@ -5,7 +5,7 @@ Feature: Suggestion for matching tag names
   So that I can easily categorize the files
 
   Background:
-    Given these users have been created with default attributes:
+    Given these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
     Given user "user1" has created a "normal" tag with name "spam"
diff --git a/tests/acceptance/features/webUITrashbin/trashbinDelete.feature b/tests/acceptance/features/webUITrashbin/trashbinDelete.feature
index 94be78cd2759..0cb581c0de5a 100644
--- a/tests/acceptance/features/webUITrashbin/trashbinDelete.feature
+++ b/tests/acceptance/features/webUITrashbin/trashbinDelete.feature
@@ -5,7 +5,7 @@ Feature: files and folders can be deleted from the trashbin
   So that I can control my trashbin space and which files are kept in that space
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
     And the following files have been deleted
       | name          |
diff --git a/tests/acceptance/features/webUITrashbin/trashbinFilesFolders.feature b/tests/acceptance/features/webUITrashbin/trashbinFilesFolders.feature
index efbab267a76e..f39c9a6403f4 100644
--- a/tests/acceptance/features/webUITrashbin/trashbinFilesFolders.feature
+++ b/tests/acceptance/features/webUITrashbin/trashbinFilesFolders.feature
@@ -5,7 +5,7 @@ Feature: files and folders exist in the trashbin after being deleted
   So that I can recover data easily
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the files page
 
diff --git a/tests/acceptance/features/webUITrashbin/trashbinRestore.feature b/tests/acceptance/features/webUITrashbin/trashbinRestore.feature
index 75f9706252c5..82d2c5d1877d 100644
--- a/tests/acceptance/features/webUITrashbin/trashbinRestore.feature
+++ b/tests/acceptance/features/webUITrashbin/trashbinRestore.feature
@@ -5,7 +5,7 @@ Feature: Restore deleted files/folders
   So that I can recover accidentally deleted files/folders in ownCloud
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the files page
 
diff --git a/tests/acceptance/features/webUIUpload/upload.feature b/tests/acceptance/features/webUIUpload/upload.feature
index 4ca440b318ce..f8c2e05c5b38 100644
--- a/tests/acceptance/features/webUIUpload/upload.feature
+++ b/tests/acceptance/features/webUIUpload/upload.feature
@@ -6,7 +6,7 @@ Feature: File Upload
   So that I can store files in ownCloud
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
 
   @smokeTest
diff --git a/tests/acceptance/features/webUIUpload/uploadEdgecases.feature b/tests/acceptance/features/webUIUpload/uploadEdgecases.feature
index 8c552a6932f7..cb0e5b76b657 100644
--- a/tests/acceptance/features/webUIUpload/uploadEdgecases.feature
+++ b/tests/acceptance/features/webUIUpload/uploadEdgecases.feature
@@ -8,7 +8,7 @@ Feature: File Upload
   that is not academically correct but saves a lot of time
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
     And user "user1" has logged in using the webUI
 
   Scenario: simple upload of a file that does not exist before
diff --git a/tests/acceptance/features/webUIUpload/uploadFileGreaterThanQuotaSize.feature b/tests/acceptance/features/webUIUpload/uploadFileGreaterThanQuotaSize.feature
index 26a3bad63e1f..e012ea494786 100644
--- a/tests/acceptance/features/webUIUpload/uploadFileGreaterThanQuotaSize.feature
+++ b/tests/acceptance/features/webUIUpload/uploadFileGreaterThanQuotaSize.feature
@@ -6,7 +6,7 @@ Feature: Upload a file
   So that I can store it in owncloud
 
   Background:
-    Given user "user1" has been created with default attributes
+    Given user "user1" has been created with default attributes and skeleton files
 
   @smokeTest
   Scenario: simple upload of a file with the size greater than the size of quota

From 51d7ae1d84af7df2d8cda146d05e32634075e252 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Wed, 5 Jun 2019 17:58:10 +0545
Subject: [PATCH 081/131] Update 'and skeleton files' step text in user
 management and encryption tests

---
 .../cliEncryption/recreatemasterkey.feature      |  2 +-
 .../webUIManageUsersGroups/disableUsers.feature  |  2 +-
 .../webUIManageUsersGroups/editUsers.feature     | 16 ++++++++--------
 .../webUIMasterKeyType/webUIMasterKeys.feature   |  4 ++--
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/tests/acceptance/features/cliEncryption/recreatemasterkey.feature b/tests/acceptance/features/cliEncryption/recreatemasterkey.feature
index 1c8dcdd46be6..48db6f0851b5 100644
--- a/tests/acceptance/features/cliEncryption/recreatemasterkey.feature
+++ b/tests/acceptance/features/cliEncryption/recreatemasterkey.feature
@@ -7,7 +7,7 @@ Feature: recreate-master-key
     Then the downloaded content when downloading file "/somefile.txt" for user "admin" with range "bytes=0-6" should be "This is"
 
   Scenario: recreate masterkey and upload data
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And user "user0" has uploaded file "filesForUpload/textfile.txt" to "/somefile.txt"
     When the administrator successfully recreates the encryption masterkey using the occ command
     And user "user0" uploads chunk file "1" of "1" with "AA" to "/somefile.txt" using the WebDAV API
diff --git a/tests/acceptance/features/webUIManageUsersGroups/disableUsers.feature b/tests/acceptance/features/webUIManageUsersGroups/disableUsers.feature
index 4879cba9c0e9..d6198d01d0e4 100644
--- a/tests/acceptance/features/webUIManageUsersGroups/disableUsers.feature
+++ b/tests/acceptance/features/webUIManageUsersGroups/disableUsers.feature
@@ -23,7 +23,7 @@ Feature: disable users
 
   Scenario: subadmin disables a user
     Given group "grp1" has been created
-    And user "subadmin" has been created with default attributes
+    And user "subadmin" has been created with default attributes and skeleton files
     And user "user1" has been added to group "grp1"
     And user "user2" has been added to group "grp1"
     And user "subadmin" has been made a subadmin of group "grp1"
diff --git a/tests/acceptance/features/webUIManageUsersGroups/editUsers.feature b/tests/acceptance/features/webUIManageUsersGroups/editUsers.feature
index d1f54dab2741..d35bdaaa8195 100644
--- a/tests/acceptance/features/webUIManageUsersGroups/editUsers.feature
+++ b/tests/acceptance/features/webUIManageUsersGroups/editUsers.feature
@@ -8,7 +8,7 @@ Feature: edit users
     Given user admin has logged in using the webUI
 
   Scenario: Admin changes the display name of the user
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And the administrator has browsed to the users page
     When the administrator changes the display name of user "user0" to "New User" using the webUI
     And the administrator logs out of the webUI
@@ -20,7 +20,7 @@ Feature: edit users
 
   @skipOnEncryptionType:user-keys
   Scenario: Admin changes the password of the user
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And the administrator has browsed to the users page
     When the administrator changes the password of user "user0" to "new_password" using the webUI
     Then user "user0" should exist
@@ -28,7 +28,7 @@ Feature: edit users
     But user "user1" using password "%regular%" should not be able to download file "textfile0.txt"
 
   Scenario: Admin adds a user to a group
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And group "grp1" has been created
     And the administrator has browsed to the users page
     When the administrator adds user "user0" to group "grp1" using the webUI
@@ -36,7 +36,7 @@ Feature: edit users
     And user "user0" should belong to group "grp1"
 
   Scenario: Admin adds a user to a group when multiple groups are created
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And group "grp1" has been created
     And group "grp2" has been created
     And group "grp3" has been created
@@ -48,7 +48,7 @@ Feature: edit users
     And user "user0" should not belong to group "grp3"
 
   Scenario: Admin adds a user to multiple groups
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And group "grp1" has been created
     And group "grp2" has been created
     And group "grp3" has been created
@@ -61,7 +61,7 @@ Feature: edit users
     And user "user0" should not belong to group "grp1"
 
   Scenario: Admin removes a user from a group
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And group "grp1" has been created
     And user "user0" has been added to group "grp1"
     And the administrator has browsed to the users page
@@ -70,7 +70,7 @@ Feature: edit users
     And user "user0" should not belong to group "grp1"
 
   Scenario: Admin removes user from multiple groups
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And group "grp1" has been created
     And group "grp2" has been created
     And group "grp3" has been created
@@ -86,7 +86,7 @@ Feature: edit users
     And user "user0" should belong to group "grp3"
 
   Scenario: Admin changes the email of the user
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And the administrator has browsed to the users page
     When the administrator changes the email of user "user0" to "new_email@oc.com" using the webUI
     Then user "user0" should exist
diff --git a/tests/acceptance/features/webUIMasterKeyType/webUIMasterKeys.feature b/tests/acceptance/features/webUIMasterKeyType/webUIMasterKeys.feature
index 519c5e652b91..93bb1cd27acf 100644
--- a/tests/acceptance/features/webUIMasterKeyType/webUIMasterKeys.feature
+++ b/tests/acceptance/features/webUIMasterKeyType/webUIMasterKeys.feature
@@ -5,7 +5,7 @@ Feature: encrypt files using master keys
   So that I can use a common key to encrypt files of all user
 
   Scenario: user cannot access their file after recreating master key with re-login
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And the administrator has set the encryption type to "masterkey"
     And user "user0" has uploaded file "filesForUpload/textfile.txt" to "/somefile.txt"
     And user "user0" has logged in using the webUI
@@ -17,7 +17,7 @@ Feature: encrypt files using master keys
     And a message should be displayed on the general exception webUI page containing "Encryption not ready"
 
   Scenario: user can access their file after recreating master key with re-login
-    Given user "user0" has been created with default attributes
+    Given user "user0" has been created with default attributes and skeleton files
     And the administrator has set the encryption type to "masterkey"
     And user "user0" has uploaded file "filesForUpload/textfile.txt" to "/somefile.txt"
     And user "user0" has logged in using the webUI

From d6bc9cc315c1691a449766d5d8ad0f3814ab8208 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Wed, 5 Jun 2019 17:58:41 +0545
Subject: [PATCH 082/131] Update 'and skeleton files' step text in
 ocsGETAuth.feature

---
 tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature b/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature
index 1ee1a3b36ed6..279b54ce111b 100644
--- a/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature
+++ b/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature
@@ -85,7 +85,7 @@ Feature: auth
   @issue-32068
   Scenario Outline: send POST requests to OCS endpoints as normal user with wrong password
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes
+    And user "user1" has been created with default attributes and skeleton files
     When user "user0" sends HTTP method "POST" to OCS API endpoint "<endpoint>" with body using password "invalid"
       | data        | doesnotmatter |
     Then the OCS status code should be "<ocs-code>"

From 577d139d6b9ee02efffe19a039b5f38479bcd1b1 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Wed, 5 Jun 2019 21:48:32 +0545
Subject: [PATCH 083/131] Given these users have been created with skeleton
 files

---
 .../resetUserPassword.feature                 | 12 ++++-----
 .../resetUserPassword.feature                 | 12 ++++-----
 .../features/bootstrap/Provisioning.php       | 17 ++++++++++--
 .../cliProvisioning/deleteUser.feature        |  4 +--
 .../features/cliProvisioning/getGroup.feature |  2 +-
 .../cliProvisioning/resetUserPassword.feature | 10 +++----
 .../webUIWebdavLockProtection/delete.feature  |  2 +-
 .../webUIWebdavLockProtection/move.feature    |  2 +-
 .../webUIWebdavLockProtection/upload.feature  |  2 +-
 .../features/webUIWebdavLocks/locks.feature   | 26 +++++++++----------
 .../features/webUIWebdavLocks/unlock.feature  | 12 ++++-----
 11 files changed, 57 insertions(+), 44 deletions(-)

diff --git a/tests/acceptance/features/apiProvisioning-v1/resetUserPassword.feature b/tests/acceptance/features/apiProvisioning-v1/resetUserPassword.feature
index 3e799473868e..708a88ddb73f 100644
--- a/tests/acceptance/features/apiProvisioning-v1/resetUserPassword.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/resetUserPassword.feature
@@ -9,7 +9,7 @@ Feature: reset user password
 
   @smokeTest @skipOnEncryptionType:user-keys @encryption-issue-57
   Scenario: reset user password
-    Given these users have been created:
+    Given these users have been created with 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
@@ -25,7 +25,7 @@ Feature: reset user password
 
   @smokeTest @skipOnEncryptionType:user-keys @encryption-issue-57
   Scenario: subadmin should be able to reset the password of a user in their group
-    Given these users have been created:
+    Given these users have been created with 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      |
@@ -39,7 +39,7 @@ Feature: reset user password
     But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt"
 
   Scenario: subadmin should not be able to reset the password of a user not in their group
-    Given these users have been created:
+    Given these users have been created with 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      |
@@ -52,7 +52,7 @@ Feature: reset user password
     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:
+    Given these users have been created with skeleton files:
       | username       | password   | displayname    | email                    |
       | brand-new-user | %regular%  | New user       | brand.new.user@oc.com.np |
       | wannabeadmin   | %altadmin% | Wanna Be Admin | wanna.be.admin@oc.com.np |
@@ -63,7 +63,7 @@ Feature: reset user password
     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:
+    Given these users have been created with 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
@@ -74,7 +74,7 @@ Feature: reset user password
 
   @skipOnEncryptionType:user-keys @encryption-issue-57
   Scenario Outline: reset user password including emoji
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username       | password  | displayname | email                    |
       | brand-new-user | %regular% | New user    | brand.new.user@oc.com.np |
     When the administrator resets the password of user "brand-new-user" to "<password>" using the provisioning API
diff --git a/tests/acceptance/features/apiProvisioning-v2/resetUserPassword.feature b/tests/acceptance/features/apiProvisioning-v2/resetUserPassword.feature
index 605087c102ef..d1bbce94a727 100644
--- a/tests/acceptance/features/apiProvisioning-v2/resetUserPassword.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/resetUserPassword.feature
@@ -9,7 +9,7 @@ Feature: reset user password
 
   @smokeTest @skipOnEncryptionType:user-keys @encryption-issue-57
   Scenario: reset user password
-    Given these users have been created:
+    Given these users have been created with 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
@@ -25,7 +25,7 @@ Feature: reset user password
 
   @smokeTest @skipOnEncryptionType:user-keys @encryption-issue-57
   Scenario: subadmin should be able to reset the password of a user in their group
-    Given these users have been created:
+    Given these users have been created with 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      |
@@ -39,7 +39,7 @@ Feature: reset user password
     But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt"
 
   Scenario: subadmin should not be able to reset the password of a user not in their group
-    Given these users have been created:
+    Given these users have been created with 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      |
@@ -52,7 +52,7 @@ Feature: reset user password
     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:
+    Given these users have been created with skeleton files:
       | username       | password   | displayname    | email                    |
       | brand-new-user | %regular%  | New user       | brand.new.user@oc.com.np |
       | wannabeadmin   | %altadmin% | Wanna Be Admin | wanna.be.admin@oc.com.np |
@@ -63,7 +63,7 @@ Feature: reset user password
     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:
+    Given these users have been created with 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
@@ -74,7 +74,7 @@ Feature: reset user password
 
   @skipOnEncryptionType:user-keys @encryption-issue-57
   Scenario Outline: reset user password including emoji
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username       | password  | displayname | email                    |
       | brand-new-user | %regular% | New user    | brand.new.user@oc.com.np |
     When the administrator resets the password of user "brand-new-user" to "<password>" using the provisioning API
diff --git a/tests/acceptance/features/bootstrap/Provisioning.php b/tests/acceptance/features/bootstrap/Provisioning.php
index 5b14d8c0e3c6..5f306f681eb4 100644
--- a/tests/acceptance/features/bootstrap/Provisioning.php
+++ b/tests/acceptance/features/bootstrap/Provisioning.php
@@ -331,8 +331,21 @@ public function theseUsersHaveBeenCreatedWithoutSkeletonFiles(TableNode $table)
 	}
 
 	/**
-	 * @Given /^these users have been created\s?(with default attributes|)\s?(but not initialized|):$/
-	 * @Given /^these users have been created\s?(with default attributes and skeleton files|)\s?(but not initialized|):$/
+	 * @Given these users have been created with skeleton files:
+	 * expects a table of users with the heading
+	 * "|username|password|displayname|email|"
+	 * password, displayname & email are optional
+	 *
+	 * @param TableNode $table
+	 *
+	 * @return void
+	 */
+	public function theseUsersHaveBeenCreatedWithSkeletonFiles(TableNode $table) {
+		$this->theseUsersHaveBeenCreated("", "", $table);
+	}
+
+	/**
+	 * @Given /^these users have been created\s?(with default attributes|with default attributes and skeleton files|)\s?(but not initialized|):$/
 	 * expects a table of users with the heading
 	 * "|username|password|displayname|email|"
 	 * password, displayname & email are optional
diff --git a/tests/acceptance/features/cliProvisioning/deleteUser.feature b/tests/acceptance/features/cliProvisioning/deleteUser.feature
index b9a8ec5bc3de..451e4f8b276d 100644
--- a/tests/acceptance/features/cliProvisioning/deleteUser.feature
+++ b/tests/acceptance/features/cliProvisioning/deleteUser.feature
@@ -5,7 +5,7 @@ Feature: delete users
   So that I can remove users from ownCloud
 
   Scenario: admin deletes a user
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username       |
       | brand-new-user |
     When the administrator deletes user "brand-new-user" using the occ command
@@ -14,7 +14,7 @@ Feature: delete users
     And user "brand-new-user" should not exist
 
   Scenario: Delete a user, and specify the user name in different case
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username       |
       | brand-new-user |
     When the administrator deletes user "Brand-New-User" using the occ command
diff --git a/tests/acceptance/features/cliProvisioning/getGroup.feature b/tests/acceptance/features/cliProvisioning/getGroup.feature
index 87c5cc41def8..155edcf74ef5 100644
--- a/tests/acceptance/features/cliProvisioning/getGroup.feature
+++ b/tests/acceptance/features/cliProvisioning/getGroup.feature
@@ -5,7 +5,7 @@ Feature: get group
   So that I can know which users are in a group
 
   Scenario: admin gets users in the group
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username       |
       | brand-new-user |
       | 123            |
diff --git a/tests/acceptance/features/cliProvisioning/resetUserPassword.feature b/tests/acceptance/features/cliProvisioning/resetUserPassword.feature
index b91a88a5f9cf..1d3ec4387e66 100644
--- a/tests/acceptance/features/cliProvisioning/resetUserPassword.feature
+++ b/tests/acceptance/features/cliProvisioning/resetUserPassword.feature
@@ -5,7 +5,7 @@ Feature: reset user password
   So that I can secure individual access to resources on the ownCloud server
 
   Scenario: reset user password
-    Given these users have been created:
+    Given these users have been created with 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 occ command
@@ -15,7 +15,7 @@ Feature: reset user password
     But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt"
 
   Scenario: user should get email when admin does a "send email" password reset without specifying a password
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username       | password  | displayname | email                    |
       | brand-new-user | %regular% | New user    | brand.new.user@oc.com.np |
     When the administrator invokes password reset for user "brand-new-user" using the occ command
@@ -27,7 +27,7 @@ Feature: reset user password
       """
 
   Scenario: user should get email when the administrator changes their password and specifies to also send email
-    Given these users have been created:
+    Given these users have been created with 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%" sending email using the occ command
@@ -41,7 +41,7 @@ Feature: reset user password
     But user "brand-new-user" using password "%regular%" should not be able to download file "textfile0.txt"
 
   Scenario: administrator gets error message while trying to reset user password with send email when the email address of the user is not setup
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username       | password  | displayname |
       | brand-new-user | %regular% | New user    |
     When the administrator invokes password reset for user "brand-new-user" using the occ command
@@ -49,7 +49,7 @@ Feature: reset user password
     And the command output should contain the text "Email address is not set for the user brand-new-user"
 
   Scenario: user should not get an email when the smtpmode value points to an invalid or missing mail program
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username       | password  | displayname | email                    |
       | brand-new-user | %regular% | New user    | brand.new.user@oc.com.np |
     And the administrator has set the mail smtpmode to "sendmail"
diff --git a/tests/acceptance/features/webUIWebdavLockProtection/delete.feature b/tests/acceptance/features/webUIWebdavLockProtection/delete.feature
index 743a7ac677ee..75ec8be67468 100644
--- a/tests/acceptance/features/webUIWebdavLockProtection/delete.feature
+++ b/tests/acceptance/features/webUIWebdavLockProtection/delete.feature
@@ -6,7 +6,7 @@ Feature: Locks
 
   Background:
     #do not set email, see bugs in https://github.com/owncloud/core/pull/32250#issuecomment-434615887
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       |username      |
       |brand-new-user|
     And user "brand-new-user" has logged in using the webUI
diff --git a/tests/acceptance/features/webUIWebdavLockProtection/move.feature b/tests/acceptance/features/webUIWebdavLockProtection/move.feature
index 6b8a5977ec44..f150e74cbaf3 100644
--- a/tests/acceptance/features/webUIWebdavLockProtection/move.feature
+++ b/tests/acceptance/features/webUIWebdavLockProtection/move.feature
@@ -6,7 +6,7 @@ Feature: Locks
 
   Background:
     #do not set email, see bugs in https://github.com/owncloud/core/pull/32250#issuecomment-434615887
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username       |
       | brand-new-user |
     And user "brand-new-user" has logged in using the webUI
diff --git a/tests/acceptance/features/webUIWebdavLockProtection/upload.feature b/tests/acceptance/features/webUIWebdavLockProtection/upload.feature
index cffbec81ed62..542fc533b60d 100644
--- a/tests/acceptance/features/webUIWebdavLockProtection/upload.feature
+++ b/tests/acceptance/features/webUIWebdavLockProtection/upload.feature
@@ -6,7 +6,7 @@ Feature: Locks
 
   Background:
     #do not set email, see bugs in https://github.com/owncloud/core/pull/32250#issuecomment-434615887
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username       |
       | brand-new-user |
     And user "brand-new-user" has logged in using the webUI
diff --git a/tests/acceptance/features/webUIWebdavLocks/locks.feature b/tests/acceptance/features/webUIWebdavLocks/locks.feature
index 60e2a505f6ee..58f175de2d76 100644
--- a/tests/acceptance/features/webUIWebdavLocks/locks.feature
+++ b/tests/acceptance/features/webUIWebdavLocks/locks.feature
@@ -6,7 +6,7 @@ Feature: Locks
 
   Background:
     #do not set email, see bugs in https://github.com/owncloud/core/pull/32250#issuecomment-434615887
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username       |
       | brand-new-user |
     And user "brand-new-user" has logged in using the webUI
@@ -25,7 +25,7 @@ Feature: Locks
     But file "data.tar.gz" should not be marked as locked on the webUI
 
   Scenario: setting a lock shows the display name of a user in the locking details
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username               | displayname   |
       | user-with-display-name | My fancy name |
     Given user "user-with-display-name" has locked folder "simple-folder" setting following properties
@@ -38,7 +38,7 @@ Feature: Locks
 
   @issue-34315
   Scenario: setting a lock shows the current display name of a user in the locking details
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username               | displayname   |
       | user-with-display-name | My fancy name |
     Given user "user-with-display-name" has locked folder "simple-folder" setting following properties
@@ -53,7 +53,7 @@ Feature: Locks
     #And file "data.zip" should be marked as locked by user "An ordinary name" in the locks tab of the details panel on the webUI
 
   Scenario: setting a lock shows the display name of a user in the locking details (user has set email address)
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username               | displayname   | email       |
       | user-with-display-name | My fancy name | mail@oc.org |
     Given user "user-with-display-name" has locked folder "simple-folder" setting following properties
@@ -65,7 +65,7 @@ Feature: Locks
     And file "data.zip" should be marked as locked by user "My fancy name (mail@oc.org)" in the locks tab of the details panel on the webUI
 
   Scenario: setting a lock shows the user name of a user in the locking details (user has set email address)
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username        | email       |
       | user-with-email | mail@oc.org |
     Given user "user-with-email" has locked folder "simple-folder" setting following properties
@@ -95,7 +95,7 @@ Feature: Locks
 
   @issue-33867
   Scenario: setting a lock shows the lock symbols at the correct files/folders on the shared-with-others page
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username |
       | receiver |
     And user "brand-new-user" has locked folder "simple-folder" setting following properties
@@ -146,7 +146,7 @@ Feature: Locks
 
   @issue-33867
   Scenario: setting a lock shows the lock symbols at the correct files/folders on the shared-with-you page
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username |
       | sharer   |
     And user "sharer" has locked folder "simple-folder" setting following properties
@@ -174,7 +174,7 @@ Feature: Locks
     Then folder "simple-folder" should not be marked as locked on the webUI
 
   Scenario: lock set on a shared file shows the lock information for all involved users
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username  |
       | sharer    |
       | receiver  |
@@ -228,7 +228,7 @@ Feature: Locks
     And file "data.zip" should not be marked as locked on the webUI
 
   Scenario Outline: decline locked folder
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username |
       | sharer   |
     And user "sharer" has created folder "/to-share-folder"
@@ -246,7 +246,7 @@ Feature: Locks
       | shared    |
 
   Scenario Outline: accept previously declined locked folder
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username |
       | sharer   |
     And user "sharer" has created folder "/to-share-folder"
@@ -266,7 +266,7 @@ Feature: Locks
       | shared    |
 
   Scenario Outline: accept previously declined locked folder but create a folder with same name in between
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username |
       | sharer   |
     And user "sharer" has created folder "/to-share-folder"
@@ -288,7 +288,7 @@ Feature: Locks
       | shared    |
 
   Scenario Outline: creating a subfolder structure that is the same as the structure of a declined & locked share
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username |
       | sharer   |
     And user "sharer" has created folder "/parent"
@@ -311,7 +311,7 @@ Feature: Locks
       | shared    |
 
   Scenario Outline: unsharing a locked file/folder
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username |
       | sharer   |
     And user "sharer" has locked file "lorem.txt" setting following properties
diff --git a/tests/acceptance/features/webUIWebdavLocks/unlock.feature b/tests/acceptance/features/webUIWebdavLocks/unlock.feature
index 6f8173782204..91529f4156a0 100644
--- a/tests/acceptance/features/webUIWebdavLocks/unlock.feature
+++ b/tests/acceptance/features/webUIWebdavLocks/unlock.feature
@@ -6,7 +6,7 @@ Feature: Unlock locked files and folders
 
   Background:
     #do not set email, see bugs in https://github.com/owncloud/core/pull/32250#issuecomment-434615887
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username       |
       | brand-new-user |
     And user "brand-new-user" has logged in using the webUI
@@ -19,7 +19,7 @@ Feature: Unlock locked files and folders
     Then folder "simple-folder" should not be marked as locked on the webUI
 
   Scenario: unlocking by webDAV after the display name has been changed deletes the lock symbols at the correct files/folders
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username               | displayname   |
       | user-with-display-name | My fancy name |
     Given user "user-with-display-name" has locked folder "simple-folder" setting following properties
@@ -108,7 +108,7 @@ Feature: Unlock locked files and folders
 
   @skipOnFIREFOX
   Scenario: deleting the first one of multiple shared locks on the webUI
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username  |
       | receiver1 |
       | receiver2 |
@@ -147,7 +147,7 @@ Feature: Unlock locked files and folders
 
   @skipOnFIREFOX
   Scenario: deleting the second one of multiple shared locks on the webUI
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username  |
       | receiver1 |
       | receiver2 |
@@ -186,7 +186,7 @@ Feature: Unlock locked files and folders
 
   @skipOnFIREFOX
   Scenario: deleting the last one of multiple shared locks on the webUI
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username  |
       | receiver1 |
       | receiver2 |
@@ -224,7 +224,7 @@ Feature: Unlock locked files and folders
     And 2 locks should be reported for folder "FOLDER_TO_SHARE" of user "receiver2" by the WebDAV API
 
   Scenario Outline: deleting a lock that was created by an other user
-    Given these users have been created:
+    Given these users have been created with skeleton files:
       | username  |
       | receiver1 |
     And user "brand-new-user" has shared file "/lorem.txt" with user "receiver1"

From 149ebc788018187725795c5f657b55341965c2b4 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Fri, 7 Jun 2019 12:06:47 +0545
Subject: [PATCH 084/131] API share_with user response is now case sensitive

---
 .../features/apiShareManagementBasic/createShare.feature        | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/acceptance/features/apiShareManagementBasic/createShare.feature b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
index 874c76a1c030..56d43781795a 100644
--- a/tests/acceptance/features/apiShareManagementBasic/createShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
@@ -600,7 +600,7 @@ Feature: sharing
     Then the OCS status code should be "100"
     And the HTTP status code should be "200"
     And the fields of the last response should include
-      | share_with  |  user1       |
+      | share_with  |  USER1       |
       | file_target | /welcome.txt |
       | path        | /welcome.txt |
       | permissions | 19           |

From b519538f3dab331a31c7884237c25a56249618cc Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Fri, 7 Jun 2019 12:07:59 +0545
Subject: [PATCH 085/131] Issue 35382 is resolved - webUI sharing to uppercase
 username works

---
 .../features/webUISharingInternalUsers/shareWithUsers.feature | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature b/tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature
index 42abacc7e5b6..02d0de8214b3 100644
--- a/tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature
+++ b/tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature
@@ -329,7 +329,6 @@ Feature: Sharing files and folders with internal users
     When the user opens the share dialog for file "lorem.txt"
     Then the user should not be able to send the share notification by email using the webUI
 
-  @issue-35382
   Scenario: user shares a file with another user with uppercase username
     Given user "user1" has been created with default attributes and skeleton files
     And these users have been created without skeleton files:
@@ -339,5 +338,4 @@ Feature: Sharing files and folders with internal users
     When the user shares file "lorem.txt" with user "SomeUser" using the webUI
     And the user re-logs in as "SomeUser" using the webUI
     And the user browses to the shared-with-you page
-    Then file "lorem.txt" should not be listed on the webUI
-#    Then file "lorem.txt" should be listed on the webUI
+    Then file "lorem.txt" should be listed on the webUI

From e25f77db529ddea7dc415e017b186063d1ad2b80 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Fri, 7 Jun 2019 09:29:38 +0545
Subject: [PATCH 086/131] Remove deprecated default attributes test steps

---
 .../features/bootstrap/Provisioning.php         | 17 +----------------
 1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/tests/acceptance/features/bootstrap/Provisioning.php b/tests/acceptance/features/bootstrap/Provisioning.php
index 5f306f681eb4..6183fef793bb 100644
--- a/tests/acceptance/features/bootstrap/Provisioning.php
+++ b/tests/acceptance/features/bootstrap/Provisioning.php
@@ -256,7 +256,6 @@ public function userHasBeenCreatedOnDatabaseBackend($user) {
 	}
 
 	/**
-	 * @Given /^user "([^"]*)" has been created with default attributes$/
 	 * @Given /^user "([^"]*)" has been created with default attributes and skeleton files$/
 	 *
 	 * @param string $user
@@ -331,21 +330,7 @@ public function theseUsersHaveBeenCreatedWithoutSkeletonFiles(TableNode $table)
 	}
 
 	/**
-	 * @Given these users have been created with skeleton files:
-	 * expects a table of users with the heading
-	 * "|username|password|displayname|email|"
-	 * password, displayname & email are optional
-	 *
-	 * @param TableNode $table
-	 *
-	 * @return void
-	 */
-	public function theseUsersHaveBeenCreatedWithSkeletonFiles(TableNode $table) {
-		$this->theseUsersHaveBeenCreated("", "", $table);
-	}
-
-	/**
-	 * @Given /^these users have been created\s?(with default attributes|with default attributes and skeleton files|)\s?(but not initialized|):$/
+	 * @Given /^these users have been created with ?(default attributes and|) skeleton files ?(but not initialized|):$/
 	 * expects a table of users with the heading
 	 * "|username|password|displayname|email|"
 	 * password, displayname & email are optional

From ddf23f99762952506f26e0ab931d3e3ef994e17c Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Fri, 7 Jun 2019 10:59:28 +0545
Subject: [PATCH 087/131] Adjust more 'with skeleton files' steps

---
 .../webUISharingAutocompletion/shareAutocompletion.feature  | 2 +-
 .../features/webUISharingExternal/federationSharing.feature | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tests/acceptance/features/webUISharingAutocompletion/shareAutocompletion.feature b/tests/acceptance/features/webUISharingAutocompletion/shareAutocompletion.feature
index 208f8319f2c2..f07e20960ea0 100644
--- a/tests/acceptance/features/webUISharingAutocompletion/shareAutocompletion.feature
+++ b/tests/acceptance/features/webUISharingAutocompletion/shareAutocompletion.feature
@@ -65,7 +65,7 @@ Feature: Autocompletion of share-with names
     Given the administrator has set the minimum characters for sharing autocomplete to "4"
     And user "regularuser" has logged in using the webUI
     And the user has browsed to the files page
-    And these users have been created but not initialized:
+    And these users have been created with skeleton files but not initialized:
       | username | password | displayname | email        |
       | use      | %alt1%   | Use         | uz@oc.com.np |
     And the user has opened the share dialog for folder "simple-folder"
diff --git a/tests/acceptance/features/webUISharingExternal/federationSharing.feature b/tests/acceptance/features/webUISharingExternal/federationSharing.feature
index 5c1a54afa26e..0a5db836a249 100644
--- a/tests/acceptance/features/webUISharingExternal/federationSharing.feature
+++ b/tests/acceptance/features/webUISharingExternal/federationSharing.feature
@@ -247,7 +247,7 @@ Feature: Federation Sharing - sharing with users on other cloud storages
 
   Scenario: test sharing folder to a remote server and resharing it back to the local
     Given using server "LOCAL"
-    And these users have been created:
+    And these users have been created with skeleton files:
       | username |
       | user2    |
     When the user shares folder "simple-folder" with remote user "user1@%remote_server_without_scheme%" using the webUI
@@ -261,7 +261,7 @@ Feature: Federation Sharing - sharing with users on other cloud storages
 
   Scenario: test resharing folder as readonly and set it as readonly by resharer
     Given using server "LOCAL"
-    And these users have been created:
+    And these users have been created with skeleton files:
       | username |
       | user2    |
     When the user shares folder "simple-folder" with remote user "user1@%remote_server_without_scheme%" using the webUI
@@ -279,7 +279,7 @@ Feature: Federation Sharing - sharing with users on other cloud storages
 
   Scenario: test resharing folder and set it as readonly by owner
     Given using server "LOCAL"
-    And these users have been created:
+    And these users have been created with skeleton files:
       | username |
       | user2    |
     When the user shares folder "simple-folder" with remote user "user1@%remote_server_without_scheme%" using the webUI

From 4dcb0de7cd0b356b2c983a602a21b60466d55b29 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Fri, 7 Jun 2019 14:12:33 +0545
Subject: [PATCH 088/131] Adjust encryption accceptance test steps for 'created
 with skeleton files'

---
 tests/acceptance/features/webUIUserKeysType/userKeys.feature | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/acceptance/features/webUIUserKeysType/userKeys.feature b/tests/acceptance/features/webUIUserKeysType/userKeys.feature
index d24babb057b2..605ec41e8815 100644
--- a/tests/acceptance/features/webUIUserKeysType/userKeys.feature
+++ b/tests/acceptance/features/webUIUserKeysType/userKeys.feature
@@ -6,7 +6,7 @@ Feature: encrypt files using user specific keys
 
   Background:
     Given app "encryption" has been enabled
-    And these users have been created but not initialized:
+    And these users have been created with skeleton files but not initialized:
       | username       |
       | brand-new-user |
     And encryption has been enabled
@@ -27,7 +27,7 @@ Feature: encrypt files using user specific keys
     Then file "textfile0.txt" of user "brand-new-user" should be encrypted
 
   Scenario: decrypt user keys based encryption of all users
-    Given these users have been created but not initialized:
+    Given these users have been created with skeleton files but not initialized:
       | username         |
       | another-new-user |
     And the administrator has set the encryption type to "user-keys"

From afd193ae52405ae004001491bbd611a3597c0f6f Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Fri, 7 Jun 2019 14:12:59 +0545
Subject: [PATCH 089/131] Adjust user_management accceptance test steps for
 'created with skeleton files'

---
 .../features/webUIManageQuota/manageUserQuota.feature           | 2 +-
 .../features/webUIManageUsersGroups/deleteUsers.feature         | 2 +-
 .../features/webUIManageUsersGroups/disableUsers.feature        | 2 +-
 .../acceptance/features/webUISettingsMenu/settingsMenu.feature  | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tests/acceptance/features/webUIManageQuota/manageUserQuota.feature b/tests/acceptance/features/webUIManageQuota/manageUserQuota.feature
index 711838ca0c55..80894280d09a 100644
--- a/tests/acceptance/features/webUIManageQuota/manageUserQuota.feature
+++ b/tests/acceptance/features/webUIManageQuota/manageUserQuota.feature
@@ -5,7 +5,7 @@ Feature: manage user quota
   So that users can only take up a certain amount of storage space
 
   Background:
-    Given these users have been created with default attributes but not initialized:
+    Given these users have been created with default attributes and skeleton files but not initialized:
       | username |
       | user1    |
     And the administrator has logged in using the webUI
diff --git a/tests/acceptance/features/webUIManageUsersGroups/deleteUsers.feature b/tests/acceptance/features/webUIManageUsersGroups/deleteUsers.feature
index bec9bc819099..140c85cd563d 100644
--- a/tests/acceptance/features/webUIManageUsersGroups/deleteUsers.feature
+++ b/tests/acceptance/features/webUIManageUsersGroups/deleteUsers.feature
@@ -5,7 +5,7 @@ Feature: delete users
   So that I can remove users
 
   Background:
-    Given these users have been created with default attributes but not initialized:
+    Given these users have been created with default attributes and skeleton files but not initialized:
       | username |
       | user1    |
       | user2    |
diff --git a/tests/acceptance/features/webUIManageUsersGroups/disableUsers.feature b/tests/acceptance/features/webUIManageUsersGroups/disableUsers.feature
index d6198d01d0e4..30ede3be3a3f 100644
--- a/tests/acceptance/features/webUIManageUsersGroups/disableUsers.feature
+++ b/tests/acceptance/features/webUIManageUsersGroups/disableUsers.feature
@@ -5,7 +5,7 @@ Feature: disable users
   So that I can remove access to unnecessary users
 
   Background:
-    Given these users have been created with default attributes but not initialized:
+    Given these users have been created with default attributes and skeleton files but not initialized:
       | username |
       | user1    |
       | user2    |
diff --git a/tests/acceptance/features/webUISettingsMenu/settingsMenu.feature b/tests/acceptance/features/webUISettingsMenu/settingsMenu.feature
index 2e42da8ed5fd..b7b8871fc9d9 100644
--- a/tests/acceptance/features/webUISettingsMenu/settingsMenu.feature
+++ b/tests/acceptance/features/webUISettingsMenu/settingsMenu.feature
@@ -5,7 +5,7 @@ Feature: add users
   So that I can see various details about users
 
   Background:
-    Given these users have been created with default attributes but not initialized:
+    Given these users have been created with default attributes and skeleton files but not initialized:
       | username |
       | user1    |
       | user2    |

From 89686fbd0b8919197fba0360c730f3a3faae7b0f Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Fri, 7 Jun 2019 16:06:12 +0545
Subject: [PATCH 090/131] Adjust acceptance test whitespace to match master

---
 tests/acceptance/features/lib/OwncloudPage.php         | 10 +++++-----
 tests/acceptance/features/webUITags/createTags.feature |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/tests/acceptance/features/lib/OwncloudPage.php b/tests/acceptance/features/lib/OwncloudPage.php
index 567fdd4a1d00..2c650f1b4618 100644
--- a/tests/acceptance/features/lib/OwncloudPage.php
+++ b/tests/acceptance/features/lib/OwncloudPage.php
@@ -274,7 +274,7 @@ public function openSettingsMenu(Session $session) {
 		$settingsMenu->waitTillPageIsLoaded($session);
 		return $settingsMenu;
 	}
-	
+
 	/**
 	 * finds the element that contains the displayname of the current user
 	 *
@@ -283,7 +283,7 @@ public function openSettingsMenu(Session $session) {
 	 */
 	protected function findUserDisplayNameElement() {
 		$displayNameElement = $this->findById($this->userNameDisplayId);
-		
+
 		$this->assertElementNotNull(
 			$displayNameElement,
 			__METHOD__ .
@@ -291,7 +291,7 @@ protected function findUserDisplayNameElement() {
 		);
 		return $displayNameElement;
 	}
-	
+
 	/**
 	 * returns the displayname (Full Name or username) of the current user
 	 *
@@ -317,7 +317,7 @@ public function isDisplaynameVisible() {
 	 */
 	protected function findAvatarElement() {
 		$avatarElement = $this->find("xpath", $this->avatarImgXpath);
-		
+
 		$this->assertElementNotNull(
 			$avatarElement,
 			__METHOD__ .
@@ -585,7 +585,7 @@ public function initAjaxCounters(
 		$activeAjaxCountIsUndefined = $session->evaluateScript(
 			"(typeof window.activeAjaxCount === 'undefined')"
 		);
-		
+
 		//only overwrite the send and open functions once
 		if ($activeAjaxCountIsUndefined === true) {
 			$session->executeScript(
diff --git a/tests/acceptance/features/webUITags/createTags.feature b/tests/acceptance/features/webUITags/createTags.feature
index 87905cabcd65..b6a0fbe6f3ac 100644
--- a/tests/acceptance/features/webUITags/createTags.feature
+++ b/tests/acceptance/features/webUITags/createTags.feature
@@ -52,4 +52,4 @@ Feature: Creation of tags for the files and folders
       | tag2 | normal |
     And file "coolnewfile.txt" should have the following tags for user "user2"
       | tag1 | normal |
-      | tag2 | normal |
\ No newline at end of file
+      | tag2 | normal |

From 94ef5c92efa96241bda6871274a82a42ce8ae1dc Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Fri, 7 Jun 2019 16:19:03 +0545
Subject: [PATCH 091/131] Add encryption app comment to cliEncryption in
 behat.yml

---
 tests/acceptance/config/behat.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/acceptance/config/behat.yml b/tests/acceptance/config/behat.yml
index 66abed72c666..0c2fb4d8b411 100644
--- a/tests/acceptance/config/behat.yml
+++ b/tests/acceptance/config/behat.yml
@@ -218,6 +218,7 @@ default:
         - FeatureContext: *common_feature_context_params
         - OccContext:
 
+    # This suite is part of the encryption app in later core versions
     cliEncryption:
       paths:
         - '%paths.base%/../features/cliEncryption'

From 9ae5fe576f9119008b0fe851239579e9a7d9dc1a Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Fri, 7 Jun 2019 10:13:16 +0545
Subject: [PATCH 092/131] federation sharing when the receiver has matching
 file/folder

---
 .../features/apiFederation/federated.feature  | 62 ++++++++++++++++++-
 1 file changed, 61 insertions(+), 1 deletion(-)

diff --git a/tests/acceptance/features/apiFederation/federated.feature b/tests/acceptance/features/apiFederation/federated.feature
index 519f95e57cbc..65b0154369c2 100644
--- a/tests/acceptance/features/apiFederation/federated.feature
+++ b/tests/acceptance/features/apiFederation/federated.feature
@@ -420,4 +420,64 @@ Feature: federated
     Examples:
       | ocs-api-version |
       | 1               |
-      | 2               |
\ No newline at end of file
+      | 2               |
+
+  Scenario Outline: share of a folder to a remote user who already has a folder with the same name
+    Given using server "REMOTE"
+    And user "user0" has created folder "/zzzfolder"
+    And user "user0" has created folder "zzzfolder/user0"
+    And using server "LOCAL"
+    And user "user1" has created folder "/zzzfolder"
+    And user "user1" has created folder "zzzfolder/user1"
+    When user "user0" from server "REMOTE" shares "zzzfolder" with user "user1" from server "LOCAL" using the sharing API
+    And user "user1" from server "LOCAL" has accepted the last pending share
+    And using OCS API version "<ocs-api-version>"
+    When user "user1" retrieves the information of the last federated cloud share using the sharing API
+    Then the OCS status code should be "<ocs-status>"
+    And the HTTP status code should be "200"
+    And the fields of the last response should include
+      | id          | A_NUMBER           |
+      | remote      | REMOTE             |
+      | name        | /zzzfolder         |
+      | owner       | user0              |
+      | user        | user1              |
+      | mountpoint  | /zzzfolder (2)     |
+      | type        | dir                |
+      | permissions | 31                 |
+    And as "user1" folder "zzzfolder/user1" should exist
+    And as "user1" folder "zzzfolder (2)/user0" should exist
+    Examples:
+      | ocs-api-version | ocs-status |
+      | 1               | 100        |
+      | 2               | 200        |
+
+  Scenario Outline: share of a file to the remote user who already has a file with the same name
+    Given using server "REMOTE"
+    And user "user0" has uploaded file with content "remote content" to "/randomfile.txt"
+    And using server "LOCAL"
+    And user "user1" has uploaded file with content "local content" to "/randomfile.txt"
+    When user "user0" from server "REMOTE" shares "/randomfile.txt" with user "user1" from server "LOCAL" using the sharing API
+    And user "user1" from server "LOCAL" has accepted the last pending share
+    And using OCS API version "<ocs-api-version>"
+    When user "user1" retrieves the information of the last federated cloud share using the sharing API
+    Then the OCS status code should be "<ocs-status>"
+    And the HTTP status code should be "200"
+    And the fields of the last response should include
+      | id          | A_NUMBER           |
+      | remote      | REMOTE             |
+      | remote_id   | A_NUMBER           |
+      | share_token | A_TOKEN            |
+      | name        | /randomfile.txt    |
+      | owner       | user0              |
+      | user        | user1              |
+      | mountpoint  | /randomfile (2).txt|
+      | accepted    | 1                  |
+      | type        | file               |
+      | permissions | 27                 |
+    And the content of file "/randomfile.txt" for user "user1" on server "LOCAL" should be "local content"
+    And the content of file "/randomfile (2).txt" for user "user1" on server "LOCAL" should be "remote content"
+    Examples:
+      | ocs-api-version | ocs-status |
+      | 1               | 100        |
+      | 2               | 200        |
+

From bba057b04ccc151e57e33dcbef8e208fe4222e67 Mon Sep 17 00:00:00 2001
From: Artur Neumann <artur@jankaritech.com>
Date: Mon, 10 Jun 2019 16:38:52 +0545
Subject: [PATCH 093/131] skip failing test on ldap and files_primary_s3

---
 .../features/apiShareManagementBasic/createShare.feature         | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/acceptance/features/apiShareManagementBasic/createShare.feature b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
index 56d43781795a..f35bf439d9b2 100644
--- a/tests/acceptance/features/apiShareManagementBasic/createShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
@@ -592,6 +592,7 @@ Feature: sharing
       | 2               | 200             |
 
   @skipOnEncryption @issue-encryption-126
+  @skipOnLDAP @skipOnStorage:ceph @issue-QA-623
   Scenario: share with user when username contains capital letters
     Given these users have been created without skeleton files:
       | username |

From f536c9bed36ae5d14f7d86315b059f66cbd37f60 Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Mon, 10 Jun 2019 16:49:14 +0545
Subject: [PATCH 094/131] webui add remove user to groups not case sensitive

---
 .../features/bootstrap/WebUIUsersContext.php  |  1 +
 .../webUIManageUsersGroups/addGroup.feature   | 31 +++++++++++++++++++
 .../webUIManageUsersGroups/addUsers.feature   | 19 ++++++++++++
 .../webUIManageUsersGroups/editUsers.feature  | 19 ++++++++++++
 .../manageGroups.feature                      | 15 +++++++++
 5 files changed, 85 insertions(+)

diff --git a/tests/acceptance/features/bootstrap/WebUIUsersContext.php b/tests/acceptance/features/bootstrap/WebUIUsersContext.php
index da82f411f7e2..3b1942e511e3 100644
--- a/tests/acceptance/features/bootstrap/WebUIUsersContext.php
+++ b/tests/acceptance/features/bootstrap/WebUIUsersContext.php
@@ -562,6 +562,7 @@ public function restoreScenario(AfterScenarioScope $afterScenarioScope) {
 	 */
 	public function theAdminAddsGroupUsingTheWebUI($groupName) {
 		$this->usersPage->addGroup($groupName, $this->getSession());
+		$this->featureContext->addGroupToCreatedGroupsList($groupName);
 	}
 
 	/**
diff --git a/tests/acceptance/features/webUIManageUsersGroups/addGroup.feature b/tests/acceptance/features/webUIManageUsersGroups/addGroup.feature
index ad18cae8025d..35a0c6f8495d 100644
--- a/tests/acceptance/features/webUIManageUsersGroups/addGroup.feature
+++ b/tests/acceptance/features/webUIManageUsersGroups/addGroup.feature
@@ -14,3 +14,34 @@ Feature: Add group
     Examples:
       | groupname   |
       | "localuser" |
+
+  Scenario Outline: group names are case-sensitive, multiple groups can exist with different upper and lower case names
+    When the administrator adds group "<group_id1>" using the webUI
+    And the administrator adds group "<group_id2>" using the webUI
+    Then the group name "<group_id1>" should be listed on the webUI
+    And the group name "<group_id2>" should be listed on the webUI
+    But the group name "<group_id3>" should not be listed on the webUI
+    And group "<group_id1>" should exist
+    And group "<group_id2>" should exist
+    And group "<group_id3>" should not 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 |
+
+  Scenario Outline: adding a user to a group using mixes of upper and lower case in group names
+    Given user "user0" has been created with default attributes and without skeleton files
+    And group "<group_id1>" has been created
+    And group "<group_id2>" has been created
+    And group "<group_id3>" has been created
+    And the administrator reloads the users page
+    When the administrator adds user "user0" to group "<group_id1>" using the webUI
+    And user "user0" should belong to group "<group_id1>"
+    But user "user0" should not belong to group "<group_id2>"
+    And user "user0" should not belong to group "<group_id3>"
+    Examples:
+      | group_id1 | group_id2 | group_id3 |
+      | Oc-Group  | oc-group  | OC-GROUP  |
+      | oc-group  | OC-GROUP  | Oc-Group  |
+      | OC-GROUp  | Oc-Group  | oc-group  |
\ No newline at end of file
diff --git a/tests/acceptance/features/webUIManageUsersGroups/addUsers.feature b/tests/acceptance/features/webUIManageUsersGroups/addUsers.feature
index 70912c2aba4f..b286f02f48d7 100644
--- a/tests/acceptance/features/webUIManageUsersGroups/addUsers.feature
+++ b/tests/acceptance/features/webUIManageUsersGroups/addUsers.feature
@@ -204,3 +204,22 @@ Feature: add users
     And the user follows the password set link received by "bnu@owncloud" using the webUI
     And the user sets the password to " " and confirms with the same password using the webUI
     Then the user should be redirected to a webUI page with the title "%productname%"
+
+  Scenario Outline: admin creates a user but logs in with different case username
+    When the administrator creates a user with the name "<creation-username>" and the password "password" using the webUI
+    And the administrator logs out of the webUI
+    And the user logs in with username "<login-username>" and password "password" using the webUI
+    Then user "<username>" should exist
+    And the user should be redirected to a webUI page with the title "Files - %productname%"
+    Examples:
+      | creation-username | login-username | username       |
+      | Brand-New-User    | brand-new-user | BRAND-NEW-USER |
+      | brand-new-user    | Brand-New-User | Brand-New-User |
+      | Brand-New-User    | 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 "user1" has been created with default attributes and without skeleton files
+    When the administrator creates a user with the name "USER1" and the password "password" using the webUI
+    Then notifications should be displayed on the webUI with the text
+      | Error creating user: A user with that name already exists. |
diff --git a/tests/acceptance/features/webUIManageUsersGroups/editUsers.feature b/tests/acceptance/features/webUIManageUsersGroups/editUsers.feature
index d35bdaaa8195..a958c5ffdf8d 100644
--- a/tests/acceptance/features/webUIManageUsersGroups/editUsers.feature
+++ b/tests/acceptance/features/webUIManageUsersGroups/editUsers.feature
@@ -91,3 +91,22 @@ Feature: edit users
     When the administrator changes the email of user "user0" to "new_email@oc.com" using the webUI
     Then user "user0" should exist
     And the email address of user "user0" should be "new_email@oc.com"
+
+  Scenario Outline: remove a user from a group using mixes of upper and lower case in group names
+    Given user "user0" has been created with default attributes and without skeleton files
+    And group "<group_id1>" has been created
+    And group "<group_id2>" has been created
+    And group "<group_id3>" has been created
+    And user "user0" has been added to group "<group_id1>"
+    And user "user0" has been added to group "<group_id2>"
+    And user "user0" has been added to group "<group_id3>"
+    And the administrator has browsed to the users page
+    When the administrator removes user "user0" from group "<group_id1>" using the webUI
+    And user "user0" should not belong to group "<group_id1>"
+    But user "user0" should belong to group "<group_id2>"
+    And user "user0" should belong to group "<group_id3>"
+    Examples:
+      | group_id1 | group_id2 | group_id3 |
+      | New-Group | new-group | NEW-GROUP |
+      | new-group | NEW-GROUP | New-Group |
+      | NEW-GROUP | New-Group | new-group |
\ No newline at end of file
diff --git a/tests/acceptance/features/webUIManageUsersGroups/manageGroups.feature b/tests/acceptance/features/webUIManageUsersGroups/manageGroups.feature
index 9cc7bba4ea2d..8584b81765fb 100644
--- a/tests/acceptance/features/webUIManageUsersGroups/manageGroups.feature
+++ b/tests/acceptance/features/webUIManageUsersGroups/manageGroups.feature
@@ -185,3 +185,18 @@ Feature: manage groups
       | quotes"        |
       | do-not-delete2 |
       | a\slash        |
+
+  Scenario Outline: group names are case-sensitive, the correct group is deleted
+    Given group "<group_id1>" has been created
+    And group "<group_id2>" has been created
+    And group "<group_id3>" has been created
+    And the administrator has browsed to the users page
+    When the administrator deletes the group named "<group_id1>" using the webUI and confirms the deletion using the webUI
+    Then group "<group_id1>" should not exist
+    But group "<group_id2>" should exist
+    And group "<group_id3>" should exist
+    Examples:
+      | group_id1            | group_id2            | group_id3 |
+      | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP |
+      | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group |
+      | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group |

From 6a838f448903d19942d42ee30a65cd810b42ac71 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Mon, 10 Jun 2019 19:12:50 +0545
Subject: [PATCH 095/131] Sync user_management acceptance tests in stable10

---
 .../features/bootstrap/WebUIUsersContext.php  | 23 ++++++++++---------
 tests/acceptance/features/lib/UsersPage.php   |  2 +-
 .../webUIManageUsersGroups/addGroup.feature   |  1 +
 .../webUIManageUsersGroups/addUsers.feature   |  2 +-
 .../deleteUsers.feature                       |  2 +-
 .../webUIManageUsersGroups/editUsers.feature  |  2 +-
 .../manageGroups.feature                      |  1 +
 7 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/tests/acceptance/features/bootstrap/WebUIUsersContext.php b/tests/acceptance/features/bootstrap/WebUIUsersContext.php
index 3b1942e511e3..998ad6247b50 100644
--- a/tests/acceptance/features/bootstrap/WebUIUsersContext.php
+++ b/tests/acceptance/features/bootstrap/WebUIUsersContext.php
@@ -27,6 +27,7 @@
 use Behat\MinkExtension\Context\RawMinkContext;
 use Page\LoginPage;
 use Page\UsersPage;
+use PHPUnit\Framework\Assert;
 use TestHelpers\AppConfigHelper;
 
 require_once 'bootstrap.php';
@@ -228,7 +229,7 @@ public function theAdminDeletesDoesNotTheseGroupsUsingTheWebUI(TableNode $table)
 	 */
 	public function theGroupNameShouldBeListed($groupName) {
 		$groups = $this->usersPage->getAllGroups();
-		PHPUnit\Framework\Assert::assertContains(
+		Assert::assertContains(
 			$groupName, $groups, "Expected '" . $groupName . "' does not exist"
 		);
 	}
@@ -241,7 +242,7 @@ public function theGroupNameShouldBeListed($groupName) {
 	 * @return void
 	 */
 	public function theGroupNamedShouldNotBeListedOnTheWebUI($name) {
-		PHPUnit\Framework\Assert::assertFalse(
+		Assert::assertFalse(
 			\in_array($name, $this->usersPage->getAllGroups(), true),
 			"group '" . $name . "' is listed but should not be"
 		);
@@ -262,7 +263,7 @@ public function theseGroupsShouldBeListedOnTheWebUI(
 		$should = ($shouldOrNot !== "not");
 		$groups = $this->usersPage->getAllGroups();
 		foreach ($table as $row) {
-			PHPUnit\Framework\Assert::assertEquals(
+			Assert::assertEquals(
 				\in_array($row['groupname'], $groups, true),
 				$should,
 				"group '" . $row['groupname'] .
@@ -377,7 +378,7 @@ public function enableOrDisableSettings($action, $setting) {
 	 */
 	public function quotaOfUserShouldBeSetToOnTheWebUI($username, $quota) {
 		$setQuota = $this->usersPage->getQuotaOfUser($username);
-		PHPUnit\Framework\Assert::assertEquals(
+		Assert::assertEquals(
 			$quota,
 			$setQuota,
 			'Users quota is set to "' . $setQuota .
@@ -395,7 +396,7 @@ public function quotaOfUserShouldBeSetToOnTheWebUI($username, $quota) {
 	public function theAdministratorShouldBeAbleToSeeEmailOfTheseUsers(TableNode $table) {
 		foreach ($table as $row) {
 			$userEmail = $this->usersPage->getEmailOfUser($row['username']);
-			PHPUnit\Framework\Assert::assertEquals($row['email'], $userEmail);
+			Assert::assertEquals($row['email'], $userEmail);
 		}
 	}
 
@@ -409,7 +410,7 @@ public function theAdministratorShouldBeAbleToSeeEmailOfTheseUsers(TableNode $ta
 	public function theAdministratorShouldBeAbleToSeeQuotaOfTheseUsers(TableNode $table) {
 		foreach ($table as $row) {
 			$visible = $this->usersPage->isQuotaColumnOfUserVisible($row['username']);
-			PHPUnit\Framework\Assert::assertEquals(true, $visible);
+			Assert::assertEquals(true, $visible);
 		}
 	}
 
@@ -423,7 +424,7 @@ public function theAdministratorShouldBeAbleToSeeQuotaOfTheseUsers(TableNode $ta
 	public function theAdministratorShouldNotBeAbleToSeeQuotaOfTheseUsers(TableNode $table) {
 		foreach ($table as $row) {
 			$visible = $this->usersPage->isQuotaColumnOfUserVisible($row['username']);
-			PHPUnit\Framework\Assert::assertEquals(false, $visible);
+			Assert::assertEquals(false, $visible);
 		}
 	}
 
@@ -437,7 +438,7 @@ public function theAdministratorShouldNotBeAbleToSeeQuotaOfTheseUsers(TableNode
 	public function theAdministratorShouldBeAbleToSeePasswordColumnOfTheseUsers(TableNode $table) {
 		foreach ($table as $row) {
 			$visible = $this->usersPage->isPasswordColumnOfUserVisible($row['username']);
-			PHPUnit\Framework\Assert::assertEquals(true, $visible);
+			Assert::assertEquals(true, $visible);
 		}
 	}
 
@@ -451,7 +452,7 @@ public function theAdministratorShouldBeAbleToSeePasswordColumnOfTheseUsers(Tabl
 	public function theAdministratorShouldNotbeAbleToSeePasswordColumnOfTheseUsers(TableNode $table) {
 		foreach ($table as $row) {
 			$visible = $this->usersPage->isPasswordColumnOfUserVisible($row['username']);
-			PHPUnit\Framework\Assert::assertEquals(false, $visible);
+			Assert::assertEquals(false, $visible);
 		}
 	}
 
@@ -467,7 +468,7 @@ public function theAdministratorShouldBeAbleToSeeStorageLocationOfTheseUsers(
 	) {
 		foreach ($table as $row) {
 			$userStorageLocation = $this->usersPage->getStorageLocationOfUser($row['username']);
-			PHPUnit\Framework\Assert::assertContains($row['storage location'], $userStorageLocation);
+			Assert::assertContains($row['storage location'], $userStorageLocation);
 		}
 	}
 
@@ -484,7 +485,7 @@ public function theAdministratorShouldBeAbleToSeeLastLoginOfTheseUsers(
 		foreach ($table as $row) {
 			$userLastLogin = $this->usersPage->getLastLoginOfUser($row['username']);
 
-			PHPUnit\Framework\Assert::assertContains($row['last login'], $userLastLogin);
+			Assert::assertContains($row['last login'], $userLastLogin);
 		}
 	}
 
diff --git a/tests/acceptance/features/lib/UsersPage.php b/tests/acceptance/features/lib/UsersPage.php
index ce8d6eb4e769..99a893e1e597 100644
--- a/tests/acceptance/features/lib/UsersPage.php
+++ b/tests/acceptance/features/lib/UsersPage.php
@@ -738,9 +738,9 @@ public function changeUserPassword(Session $session, $user, $password) {
 		try {
 			$editPasswordInput->focus();
 			$editPasswordInput->setValue($password . "\n");
-			$this->waitForAjaxCallsToStartAndFinish($session);
 		} catch (StaleElementReference $e) {
 		}
+		$this->waitForAjaxCallsToStartAndFinish($session);
 	}
 
 	/**
diff --git a/tests/acceptance/features/webUIManageUsersGroups/addGroup.feature b/tests/acceptance/features/webUIManageUsersGroups/addGroup.feature
index 35a0c6f8495d..9edadc6eb5b1 100644
--- a/tests/acceptance/features/webUIManageUsersGroups/addGroup.feature
+++ b/tests/acceptance/features/webUIManageUsersGroups/addGroup.feature
@@ -11,6 +11,7 @@ Feature: Add group
   Scenario Outline: Add group
     When the administrator adds group <groupname> using the webUI
     Then the group name <groupname> should be listed on the webUI
+    And group <groupname> should exist
     Examples:
       | groupname   |
       | "localuser" |
diff --git a/tests/acceptance/features/webUIManageUsersGroups/addUsers.feature b/tests/acceptance/features/webUIManageUsersGroups/addUsers.feature
index b286f02f48d7..e24f721c5b33 100644
--- a/tests/acceptance/features/webUIManageUsersGroups/addUsers.feature
+++ b/tests/acceptance/features/webUIManageUsersGroups/addUsers.feature
@@ -222,4 +222,4 @@ Feature: add users
     Given user "user1" has been created with default attributes and without skeleton files
     When the administrator creates a user with the name "USER1" and the password "password" using the webUI
     Then notifications should be displayed on the webUI with the text
-      | Error creating user: A user with that name already exists. |
+      | Error creating user: A user with that name already exists. |
\ No newline at end of file
diff --git a/tests/acceptance/features/webUIManageUsersGroups/deleteUsers.feature b/tests/acceptance/features/webUIManageUsersGroups/deleteUsers.feature
index 140c85cd563d..9f6222005a48 100644
--- a/tests/acceptance/features/webUIManageUsersGroups/deleteUsers.feature
+++ b/tests/acceptance/features/webUIManageUsersGroups/deleteUsers.feature
@@ -22,4 +22,4 @@ Feature: delete users
 
   Scenario: use the webUI to cancel deletion of user
     When the administrator deletes user "user1" using the webUI and cancels the deletion using the webUI
-    Then user "user1" should exist
+    Then user "user1" should exist
\ No newline at end of file
diff --git a/tests/acceptance/features/webUIManageUsersGroups/editUsers.feature b/tests/acceptance/features/webUIManageUsersGroups/editUsers.feature
index a958c5ffdf8d..184bcb0c8e27 100644
--- a/tests/acceptance/features/webUIManageUsersGroups/editUsers.feature
+++ b/tests/acceptance/features/webUIManageUsersGroups/editUsers.feature
@@ -109,4 +109,4 @@ Feature: edit users
       | group_id1 | group_id2 | group_id3 |
       | New-Group | new-group | NEW-GROUP |
       | new-group | NEW-GROUP | New-Group |
-      | NEW-GROUP | New-Group | new-group |
\ No newline at end of file
+      | NEW-GROUP | New-Group | new-group |
diff --git a/tests/acceptance/features/webUIManageUsersGroups/manageGroups.feature b/tests/acceptance/features/webUIManageUsersGroups/manageGroups.feature
index 8584b81765fb..f24968df12e7 100644
--- a/tests/acceptance/features/webUIManageUsersGroups/manageGroups.feature
+++ b/tests/acceptance/features/webUIManageUsersGroups/manageGroups.feature
@@ -200,3 +200,4 @@ Feature: manage groups
       | 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 |
+

From 8b4395720ef61872aa135a152bda1b5547a56653 Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Fri, 7 Jun 2019 16:19:03 +0545
Subject: [PATCH 096/131] acceptance test for sharing when the receiver has
 matching file/folder

---
 .../createShare.feature                       | 70 ++++++++++++++++++-
 .../acceptance/features/bootstrap/Sharing.php |  4 +-
 .../shareWithGroups.feature                   |  9 +++
 .../shareWithUsers.feature                    | 32 +++++++++
 4 files changed, 112 insertions(+), 3 deletions(-)

diff --git a/tests/acceptance/features/apiShareManagementBasic/createShare.feature b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
index f35bf439d9b2..361070d54473 100644
--- a/tests/acceptance/features/apiShareManagementBasic/createShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
@@ -649,4 +649,72 @@ Feature: sharing
       | ocs_api_version | ocs_status_code |
       | 1               | 100             |
       | 2               | 200             |
-    
\ No newline at end of file
+
+  Scenario Outline: multiple users share a file with the same name but different permissions to a user
+    Given using OCS API version "<ocs_api_version>"
+    And these users have been created with default attributes and without skeleton files:
+      | username |
+      | user1    |
+      | user2    |
+      | user3    |
+    And user "user2" has uploaded file with content "user2 file" to "/randomfile.txt"
+    And user "user3" has uploaded file with content "user3 file" to "/randomfile.txt"
+    When user "user2" shares file "randomfile.txt" with user "user1" with permissions read using the sharing API
+    And user "user1" gets the info of the last share using the sharing API
+    Then the fields of the last response should include
+      | uid_owner   | user2              |
+      | share_with  | user1              |
+      | file_target | /randomfile.txt|
+      | item_type   | file               |
+      | permissions | 1                  |
+    When user "user3" shares file "randomfile.txt" with user "user1" with permissions update using the sharing API
+    And user "user1" gets the info of the last share using the sharing API
+    Then the fields of the last response should include
+      | uid_owner   | user3              |
+      | share_with  | user1              |
+      | file_target | /randomfile (2).txt|
+      | item_type   | file               |
+      | permissions | 3                  |
+    # Here the last response contains permissions = 3 which is equivalent to permissons: read(1) + update(2)
+    And the content of file "randomfile.txt" for user "user1" should be "user2 file"
+    And the content of file "randomfile (2).txt" for user "user1" should be "user3 file"
+    Examples:
+      | ocs_api_version |
+      | 1               |
+      | 2               |
+
+  Scenario Outline: multiple users share a folder with the same name to a user
+    Given using OCS API version "<ocs_api_version>"
+    And these users have been created with default attributes and without skeleton files:
+      | username |
+      | user1    |
+      | user2    |
+      | user3    |
+    And user "user2" has created folder "/zzzfolder"
+    And user "user2" has created folder "zzzfolder/user2"
+    And user "user3" has created folder "/zzzfolder"
+    And user "user3" has created folder "zzzfolder/user3"
+    When user "user2" shares folder "zzzfolder" with user "user1" with permissions delete using the sharing API
+    And user "user1" gets the info of the last share using the sharing API
+    Then the fields of the last response should include
+      | uid_owner   | user2              |
+      | share_with  | user1              |
+      | file_target | /zzzfolder     |
+      | item_type   | folder             |
+      | permissions | 9                  |
+    # The last response contains permissions = 9 which is equivalent to permissons: read(1) + delete(8)
+    When user "user3" shares folder "zzzfolder" with user "user1" with permissions share using the sharing API
+    And user "user1" gets the info of the last share using the sharing API
+    Then the fields of the last response should include
+      | uid_owner   | user3              |
+      | share_with  | user1              |
+      | file_target | /zzzfolder (2)     |
+      | item_type   | folder             |
+      | permissions | 17                 |
+    # Here the last response has permissions = 9 which is equivalent to permissons: read(1) + share(16)
+    And as "user1" folder "zzzfolder/user2" should exist
+    And as "user1" folder "zzzfolder (2)/user3" should exist
+    Examples:
+      | ocs_api_version |
+      | 1               |
+      | 2               |
\ No newline at end of file
diff --git a/tests/acceptance/features/bootstrap/Sharing.php b/tests/acceptance/features/bootstrap/Sharing.php
index 3d422123e032..b56395bd69d0 100644
--- a/tests/acceptance/features/bootstrap/Sharing.php
+++ b/tests/acceptance/features/bootstrap/Sharing.php
@@ -599,7 +599,7 @@ public function userUpdatesTheLastShareWith($user, $body) {
 	 * @param string $shareWith
 	 * @param string $publicUpload
 	 * @param string $sharePassword
-	 * @param int $permissions
+	 * @param string|int|string[]|int[] $permissions
 	 * @param string $linkName
 	 * @param string $expireDate
 	 *
@@ -819,7 +819,7 @@ public function isUserOrGroupInSharedData($userOrGroup, $permissions = null) {
 	 * @param string $user1
 	 * @param string $filepath
 	 * @param string $user2
-	 * @param int $permissions
+	 * @param string|int|string[]|int[] $permissions
 	 *
 	 * @return void
 	 */
diff --git a/tests/acceptance/features/webUISharingInternalGroups/shareWithGroups.feature b/tests/acceptance/features/webUISharingInternalGroups/shareWithGroups.feature
index 052fca801fc0..72335c54be8f 100644
--- a/tests/acceptance/features/webUISharingInternalGroups/shareWithGroups.feature
+++ b/tests/acceptance/features/webUISharingInternalGroups/shareWithGroups.feature
@@ -205,3 +205,12 @@ Feature: Sharing files and folders with internal groups
       """
       just letting you know that User Three shared lorem.txt with you.
       """
+  Scenario: user added to a group has a share that matches the skeleton of added user
+    Given user "user1" has uploaded file with content "some content" to "lorem.txt"
+    And user "user1" has shared file "lorem.txt" with group "grp1"
+    And user "user3" has been added to group "grp1"
+    When user "user3" logs in using the webUI
+    Then file "lorem.txt" should be listed on the webUI
+    And file "lorem (2).txt" should be listed on the webUI
+    And file "lorem (2).txt" should be marked as shared with "grp1" by "User One" on the webUI
+    And the content of file "lorem (2).txt" for user "user3" should be "some content"
\ No newline at end of file
diff --git a/tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature b/tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature
index 02d0de8214b3..6b0731b1c63c 100644
--- a/tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature
+++ b/tests/acceptance/features/webUISharingInternalUsers/shareWithUsers.feature
@@ -339,3 +339,35 @@ Feature: Sharing files and folders with internal users
     And the user re-logs in as "SomeUser" using the webUI
     And the user browses to the shared-with-you page
     Then file "lorem.txt" should be listed on the webUI
+
+  Scenario: multiple users share a file with the same name to a user
+    Given these users have been created with default attributes and without skeleton files:
+      | username |
+      | user1    |
+      | user2    |
+      | user3    |
+    And user "user2" has uploaded file with content "user2 file" to "/randomfile.txt"
+    And user "user3" has uploaded file with content "user3 file" to "/randomfile.txt"
+    And user "user2" has shared file "randomfile.txt" with user "user1"
+    And user "user3" has shared file "randomfile.txt" with user "user1"
+    When user "user1" logs in using the webUI
+    Then file "randomfile.txt" should be listed on the webUI
+    And the content of file "randomfile.txt" for user "user1" should be "user2 file"
+    And file "randomfile (2).txt" should be listed on the webUI
+    And the content of file "randomfile (2).txt" for user "user1" should be "user3 file"
+
+  Scenario: multiple users share a folder with the same name to a user
+    Given these users have been created with default attributes and without skeleton files:
+      | username |
+      | user1    |
+      | user2    |
+      | user3    |
+    And user "user2" has created folder "/zzzfolder"
+    And user "user3" has created folder "/zzzfolder"
+    And user "user2" has shared folder "zzzfolder" with user "user1"
+    And user "user3" has shared folder "zzzfolder" with user "user1"
+    When user "user1" logs in using the webUI
+    Then folder "zzzfolder" should be listed on the webUI
+    And folder "zzzfolder" should be marked as shared by "User Two" on the webUI
+    And folder "zzzfolder (2)" should be listed on the webUI
+    And folder "zzzfolder (2)" should be marked as shared by "User Three" on the webUI
\ No newline at end of file

From f012e4868c95d53dafebcd7120ab13707315c728 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Tue, 11 Jun 2019 09:34:59 +0545
Subject: [PATCH 097/131] Split addUsers.feature into webUIAddUsers suite

---
 .drone.yml                                        | 14 ++++++++++++++
 tests/acceptance/config/behat.yml                 | 15 +++++++++++++++
 .../addUsers.feature                              |  0
 3 files changed, 29 insertions(+)
 rename tests/acceptance/features/{webUIManageUsersGroups => webUIAddUsers}/addUsers.feature (100%)

diff --git a/.drone.yml b/.drone.yml
index 0920649c5e85..7db638bb3712 100644
--- a/.drone.yml
+++ b/.drone.yml
@@ -1407,6 +1407,20 @@ matrix:
       OWNCLOUD_LOG: true
       INSTALL_TESTING_APP: true
 
+    # This suite is part of the user_management app in later core versions
+    - PHP_VERSION: 7.1
+      TEST_SUITE: selenium
+      BROWSER: chrome
+      BEHAT_SUITE: webUIAddUsers
+      DB_TYPE: mariadb
+      USE_SERVER: true
+      SERVER_PROTOCOL: https
+      INSTALL_SERVER: true
+      CHOWN_SERVER: true
+      USE_EMAIL: true
+      OWNCLOUD_LOG: true
+      INSTALL_TESTING_APP: true
+
     # This suite is part of the user_management app in later core versions
     - PHP_VERSION: 7.1
       TEST_SUITE: selenium
diff --git a/tests/acceptance/config/behat.yml b/tests/acceptance/config/behat.yml
index 0c2fb4d8b411..4bc38f0769ec 100644
--- a/tests/acceptance/config/behat.yml
+++ b/tests/acceptance/config/behat.yml
@@ -533,6 +533,21 @@ default:
         - OccContext:
         - WebDavPropertiesContext:
 
+    # This suite is part of the user_management app in later core versions
+    webUIAddUsers:
+      paths:
+        - '%paths.base%/../features/webUIAddUsers'
+      contexts:
+        - FeatureContext: *common_feature_context_params
+        - EmailContext:
+        - WebDavPropertiesContext:
+        - WebUIFilesContext:
+        - WebUIGeneralContext:
+        - WebUILoginContext:
+        - WebUIPersonalGeneralSettingsContext:
+        - WebUIUsersContext:
+        - WebUIUserContext:
+
     # This suite is part of the user_management app in later core versions
     webUIManageQuota:
       paths:
diff --git a/tests/acceptance/features/webUIManageUsersGroups/addUsers.feature b/tests/acceptance/features/webUIAddUsers/addUsers.feature
similarity index 100%
rename from tests/acceptance/features/webUIManageUsersGroups/addUsers.feature
rename to tests/acceptance/features/webUIAddUsers/addUsers.feature

From baf9a5d62ab91ca56790d9394e3f0cc143e170ad Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Tue, 11 Jun 2019 09:45:47 +0545
Subject: [PATCH 098/131] webui login without skeleton files

---
 tests/acceptance/features/webUILogin/login.feature              | 2 +-
 tests/acceptance/features/webUILogin/resetPassword.feature      | 2 +-
 .../features/webUILogin/resetPasswordUsingEmail.feature         | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/acceptance/features/webUILogin/login.feature b/tests/acceptance/features/webUILogin/login.feature
index 95f31f8d150f..d71e4afb4805 100644
--- a/tests/acceptance/features/webUILogin/login.feature
+++ b/tests/acceptance/features/webUILogin/login.feature
@@ -10,7 +10,7 @@ Feature: login users
 
   @TestAlsoOnExternalUserBackend
   Scenario: simple user login
-    Given these users have been created with default attributes and skeleton files but not initialized:
+    Given these users have been created with default attributes and without skeleton files:
       | username |
       | user1    |
     When user "user1" logs in using the webUI
diff --git a/tests/acceptance/features/webUILogin/resetPassword.feature b/tests/acceptance/features/webUILogin/resetPassword.feature
index f93fb6a6799b..c16dc57742cb 100644
--- a/tests/acceptance/features/webUILogin/resetPassword.feature
+++ b/tests/acceptance/features/webUILogin/resetPassword.feature
@@ -5,7 +5,7 @@ Feature: reset the password
   So that I can login to my account again after forgetting the password
 
   Background:
-    Given these users have been created with default attributes and skeleton files but not initialized:
+    Given these users have been created with default attributes and without skeleton files:
       | username |
       | user1    |
     And the user has browsed to the login page
diff --git a/tests/acceptance/features/webUILogin/resetPasswordUsingEmail.feature b/tests/acceptance/features/webUILogin/resetPasswordUsingEmail.feature
index 6a1814685255..79590e7feb5f 100644
--- a/tests/acceptance/features/webUILogin/resetPasswordUsingEmail.feature
+++ b/tests/acceptance/features/webUILogin/resetPasswordUsingEmail.feature
@@ -5,7 +5,7 @@ Feature: reset the password using an email address
   So that I can login to my account again after forgetting the password
 
   Background:
-    Given these users have been created with default attributes and skeleton files but not initialized:
+    Given these users have been created with default attributes and without skeleton files:
       | username |
       | user1    |
     And the user has browsed to the login page

From dfdc4187e0ca8ee5f3f1a037808d07b572edc301 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Tue, 11 Jun 2019 14:42:03 +0545
Subject: [PATCH 099/131] Fixup check_apache_module_enabled in run.sh

---
 tests/acceptance/run.sh | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/tests/acceptance/run.sh b/tests/acceptance/run.sh
index 9548166d0f10..3f6e28099250 100755
--- a/tests/acceptance/run.sh
+++ b/tests/acceptance/run.sh
@@ -265,8 +265,9 @@ function assert_testing_app_enabled() {
 
 # check if certain apache_module is enabled
 # $1 admin authentication string username:password
-# $2 the full url to the testing app
+# $2 the full url to the testing app on the server to check
 # $3 Module to check for
+# $4 text description of the server being checked, e.g. "local", "remote"
 # return 0 if given module is enabled, else return with 1
 function check_apache_module_enabled() {
 	# test if mod_rewrite is enabled
@@ -274,8 +275,9 @@ function check_apache_module_enabled() {
 	STATUS_CODE=`echo ${CURL_RESULT} | xmllint --xpath "string(ocs/meta/statuscode)" -`
 	if [[ ${STATUS_CODE} -ne 200 ]]
 	then
-		echo -n "Could not reliably determine if '$3' module is enabled, because "
+		echo -n "Could not reliably determine if '$3' module is enabled on the $4 server, because "
 		echo ${CURL_RESULT} | xmllint --xpath "string(ocs/meta/message)" -
+		echo ""
 		return 1
 	fi
 	return 0
@@ -534,7 +536,7 @@ then
 	remote_occ ${ADMIN_AUTH} ${OCC_URL} "maintenance:update:htaccess"
 	[[ $? -eq 0 ]] || { echo "${HTACCESS_UPDATE_FAILURE_MSG}"; }
 	# check if mod_rewrite module is enabled
-	check_apache_module_enabled ${ADMIN_AUTH} ${TESTING_APP_URL} "mod_rewrite"
+	check_apache_module_enabled ${ADMIN_AUTH} ${TESTING_APP_URL} "mod_rewrite" "local"
 
 	if [ -n "${TEST_SERVER_FED_URL}" ]
 	then
@@ -543,7 +545,7 @@ then
 		remote_occ ${ADMIN_AUTH} ${OCC_FED_URL} "maintenance:update:htaccess"
 		[[ $? -eq 0 ]] || { echo "${HTACCESS_UPDATE_FAILURE_MSG/local/federated}"; }
 		# check if mod_rewrite module is enabled
-		check_apache_module_enabled ${ADMIN_AUTH} ${TESTING_APP_URL} "mod_rewrite"
+		check_apache_module_enabled ${ADMIN_AUTH} ${TESTING_APP_FED_URL} "mod_rewrite" "remote"
 	fi
 else
 	echo "Using php inbuilt server for running scenario ..."

From 7915ced89de98905032c72d0044a844ea53b2d7f Mon Sep 17 00:00:00 2001
From: paurakhsharma <paurakh011@gmail.com>
Date: Tue, 11 Jun 2019 15:57:20 +0545
Subject: [PATCH 100/131] add no skeleton steps in webUIRestrictSharing

---
 .../webUIRestrictSharing/disableSharing.feature       |  5 +++--
 .../webUIRestrictSharing/restrictReSharing.feature    |  4 +++-
 .../webUIRestrictSharing/restrictSharing.feature      | 11 +++++++----
 3 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/tests/acceptance/features/webUIRestrictSharing/disableSharing.feature b/tests/acceptance/features/webUIRestrictSharing/disableSharing.feature
index 74148b605049..b83c55ce149c 100644
--- a/tests/acceptance/features/webUIRestrictSharing/disableSharing.feature
+++ b/tests/acceptance/features/webUIRestrictSharing/disableSharing.feature
@@ -5,11 +5,12 @@ Feature: disable sharing
   So that users cannot share files
 
   Background:
-    Given user "user1" has been created with default attributes and skeleton files
+    Given user "user1" has been created with default attributes and without skeleton files
 
   @TestAlsoOnExternalUserBackend
   @smokeTest
   Scenario: Users tries to share via WebUI when Sharing is disabled
-    Given the setting "Allow apps to use the Share API" in the section "Sharing" has been disabled
+    Given user "user1" has created folder "simple-folder"
+    And the setting "Allow apps to use the Share API" in the section "Sharing" has been disabled
     When user "user1" logs in using the webUI
     Then it should not be possible to share folder "simple-folder" using the webUI
diff --git a/tests/acceptance/features/webUIRestrictSharing/restrictReSharing.feature b/tests/acceptance/features/webUIRestrictSharing/restrictReSharing.feature
index b938a687f626..d444e26ee0b9 100644
--- a/tests/acceptance/features/webUIRestrictSharing/restrictReSharing.feature
+++ b/tests/acceptance/features/webUIRestrictSharing/restrictReSharing.feature
@@ -6,7 +6,7 @@ Feature: restrict resharing
   I want to be able to forbid a user that received a share from me to share it further
 
   Background:
-    Given these users have been created with default attributes and skeleton files:
+    Given these users have been created with default attributes and without skeleton files:
       | username |
       | user1    |
       | user2    |
@@ -15,6 +15,8 @@ Feature: restrict resharing
       | grp1      |
     And user "user1" has been added to group "grp1"
     And user "user2" has been added to group "grp1"
+    And user "user1" has created folder "simple-folder"
+    And user "user2" has created folder "simple-folder"
     And user "user2" has logged in using the webUI
 
   @skipOnMICROSOFTEDGE @TestAlsoOnExternalUserBackend
diff --git a/tests/acceptance/features/webUIRestrictSharing/restrictSharing.feature b/tests/acceptance/features/webUIRestrictSharing/restrictSharing.feature
index 271ecf63a7ba..44eddb2eed16 100644
--- a/tests/acceptance/features/webUIRestrictSharing/restrictSharing.feature
+++ b/tests/acceptance/features/webUIRestrictSharing/restrictSharing.feature
@@ -5,18 +5,18 @@ Feature: restrict Sharing
   So that users can only share files with specific users and groups
 
   Background:
-    Given these users have been created with default attributes and skeleton files:
+    Given these users have been created with default attributes and without skeleton files:
       | username |
       | user1    |
       | user2    |
-      | user3    |
     And these groups have been created:
       | groupname |
       | grp1      |
       | grp2      |
     And user "user1" has been added to group "grp1"
     And user "user2" has been added to group "grp1"
-    And user "user3" has been added to group "grp2"
+    And user "user1" has created folder "simple-folder"
+    And user "user2" has created folder "simple-folder"
     And user "user2" has logged in using the webUI
 
   @TestAlsoOnExternalUserBackend
@@ -41,7 +41,10 @@ Feature: restrict Sharing
 
   @TestAlsoOnExternalUserBackend
   Scenario: Do not restrict users to only share with groups they are member of
-    Given the setting "Restrict users to only share with groups they are member of" in the section "Sharing" has been disabled
+    Given user "user3" has been created with default attributes and without skeleton files
+    And user "user3" has been added to group "grp2"
+    And user "user3" has created folder "simple-folder"
+    And the setting "Restrict users to only share with groups they are member of" in the section "Sharing" has been disabled
     And the user browses to the files page
     When the user shares folder "simple-folder" with group "grp2" using the webUI
     And the user re-logs in as "user3" using the webUI

From b81fd51aedfd367fa3e781bcd7acecd65322ae3b Mon Sep 17 00:00:00 2001
From: Artur Neumann <artur@jankaritech.com>
Date: Tue, 11 Jun 2019 18:12:58 +0545
Subject: [PATCH 101/131] fix snakeoil tests

---
 .../createShare.feature                       | 29 +++++++++++--------
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/tests/acceptance/features/apiShareManagementBasic/createShare.feature b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
index 361070d54473..1307285189aa 100644
--- a/tests/acceptance/features/apiShareManagementBasic/createShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
@@ -591,23 +591,26 @@ Feature: sharing
       | 1               | 100             |
       | 2               | 200             |
 
-  @skipOnEncryption @issue-encryption-126
-  @skipOnLDAP @skipOnStorage:ceph @issue-QA-623
+  @issue-35484
   Scenario: share with user when username contains capital letters
     Given these users have been created without skeleton files:
       | username |
       | user1    |
-    When user "user0" shares file "/welcome.txt" with user "USER1" using the sharing API
+    And user "user0" has uploaded file with content "user0 file" to "/randomfile.txt"
+    When user "user0" shares file "/randomfile.txt" with user "USER1" 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 should include
-      | share_with  |  USER1       |
-      | file_target | /welcome.txt |
-      | path        | /welcome.txt |
-      | permissions | 19           |
-      | uid_owner   | user0        |
-    And user "user1" should see the following elements
-      | /welcome.txt |
+      | share_with  | USER1           |
+      | file_target | /randomfile.txt |
+      | path        | /randomfile.txt |
+      | permissions | 19              |
+      | uid_owner   | user0           |
+    #And user "user1" should see the following elements
+    #  | /randomfile.txt |
+    #And the content of file "randomfile.txt" for user "user1" should be "user0 file"
+    And user "user1" should not see the following elements
+      | /randomfile.txt |
 
   Scenario: creating a new share with user of a group when username contains capital letters
     Given these users have been created without skeleton files:
@@ -615,11 +618,13 @@ Feature: sharing
       | user1    |
     And group "grp1" has been created
     And user "USER1" has been added to group "grp1"
-    And user "user0" has shared file "welcome.txt" with group "grp1"
+    And user "user0" has uploaded file with content "user0 file" to "/randomfile.txt"
+    And user "user0" has shared file "randomfile.txt" with group "grp1"
     Then the OCS status code should be "100"
     And the HTTP status code should be "200"
     And user "user1" should see the following elements
-      | /welcome.txt |
+      | /randomfile.txt |
+    And the content of file "randomfile.txt" for user "user1" should be "user0 file"
 
   Scenario Outline: Share of folder to a group with emoji in the name
     Given using OCS API version "<ocs_api_version>"

From 48f500df617ac8e50a556bb20dfb51391f6b0573 Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Tue, 11 Jun 2019 12:08:11 +0545
Subject: [PATCH 102/131] webui rename file without skeleton

---
 .../webUIRenameFiles/renameFiles.feature      | 85 +++++++++++++------
 ...meFilesInsideProblematicFolderName.feature | 18 ++--
 2 files changed, 68 insertions(+), 35 deletions(-)

diff --git a/tests/acceptance/features/webUIRenameFiles/renameFiles.feature b/tests/acceptance/features/webUIRenameFiles/renameFiles.feature
index 293497ee90c8..a494e5fee54d 100644
--- a/tests/acceptance/features/webUIRenameFiles/renameFiles.feature
+++ b/tests/acceptance/features/webUIRenameFiles/renameFiles.feature
@@ -5,23 +5,25 @@ Feature: rename files
   So that I can organise my data structure
 
   Background:
-    Given user "user1" has been created with default attributes and skeleton files
-    And user "user1" has logged in using the webUI
-    And the user has browsed to the files page
+    Given user "user1" has been created with default attributes and without skeleton files
 
   @smokeTest
   Scenario Outline: Rename a file using special characters
-    When the user renames file "lorem.txt" to <to_file_name> using the webUI
+    Given user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And user "user1" has logged in using the webUI
+    When the user renames file "randomfile.txt" to <to_file_name> using the webUI
     Then file <to_file_name> should be listed on the webUI
     When the user reloads the current page of the webUI
     Then file <to_file_name> should be listed on the webUI
     Examples:
       | to_file_name           |
-      | 'लोरेम।तयक्स्त? $%#&@' |
+      | 'लोरेम।तयक्स्त? $%#&@'     |
       | '"quotes1"'            |
       | "'quotes2'"            |
 
   Scenario Outline: Rename a file that has special characters in its name
+    Given user "user1" has uploaded file with content "some content" to <from_name>
+    And user "user1" has logged in using the webUI
     When the user renames file <from_name> to <to_name> using the webUI
     Then file <to_name> should be listed on the webUI
     When the user reloads the current page of the webUI
@@ -33,7 +35,10 @@ Feature: rename files
 
   @smokeTest
   Scenario: Rename a file using special characters and check its existence after page reload
-    When the user renames file "lorem.txt" to "लोरेम।तयक्स्त $%&" using the webUI
+    Given user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And user "user1" has uploaded file with content "more content" to "/zzzz-must-be-last-file-in-folder.txt"
+    And user "user1" has logged in using the webUI
+    When the user renames file "randomfile.txt" to "लोरेम।तयक्स्त $%&" using the webUI
     And the user reloads the current page of the webUI
     Then file "लोरेम।तयक्स्त $%&" should be listed on the webUI
     When the user renames file "लोरेम।तयक्स्त $%&" to '"double"quotes.txt' using the webUI
@@ -50,7 +55,9 @@ Feature: rename files
     Then file "aaaaaa.txt" should be listed on the webUI
 
   Scenario: Rename a file using spaces at front and/or back of file name and type
-    When the user renames file "lorem.txt" to " space at start" using the webUI
+    Given user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And user "user1" has logged in using the webUI
+    When the user renames file "randomfile.txt" to " space at start" using the webUI
     And the user reloads the current page of the webUI
     Then file " space at start" should be listed on the webUI
     When the user renames file " space at start" to "space at end " using the webUI
@@ -70,9 +77,11 @@ Feature: rename files
     Then file "  multiple   space    all     over   .  dat  " should be listed on the webUI
 
   Scenario: Rename a file using both double and single quotes
+    Given user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And user "user1" has logged in using the webUI
     When the user renames the following file using the webUI
       | from-name-parts | to-name-parts         |
-      | lorem.txt       | First 'single' quotes |
+      | randomfile.txt  | First 'single' quotes |
       |                 | -then "double".txt    |
     And the user reloads the current page of the webUI
     Then the following file should be listed on the webUI
@@ -87,51 +96,71 @@ Feature: rename files
     Then file "loremz.dat" should be listed on the webUI
 
   Scenario: Rename a file using forbidden characters
-    When the user renames file "data.zip" to one of these names using the webUI
+    Given user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And user "user1" has logged in using the webUI
+    When the user renames file "randomfile.txt" to one of these names using the webUI
       | lorem\txt |
       | \\.txt    |
       | .htaccess |
     Then notifications should be displayed on the webUI with the text
-      | Could not rename "data.zip" |
-      | Could not rename "data.zip" |
-      | Could not rename "data.zip" |
-    And file "data.zip" should be listed on the webUI
+      | Could not rename "randomfile.txt" |
+      | Could not rename "randomfile.txt" |
+      | Could not rename "randomfile.txt" |
+    And file "randomfile.txt" should be listed on the webUI
 
   Scenario: Rename the last file in a folder
+    Given user "user1" has uploaded file with content "some content" to "/firstfile.txt"
+    And user "user1" has uploaded file with content "more content" to "/zzzz-must-be-last-file-in-folder.txt"
+    And user "user1" has logged in using the webUI
     When the user renames file "zzzz-must-be-last-file-in-folder.txt" to "a-file.txt" using the webUI
     And the user reloads the current page of the webUI
     Then file "a-file.txt" should be listed on the webUI
 
   Scenario: Rename a file to become the last file in a folder
-    When the user renames file "lorem.txt" to "zzzz-z-this-is-now-the-last-file.txt" using the webUI
+    Given user "user1" has uploaded file with content "some content" to "/firstfile.txt"
+    And user "user1" has uploaded file with content "more content" to "/lastfile.txt"
+    And user "user1" has logged in using the webUI
+    When the user renames file "firstfile.txt" to "zzzz-z-this-is-now-the-last-file.txt" using the webUI
     And the user reloads the current page of the webUI
     Then file "zzzz-z-this-is-now-the-last-file.txt" should be listed on the webUI
 
   Scenario: Rename a file putting a name of a file which already exists
-    When the user renames file "data.zip" to "lorem.txt" using the webUI
-    Then near file "data.zip" a tooltip with the text 'lorem.txt already exists' should be displayed on the webUI
+    Given user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And user "user1" has uploaded file with content "another content" to "/anotherfile.txt"
+    And user "user1" has logged in using the webUI
+    When the user renames file "anotherfile.txt" to "randomfile.txt" using the webUI
+    Then near file "anotherfile.txt" a tooltip with the text 'randomfile.txt already exists' should be displayed on the webUI
 
   Scenario: Rename a file to ..
-    When the user renames file "data.zip" to ".." using the webUI
-    Then near file "data.zip" a tooltip with the text '".." is an invalid file name.' should be displayed on the webUI
+    Given user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And user "user1" has logged in using the webUI
+    When the user renames file "randomfile.txt" to ".." using the webUI
+    Then near file "randomfile.txt" a tooltip with the text '".." is an invalid file name.' should be displayed on the webUI
 
   Scenario: Rename a file to .
-    When the user renames file "data.zip" to "." using the webUI
-    Then near file "data.zip" a tooltip with the text '"." is an invalid file name.' should be displayed on the webUI
+    Given user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And user "user1" has logged in using the webUI
+    When the user renames file "randomfile.txt" to "." using the webUI
+    Then near file "randomfile.txt" a tooltip with the text '"." is an invalid file name.' should be displayed on the webUI
 
   Scenario: Rename a file to .part
-    When the user renames file "data.zip" to "data.part" using the webUI
-    Then near file "data.zip" a tooltip with the text '"data.part" has a forbidden file type/extension.' should be displayed on the webUI
+    Given user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And user "user1" has logged in using the webUI
+    When the user renames file "randomfile.txt" to "randomfile.part" using the webUI
+    Then near file "randomfile.txt" a tooltip with the text '"randomfile.part" has a forbidden file type/extension.' should be displayed on the webUI
 
   Scenario: rename a file on a public share
-    Given the user has created a new public link for folder "simple-folder" using the webUI with
+    Given user "user1" has created folder "/FOLDER_TO_SHARE"
+    And user "user1" has uploaded file with content "some content" to "/FOLDER_TO_SHARE/randomfile.txt"
+    And user "user1" has logged in using the webUI
+    And the user has created a new public link for folder "FOLDER_TO_SHARE" using the webUI with
       | permission | read-write |
     When the public accesses the last created public link using the webUI
-    And the user renames file "lorem.txt" to "a-renamed-file.txt" using the webUI
+    And the user renames file "randomfile.txt" to "a-renamed-file.txt" using the webUI
     Then file "a-renamed-file.txt" should be listed on the webUI
-    But file "lorem.txt" should not be listed on the webUI
+    But file "randomfile.txt" should not be listed on the webUI
     When the user reloads the current page of the webUI
     Then file "a-renamed-file.txt" should be listed on the webUI
-    But file "lorem.txt" should not be listed on the webUI
-    And as "user1" file "simple-folder/a-renamed-file.txt" should exist
-    And as "user1" file "simple-folder/lorem.txt" should not exist
+    But file "randomfile.txt" should not be listed on the webUI
+    And as "user1" file "FOLDER_TO_SHARE/a-renamed-file.txt" should exist
+    And as "user1" file "FOLDER_TO_SHARE/randomfile.txt" should not exist
diff --git a/tests/acceptance/features/webUIRenameFiles/renameFilesInsideProblematicFolderName.feature b/tests/acceptance/features/webUIRenameFiles/renameFilesInsideProblematicFolderName.feature
index a2929b6edd2b..8e6bd39ddd74 100644
--- a/tests/acceptance/features/webUIRenameFiles/renameFilesInsideProblematicFolderName.feature
+++ b/tests/acceptance/features/webUIRenameFiles/renameFilesInsideProblematicFolderName.feature
@@ -5,17 +5,21 @@ Feature: Renaming files inside a folder with problematic name
   So that I can recognize my file easily
 
   Background:
-    Given user "user1" has been created with default attributes and skeleton files
+    Given user "user1" has been created with default attributes and without skeleton files
     And user "user1" has logged in using the webUI
 
   Scenario Outline: Rename the existing file inside a problematic folder
-    When the user opens folder <folder> using the webUI
-    And the user renames file "lorem.txt" to "???.txt" using the webUI
+    Given user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And user "user1" has created folder "<folder>"
+    And user "user1" has moved file "/randomfile.txt" to "/<folder>/randomfile.txt"
+    And the user reloads the current page of the webUI
+    When the user opens folder "<folder>" using the webUI
+    And the user renames file "randomfile.txt" to "???.txt" using the webUI
     Then file "???.txt" should be listed on the webUI
     When the user reloads the current page of the webUI
     Then file "???.txt" should be listed on the webUI
     Examples:
-      | folder                  |
-      | "0"                     |
-      | "'single'quotes"        |
-      | "strängé नेपाली folder" |
\ No newline at end of file
+      | folder                |
+      | 0                     |
+      | 'single'quotes        |
+      | strängé नेपाली folder   |
\ No newline at end of file

From 870b64b125bd36301cd336ca4b8c03aa118c63f1 Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Tue, 11 Jun 2019 14:00:27 +0545
Subject: [PATCH 103/131] rename folder without skeleton

---
 .../webUIRenameFolders/renameFolders.feature  | 63 ++++++++++++-------
 1 file changed, 41 insertions(+), 22 deletions(-)

diff --git a/tests/acceptance/features/webUIRenameFolders/renameFolders.feature b/tests/acceptance/features/webUIRenameFolders/renameFolders.feature
index fde71f0d8afe..d0f744f87114 100644
--- a/tests/acceptance/features/webUIRenameFolders/renameFolders.feature
+++ b/tests/acceptance/features/webUIRenameFolders/renameFolders.feature
@@ -5,33 +5,37 @@ Feature: rename folders
   So that I can organise my data structure
 
   Background:
-    Given user "user1" has been created with default attributes and skeleton files
-    And user "user1" has logged in using the webUI
-    And the user has browsed to the files page
+    Given user "user1" has been created with default attributes and without skeleton files
 
   Scenario Outline: Rename a folder using special characters
-    When the user renames folder "simple-folder" to <to_folder_name> using the webUI
+    Given user "user1" has created folder "a-folder"
+    And user "user1" has logged in using the webUI
+    When the user renames folder "a-folder" to <to_folder_name> using the webUI
     Then folder <to_folder_name> should be listed on the webUI
     When the user reloads the current page of the webUI
     Then folder <to_folder_name> should be listed on the webUI
     Examples:
       | to_folder_name          |
-      | 'सिमप्ले फोल्देर$%#?&@' |
+      | 'सिमप्ले फोल्देर$%#?&@'       |
       | '"quotes1"'             |
       | "'quotes2'"             |
 
   Scenario Outline: Rename a folder that has special characters in its name
+    Given user "user1" has created folder <from_name>
+    And user "user1" has logged in using the webUI
     When the user renames folder <from_name> to <to_name> using the webUI
     Then folder <to_name> should be listed on the webUI
     When the user reloads the current page of the webUI
     Then folder <to_name> should be listed on the webUI
     Examples:
       | from_name               | to_name                     |
-      | "strängé नेपाली folder" | "strängé नेपाली folder-#?2" |
+      | "strängé नेपाली folder"   | "strängé नेपाली folder-#?2"   |
       | "'single'quotes"        | "single-quotes"             |
 
   Scenario: Rename a folder using special characters and check its existence after page reload
-    When the user renames folder "simple-folder" to "लोरेम।तयक्स्त $%&" using the webUI
+    Given user "user1" has created folder "a-folder"
+    And user "user1" has logged in using the webUI
+    When the user renames folder "a-folder" to "लोरेम।तयक्स्त $%&" using the webUI
     And the user reloads the current page of the webUI
     Then folder "लोरेम।तयक्स्त $%&" should be listed on the webUI
     When the user renames folder "लोरेम।तयक्स्त $%&" to '"double"quotes' using the webUI
@@ -45,7 +49,9 @@ Feature: rename folders
     Then folder "hash#And&QuestionMark?At@FolderName" should be listed on the webUI
 
   Scenario: Rename a folder using spaces at front and/or back of the name
-    When the user renames folder "simple-folder" to " space at start" using the webUI
+    Given user "user1" has created folder "a-folder"
+    And user "user1" has logged in using the webUI
+    When the user renames folder "a-folder" to " space at start" using the webUI
     And the user reloads the current page of the webUI
     Then folder " space at start" should be listed on the webUI
     When the user renames folder " space at start" to "space at end " using the webUI
@@ -56,9 +62,11 @@ Feature: rename folders
     Then folder "  multiple   spaces    all     over   " should be listed on the webUI
 
   Scenario: Rename a folder using both double and single quotes
+    Given user "user1" has created folder "a-folder"
+    And user "user1" has logged in using the webUI
     When the user renames the following folder using the webUI
       | from-name-parts | to-name-parts         |
-      | simple-folder   | First 'single' quotes |
+      | a-folder   | First 'single' quotes |
       |                 | -then "double"        |
     And the user reloads the current page of the webUI
     Then the following folder should be listed on the webUI
@@ -73,28 +81,39 @@ Feature: rename folders
     Then folder "a normal folder" should be listed on the webUI
 
   Scenario: Rename a folder using forbidden characters
-    When the user renames folder "simple-folder" to one of these names using the webUI
+    Given user "user1" has created folder "a-folder"
+    And user "user1" has logged in using the webUI
+    When the user renames folder "a-folder" to one of these names using the webUI
       | simple\folder   |
       | \\simple-folder |
       | .htaccess       |
     Then notifications should be displayed on the webUI with the text
-      | Could not rename "simple-folder" |
-      | Could not rename "simple-folder" |
-      | Could not rename "simple-folder" |
-    And folder "simple-folder" should be listed on the webUI
+      | Could not rename "a-folder" |
+      | Could not rename "a-folder" |
+      | Could not rename "a-folder" |
+    And folder "a-folder" should be listed on the webUI
 
   Scenario: Rename a folder putting a name of a file which already exists
-    When the user renames folder "simple-folder" to "lorem.txt" using the webUI
-    Then near folder "simple-folder" a tooltip with the text 'lorem.txt already exists' should be displayed on the webUI
+    Given user "user1" has created folder "a-folder"
+    And user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And user "user1" has logged in using the webUI
+    When the user renames folder "a-folder" to "randomfile.txt" using the webUI
+    Then near folder "a-folder" a tooltip with the text 'randomfile.txt already exists' should be displayed on the webUI
 
   Scenario: Rename a folder to ..
-    When the user renames folder "simple-folder" to ".." using the webUI
-    Then near folder "simple-folder" a tooltip with the text '".." is an invalid file name.' should be displayed on the webUI
+    Given user "user1" has created folder "a-folder"
+    And user "user1" has logged in using the webUI
+    When the user renames folder "a-folder" to ".." using the webUI
+    Then near folder "a-folder" a tooltip with the text '".." is an invalid file name.' should be displayed on the webUI
 
   Scenario: Rename a folder to .
-    When the user renames folder "simple-folder" to "." using the webUI
-    Then near folder "simple-folder" a tooltip with the text '"." is an invalid file name.' should be displayed on the webUI
+    Given user "user1" has created folder "a-folder"
+    And user "user1" has logged in using the webUI
+    When the user renames folder "a-folder" to "." using the webUI
+    Then near folder "a-folder" a tooltip with the text '"." is an invalid file name.' should be displayed on the webUI
 
   Scenario: Rename a folder to .part
-    When the user renames folder "simple-folder" to "simple.part" using the webUI
-    Then near folder "simple-folder" a tooltip with the text '"simple.part" has a forbidden file type/extension.' should be displayed on the webUI
+    Given user "user1" has created folder "a-folder"
+    And user "user1" has logged in using the webUI
+    When the user renames folder "a-folder" to "a.part" using the webUI
+    Then near folder "a-folder" a tooltip with the text '"a.part" has a forbidden file type/extension.' should be displayed on the webUI

From bb44199b97db74caec4be84fa2b48f3602c0c9b2 Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Wed, 12 Jun 2019 10:09:39 +0545
Subject: [PATCH 104/131] webui tag operations without skeleton

---
 .../features/webUITags/createTags.feature     | 48 +++++-----
 .../features/webUITags/deleteTags.feature     | 91 ++++++++++---------
 .../features/webUITags/editTags.feature       | 34 +++----
 .../features/webUITags/removeTags.feature     | 73 ++++++++-------
 .../features/webUITags/tagsSuggestion.feature | 10 +-
 5 files changed, 141 insertions(+), 115 deletions(-)

diff --git a/tests/acceptance/features/webUITags/createTags.feature b/tests/acceptance/features/webUITags/createTags.feature
index b6a0fbe6f3ac..7b1b2f1df325 100644
--- a/tests/acceptance/features/webUITags/createTags.feature
+++ b/tests/acceptance/features/webUITags/createTags.feature
@@ -5,51 +5,57 @@ Feature: Creation of tags for the files and folders
   So that I can find them easily
 
   Background:
-    Given these users have been created with default attributes and skeleton files:
+    Given these users have been created with default attributes and without skeleton files:
       | username |
       | user1    |
     And the user has browsed to the login page
     And the user has logged in with username "user1" and password "%alt1%" using the webUI
 
   Scenario: Create a new tag that does not exist for a file in the root
-    When the user browses directly to display the details of file "lorem.txt" in folder "/"
+    Given user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    When the user browses directly to display the details of file "randomfile.txt" in folder "/"
     And the user adds a tag "Top Secret" to the file using the webUI
     And the user adds a tag "Confidential" to the file using the webUI
-    Then file "/lorem.txt" should have the following tags for user "user1"
+    Then file "/randomfile.txt" should have the following tags for user "user1"
       | Top Secret   | normal |
       | Confidential | normal |
 
   Scenario: Create a new tag that does not exist for a file in a folder
-    When the user browses directly to display the details of file "lorem.txt" in folder "simple-folder"
+    Given user "user1" has created folder "a-folder"
+    And user "user1" has uploaded file with content "some content" to "/a-folder/randomfile.txt"
+    When the user browses directly to display the details of file "randomfile.txt" in folder "a-folder"
     And the user adds a tag "Top Secret" to the file using the webUI
     And the user adds a tag "Top" to the file using the webUI
-    Then file "simple-folder/lorem.txt" should have the following tags for user "user1"
+    Then file "a-folder/randomfile.txt" should have the following tags for user "user1"
       | Top Secret | normal |
       | Top        | normal |
 
   Scenario: Add a new tag that already exists for a file in a folder
-    Given the user has browsed directly to display the details of file "lorem.txt" in folder "simple-folder"
-    And the user has added a tag "lorem" to the file using the webUI
-    When the user browses directly to display the details of file "lorem-big.txt" in folder "simple-folder"
-    And the user adds a tag "lorem" to the file using the webUI
-    Then file "simple-folder/lorem.txt" should have the following tags for user "user1"
-      | lorem | normal |
-    And file "simple-folder/lorem-big.txt" should have the following tags for user "user1"
-      | lorem | normal |
+    Given user "user1" has created folder "a-folder"
+    And user "user1" has uploaded file with content "some content" to "/a-folder/randomfile.txt"
+    And user "user1" has uploaded file with content "some content" to "/a-folder/randomfile-big.txt"
+    And the user has browsed directly to display the details of file "randomfile.txt" in folder "a-folder"
+    And the user has added a tag "randomfile" to the file using the webUI
+    When the user browses directly to display the details of file "randomfile-big.txt" in folder "a-folder"
+    And the user adds a tag "randomfile" to the file using the webUI
+    Then file "a-folder/randomfile.txt" should have the following tags for user "user1"
+      | randomfile | normal |
+    And file "a-folder/randomfile-big.txt" should have the following tags for user "user1"
+      | randomfile | normal |
 
   @skipOnFIREFOX
   Scenario: Create and add tag on a shared file
-    Given user "user2" has been created with default attributes and skeleton files
-    When the user renames file "lorem.txt" to "coolnewfile.txt" using the webUI
-    And the user browses directly to display the details of file "coolnewfile.txt" in folder ""
-    And the user adds a tag "tag1" to the file using the webUI
-    And the user shares file "coolnewfile.txt" with user "User Two" using the webUI
+    Given user "user2" has been created with default attributes and without skeleton files
+    And user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And the user browses directly to display the details of file "randomfile.txt" in folder ""
+    When the user adds a tag "tag1" to the file using the webUI
+    And the user shares file "randomfile.txt" with user "User Two" using the webUI
     And the user re-logs in with username "user2" and password "%alt2%" using the webUI
-    And the user browses directly to display the details of file "coolnewfile.txt" in folder ""
+    And the user browses directly to display the details of file "randomfile.txt" in folder ""
     And the user adds a tag "tag2" to the file using the webUI
-    Then file "coolnewfile.txt" should have the following tags for user "user1"
+    Then file "randomfile.txt" should have the following tags for user "user1"
       | tag1 | normal |
       | tag2 | normal |
-    And file "coolnewfile.txt" should have the following tags for user "user2"
+    And file "randomfile.txt" should have the following tags for user "user2"
       | tag1 | normal |
       | tag2 | normal |
diff --git a/tests/acceptance/features/webUITags/deleteTags.feature b/tests/acceptance/features/webUITags/deleteTags.feature
index b10c5fc3c93d..1b28d230f010 100644
--- a/tests/acceptance/features/webUITags/deleteTags.feature
+++ b/tests/acceptance/features/webUITags/deleteTags.feature
@@ -5,7 +5,7 @@ Feature: Deletion of existing tags from files and folders
   So that I can keep my filing system clean and tidy
 
   Background:
-    Given these users have been created with default attributes and skeleton files:
+    Given these users have been created with default attributes and without skeleton files:
       | username |
       | user1    |
     And the user has browsed to the login page
@@ -13,67 +13,74 @@ Feature: Deletion of existing tags from files and folders
 
 @skipOnFIREFOX
   Scenario: Delete a tag in a shared file
-    Given user "user2" has been created with default attributes and skeleton files
-    When the user renames file "lorem.txt" to "coolnewfile.txt" using the webUI
-    And the user browses directly to display the details of file "coolnewfile.txt" in folder ""
-    And the user adds a tag "tag1" to the file using the webUI
-    And the user shares file "coolnewfile.txt" with user "User Two" using the webUI
+    Given user "user2" has been created with default attributes and without skeleton files
+    And user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And the user browses directly to display the details of file "randomfile.txt" in folder ""
+    When the user adds a tag "tag1" to the file using the webUI
+    And the user shares file "randomfile.txt" with user "User Two" using the webUI
     And the user re-logs in with username "user2" and password "%alt2%" using the webUI
-    Then file "coolnewfile.txt" should have the following tags for user "user2"
+    Then file "randomfile.txt" should have the following tags for user "user2"
     | tag1 | normal |
-    When the user browses directly to display the details of file "coolnewfile.txt" in folder ""
+    When the user browses directly to display the details of file "randomfile.txt" in folder ""
     And the user deletes tag with name "tag1" using the webUI
     Then tag "tag1" should not exist for user "user1"
     And tag "tag1" should not exist for user "user2"
 
   Scenario: Delete a tag that already exists for a file in the root
-    Given the user has created a "normal" tag with name "lorem"
-    And the user has added tag "lorem" to file "lorem.txt"
-    When the user browses directly to display the details of file "lorem.txt" in folder "/"
-    Then file "lorem.txt" should have the following tags for user "user1"
-      | lorem | normal |
-    When the user deletes tag with name "lorem" using the webUI
-    Then tag "lorem" should not exist for user "user1"
+    Given user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And the user has created a "normal" tag with name "random"
+    And the user has added tag "random" to file "randomfile.txt"
+    When the user browses directly to display the details of file "randomfile.txt" in folder "/"
+    Then file "randomfile.txt" should have the following tags for user "user1"
+      | random | normal |
+    When the user deletes tag with name "random" using the webUI
+    Then tag "random" should not exist for user "user1"
 
   Scenario: Delete a tag that already exists for a file in a folder
-    Given the user has created a "normal" tag with name "lorem"
-    And the user has added tag "lorem" to file "simple-folder/lorem.txt"
-    When the user browses directly to display the details of file "lorem.txt" in folder "simple-folder"
-    Then file "simple-folder/lorem.txt" should have the following tags for user "user1"
-      | lorem | normal |
-    When the user deletes tag with name "lorem" using the webUI
-    Then tag "lorem" should not exist for user "user1"
+    Given user "user1" has created folder "a-folder"
+    And user "user1" has uploaded file with content "some content" to "/a-folder/randomfile.txt"
+    And the user has created a "normal" tag with name "random"
+    And the user has added tag "random" to file "a-folder/randomfile.txt"
+    When the user browses directly to display the details of file "randomfile.txt" in folder "a-folder"
+    Then file "a-folder/randomfile.txt" should have the following tags for user "user1"
+      | random | normal |
+    When the user deletes tag with name "random" using the webUI
+    Then tag "random" should not exist for user "user1"
 
   Scenario: Delete a tag that exists for multiple file
-    Given the user has created a "normal" tag with name "lorem"
-    And the user has added tag "lorem" to file "lorem.txt"
-    And the user has added tag "lorem" to file "lorem-big.txt"
-    And the user has browsed directly to display the details of file "lorem.txt" in folder "simple-folder"
-    When the user deletes tag with name "lorem" using the webUI
-    Then tag "lorem" should not exist for user "user1"
+    Given user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And user "user1" has uploaded file with content "more content" to "/randomfile-big.txt"
+    And the user has created a "normal" tag with name "random"
+    And the user has added tag "random" to file "randomfile.txt"
+    And the user has added tag "random" to file "randomfile-big.txt"
+    And the user has browsed directly to display the details of file "randomfile.txt" in folder ""
+    When the user deletes tag with name "random" using the webUI
+    Then tag "random" should not exist for user "user1"
 
   Scenario: Delete all tags that exist for a file
-    Given the user has created a "normal" tag with name "lorem"
+    Given user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And the user has created a "normal" tag with name "random"
     And the user has created a "normal" tag with name "Confidential"
-    And the user has added tag "lorem" to file "lorem.txt"
-    And the user has added tag "Confidential" to file "lorem.txt"
-    And the user has browsed directly to display the details of file "lorem.txt" in folder "/"
-    When the user deletes tag with name "lorem" using the webUI
+    And the user has added tag "random" to file "randomfile.txt"
+    And the user has added tag "Confidential" to file "randomfile.txt"
+    And the user has browsed directly to display the details of file "randomfile.txt" in folder "/"
+    When the user deletes tag with name "random" using the webUI
     And the user deletes tag with name "Confidential" using the webUI
-    Then file "lorem.txt" should have no tags for user "user1"
+    Then file "randomfile.txt" should have no tags for user "user1"
 
   Scenario: Delete multiple tags that exist for a file
-    Given the user has created a "normal" tag with name "lorem"
+    Given user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And the user has created a "normal" tag with name "random"
     And the user has created a "normal" tag with name "Confidential"
     And the user has created a "normal" tag with name "some-tag"
-    And the user has added tag "lorem" to file "lorem.txt"
-    And the user has added tag "Confidential" to file "lorem.txt"
-    And the user has added tag "some-tag" to file "lorem.txt"
-    And the user has browsed directly to display the details of file "lorem.txt" in folder "/"
-    When the user deletes tag with name "lorem" using the webUI
+    And the user has added tag "random" to file "randomfile.txt"
+    And the user has added tag "Confidential" to file "randomfile.txt"
+    And the user has added tag "some-tag" to file "randomfile.txt"
+    And the user has browsed directly to display the details of file "randomfile.txt" in folder "/"
+    When the user deletes tag with name "random" using the webUI
     And the user deletes tag with name "Confidential" using the webUI
-    Then tag "lorem" should not exist for user "user1"
+    Then tag "random" should not exist for user "user1"
     And tag "Confidential" should not exist for user "user1"
-    And file "/lorem.txt" should have the following tags for user "user1"
+    And file "/randomfile.txt" should have the following tags for user "user1"
       | some-tag | normal |
 
diff --git a/tests/acceptance/features/webUITags/editTags.feature b/tests/acceptance/features/webUITags/editTags.feature
index 193497421de5..6d43545d5ded 100644
--- a/tests/acceptance/features/webUITags/editTags.feature
+++ b/tests/acceptance/features/webUITags/editTags.feature
@@ -5,7 +5,7 @@ Feature: Edit tags for files and folders
   So that I can find them easily
 
   Background:
-    Given these users have been created with default attributes and skeleton files:
+    Given these users have been created with default attributes and without skeleton files:
       | username |
       | user1    |
       | user2    |
@@ -13,24 +13,26 @@ Feature: Edit tags for files and folders
     And the user has logged in with username "user1" and password "%alt1%" using the webUI
 
   Scenario: Change the name of a tag that already exists for a file
-    Given the user has created a "normal" tag with name "lorem"
-    And the user has added tag "lorem" to file "lorem.txt"
-    When the user browses directly to display the details of file "lorem.txt" in folder "/"
-    And the user edits the tag with name "lorem" and sets its name to "lorem-big" using the webUI
-    Then file "lorem.txt" should have the following tags for user "user1"
-      | lorem-big  | normal |
-    And tag "lorem" should not exist for the user
+    Given user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And the user has created a "normal" tag with name "random"
+    And the user has added tag "random" to file "randomfile.txt"
+    When the user browses directly to display the details of file "randomfile.txt" in folder "/"
+    And the user edits the tag with name "random" and sets its name to "random-big" using the webUI
+    Then file "randomfile.txt" should have the following tags for user "user1"
+      | random-big  | normal |
+    And tag "random" should not exist for the user
 
   Scenario: Change the name of multiple tags that exist for a file
-    Given the user has created a "normal" tag with name "lorem"
+    Given user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And the user has created a "normal" tag with name "random"
     And the user has created a "normal" tag with name "some-tag"
-    And the user has added tag "lorem" to file "lorem.txt"
-    And the user has added tag "some-tag" to file "lorem.txt"
-    When the user browses directly to display the details of file "lorem.txt" in folder "/"
-    And the user edits the tag with name "lorem" and sets its name to "lorem-big" using the webUI
+    And the user has added tag "random" to file "randomfile.txt"
+    And the user has added tag "some-tag" to file "randomfile.txt"
+    When the user browses directly to display the details of file "randomfile.txt" in folder "/"
+    And the user edits the tag with name "random" and sets its name to "random-big" using the webUI
     And the user edits the tag with name "some-tag" and sets its name to "another-tag" using the webUI
-    Then file "lorem.txt" should have the following tags for user "user1"
-      |  lorem-big  | normal |
+    Then file "randomfile.txt" should have the following tags for user "user1"
+      |  random-big  | normal |
       | another-tag | normal |
-    And tag "lorem" should not exist for the user
+    And tag "random" should not exist for the user
     And tag "some-tag" should not exist for the user
\ No newline at end of file
diff --git a/tests/acceptance/features/webUITags/removeTags.feature b/tests/acceptance/features/webUITags/removeTags.feature
index b5b773ca6250..927dfe06a46e 100644
--- a/tests/acceptance/features/webUITags/removeTags.feature
+++ b/tests/acceptance/features/webUITags/removeTags.feature
@@ -5,39 +5,43 @@ Feature: Removal of already existing tags from files and folders
   So that I can properly organize my filing system
 
   Background:
-    Given these users have been created with default attributes and skeleton files:
+    Given these users have been created with default attributes and without skeleton files:
       | username |
       | user1    |
-      | user2    |
     And the user has browsed to the login page
     And the user has logged in with username "user1" and password "%alt1%" using the webUI
 
   Scenario: Remove a tag that already exists for a file in a folder
-    Given the user has browsed directly to display the details of file "lorem.txt" in folder "simple-folder"
-    And the user has added a tag "lorem" to the file using the webUI
-    When the user browses directly to display the details of file "lorem.txt" in folder "simple-folder"
-    And the user toggles a tag "lorem" on the file using the webUI
-    Then file "simple-folder/lorem.txt" should have no tags for user "user1"
+    Given user "user1" has created folder "a-folder"
+    And user "user1" has uploaded file with content "some content" to "/a-folder/randomfile.txt"
+    And the user has created a "normal" tag with name "random"
+    And the user has added tag "random" to file "a-folder/randomfile.txt"
+    When the user browses directly to display the details of file "randomfile.txt" in folder "a-folder"
+    And the user toggles a tag "random" on the file using the webUI
+    Then file "a-folder/randomfile.txt" should have no tags for user "user1"
 
   Scenario: Remove a tag that already exists for a file in the root
-    Given the user has browsed directly to display the details of file "lorem.txt" in folder "/"
-    And the user has added a tag "lorem" to the file using the webUI
-    When the user browses directly to display the details of file "lorem.txt" in folder "/"
-    And the user toggles a tag "lorem" on the file using the webUI
-    Then file "lorem.txt" should have no tags for user "user1"
+    Given user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And the user has created a "normal" tag with name "random"
+    And the user has added tag "random" to file "randomfile.txt"
+    When the user browses directly to display the details of file "randomfile.txt" in folder "/"
+    And the user toggles a tag "random" on the file using the webUI
+    Then file "randomfile.txt" should have no tags for user "user1"
 
   Scenario: Remove all tags that already exist for a file
-    Given the user has created a "normal" tag with name "lorem"
+    Given user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And the user has created a "normal" tag with name "random"
     And the user has created a "normal" tag with name "Confidential"
-    And the user has added tag "lorem" to file "lorem.txt"
-    And the user has added tag "Confidential" to file "lorem.txt"
-    When the user browses directly to display the details of file "lorem.txt" in folder "/"
-    And the user toggles a tag "lorem" on the file using the webUI
+    And the user has added tag "random" to file "randomfile.txt"
+    And the user has added tag "Confidential" to file "randomfile.txt"
+    When the user browses directly to display the details of file "randomfile.txt" in folder "/"
+    And the user toggles a tag "random" on the file using the webUI
     And the user toggles a tag "Confidential" on the file using the webUI
-    Then file "lorem.txt" should have no tags for user "user1"
+    Then file "randomfile.txt" should have no tags for user "user1"
 
   Scenario: Shared user removes a tag in shared file
-    Given the user has created a "normal" tag with name "tag1"
+    Given user "user2" has been created with default attributes and without skeleton files
+    And the user has created a "normal" tag with name "tag1"
     And user "user1" has uploaded file with content "does-not-matter" to "/coolnewfile.txt"
     And the user has added tag "tag1" to file "coolnewfile.txt"
     And the user has shared file "coolnewfile.txt" with user "user2"
@@ -50,7 +54,8 @@ Feature: Removal of already existing tags from files and folders
     And file "coolnewfile.txt" should have no tags for user "user1"
 
   Scenario: Sharer removes a tag in shared file
-    Given the user has created a "normal" tag with name "tag1"
+    Given user "user2" has been created with default attributes and without skeleton files
+    And the user has created a "normal" tag with name "tag1"
     And user "user1" has uploaded file with content "does-not-matter" to "/coolnewfile.txt"
     And the user has added tag "tag1" to file "coolnewfile.txt"
     And the user has shared file "coolnewfile.txt" with user "user2"
@@ -64,23 +69,25 @@ Feature: Removal of already existing tags from files and folders
     And file "coolnewfile.txt" should have no tags for user "user1"
 
   Scenario: Remove multiple tags that exist for a file
-    Given the user has created a "normal" tag with name "lorem"
+    Given user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And the user has created a "normal" tag with name "random"
     And the user has created a "normal" tag with name "Confidential"
     And the user has created a "normal" tag with name "some-tag"
-    And the user has added tag "lorem" to file "lorem.txt"
-    And the user has added tag "Confidential" to file "lorem.txt"
-    And the user has added tag "some-tag" to file "lorem.txt"
-    When the user browses directly to display the details of file "lorem.txt" in folder "/"
-    And the user toggles a tag "lorem" on the file using the webUI
+    And the user has added tag "random" to file "randomfile.txt"
+    And the user has added tag "Confidential" to file "randomfile.txt"
+    And the user has added tag "some-tag" to file "randomfile.txt"
+    When the user browses directly to display the details of file "randomfile.txt" in folder "/"
+    And the user toggles a tag "random" on the file using the webUI
     And the user toggles a tag "Confidential" on the file using the webUI
-    Then file "lorem.txt" should have the following tags for user "user1"
+    Then file "randomfile.txt" should have the following tags for user "user1"
       | some-tag | normal |
 
   Scenario: Remove a tag from a file and assign another tag
-    Given the user has created a "normal" tag with name "lorem"
-    And the user has added tag "lorem" to file "lorem.txt"
-    When the user browses directly to display the details of file "lorem.txt" in folder "/"
-    And the user toggles a tag "lorem" on the file using the webUI
+    Given user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And the user has created a "normal" tag with name "random"
+    And the user has added tag "random" to file "randomfile.txt"
+    When the user browses directly to display the details of file "randomfile.txt" in folder "/"
+    And the user toggles a tag "random" on the file using the webUI
     And the user adds a tag "some-tag" to the file using the webUI
-    Then file "lorem.txt" should have the following tags for user "user1"
-      | some-tag | normal |
+    Then file "randomfile.txt" should have the following tags for user "user1"
+      | some-tag | normal |
\ No newline at end of file
diff --git a/tests/acceptance/features/webUITags/tagsSuggestion.feature b/tests/acceptance/features/webUITags/tagsSuggestion.feature
index 7991fbd6e197..cca3ac62518c 100644
--- a/tests/acceptance/features/webUITags/tagsSuggestion.feature
+++ b/tests/acceptance/features/webUITags/tagsSuggestion.feature
@@ -5,7 +5,7 @@ Feature: Suggestion for matching tag names
   So that I can easily categorize the files
 
   Background:
-    Given these users have been created with default attributes and skeleton files:
+    Given these users have been created with default attributes and without skeleton files:
       | username |
       | user1    |
     Given user "user1" has created a "normal" tag with name "spam"
@@ -21,7 +21,9 @@ Feature: Suggestion for matching tag names
     And user "user1" has logged in using the webUI
 
   Scenario: User should get suggestion from already existing tags
-    When the user browses directly to display the details of file "lorem.txt" in folder "simple-folder"
+    Given user "user1" has created folder "a-folder"
+    And user "user1" has uploaded file with content "some content" to "/a-folder/randomfile.txt"
+    When the user browses directly to display the details of file "randomfile.txt" in folder "a-folder"
     And the user types "sp" in the collaborative tags field using the webUI
     Then all the tags starting with "sp" in their name should be listed in the dropdown list on the webUI
     But tag "gham" should not be listed in the dropdown list on the webUI
@@ -30,7 +32,9 @@ Feature: Suggestion for matching tag names
     And tag "sponsored" should not be listed in the dropdown list on the webUI
 
   Scenario: User of static tags group should get suggestion for static tags
-    When the user browses directly to display the details of file "lorem.txt" in folder "simple-folder"
+    Given user "user1" has created folder "a-folder"
+    And user "user1" has uploaded file with content "some content" to "/a-folder/randomfile.txt"
+    When the user browses directly to display the details of file "randomfile.txt" in folder "a-folder"
     And the administrator has created a "static" tag with name "StaticTagName" and groups "group1"
     And the user types "St" in the collaborative tags field using the webUI
     Then all the tags starting with "St" in their name should be listed in the dropdown list on the webUI

From fb21daf6598c1a98fb07a9e38ec82234299efa82 Mon Sep 17 00:00:00 2001
From: paurakhsharma <paurakh011@gmail.com>
Date: Wed, 12 Jun 2019 14:51:05 +0545
Subject: [PATCH 105/131] webUIComments without skeleton

---
 tests/acceptance/features/webUIComments/comments.feature | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tests/acceptance/features/webUIComments/comments.feature b/tests/acceptance/features/webUIComments/comments.feature
index 53f5cc5d77c5..dee14d35ac5a 100644
--- a/tests/acceptance/features/webUIComments/comments.feature
+++ b/tests/acceptance/features/webUIComments/comments.feature
@@ -6,10 +6,11 @@ Feature: Add, delete and edit comments in files and folders
   So that I can provide more information about the file/folder
 
   Background:
-    Given these users have been created with default attributes and skeleton files:
+    Given these users have been created with default attributes and without skeleton files:
       | username |
       | user1    |
       | user2    |
+    And user "user1" has uploaded file with content "does-not-matter" to "/lorem.txt"
     And user "user1" has logged in using the webUI
     And the user has browsed to the files page
 

From 17794ddabe352ba80d71bb6ba691d037b4756e6b Mon Sep 17 00:00:00 2001
From: paurakhsharma <paurakh011@gmail.com>
Date: Wed, 12 Jun 2019 15:37:23 +0545
Subject: [PATCH 106/131] Use no skeleton on webUIComments

---
 .../webUIFavorites/favoritesFile.feature      | 20 +++++++++++++------
 .../webUIFavorites/unfavoriteFile.feature     |  8 +++++---
 2 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/tests/acceptance/features/webUIFavorites/favoritesFile.feature b/tests/acceptance/features/webUIFavorites/favoritesFile.feature
index dcfbd85f7c43..2a118f9384eb 100644
--- a/tests/acceptance/features/webUIFavorites/favoritesFile.feature
+++ b/tests/acceptance/features/webUIFavorites/favoritesFile.feature
@@ -5,13 +5,13 @@ Feature: Mark file as favorite
   I would like to mark any file/folder as favorite
   So that I can find my favorite file/folder easily
 
-  Background:
-    Given user "user1" has been created with default attributes and skeleton files
-    And user "user1" has logged in using the webUI
-    And the user has browsed to the files page
-
   @smokeTest
   Scenario: mark a file as favorite and list it in favorites page
+    Given user "user1" has been created with default attributes and without skeleton files
+    And user "user1" has uploaded file "filesForUpload/data.zip" to "/data.zip"
+    And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt"
+    And user "user1" has logged in using the webUI
+    And the user has browsed to the files page
     When the user marks file "data.zip" as favorite using the webUI
     Then file "data.zip" should be marked as favorite on the webUI
     When the user reloads the current page of the webUI
@@ -20,6 +20,11 @@ Feature: Mark file as favorite
     And file "lorem.txt" should not be listed in the favorites page on the webUI
 
   Scenario: mark a folder as favorite and list it in favorites page
+    Given user "user1" has been created with default attributes and without skeleton files
+    And user "user1" has created folder "/simple-folder"
+    And user "user1" has created folder "/simple-folder/simple-empty-folder"
+    And user "user1" has logged in using the webUI
+    And the user has browsed to the files page
     When the user marks folder "simple-folder" as favorite using the webUI
     Then folder "simple-folder" should be marked as favorite on the webUI
     When the user reloads the current page of the webUI
@@ -28,6 +33,9 @@ Feature: Mark file as favorite
     And folder "simple-empty-folder" should not be listed in the favorites page on the webUI
 
   Scenario: mark files with same name and different path as favorites and list them in favourites page
+    Given user "user1" has been created with default attributes and skeleton files
+    And user "user1" has logged in using the webUI
+    And the user has browsed to the files page
     When the user marks file "lorem.txt" as favorite using the webUI
     And the user marks folder "simple-empty-folder" as favorite using the webUI
     And the user opens folder "simple-folder" using the webUI
@@ -40,4 +48,4 @@ Feature: Mark file as favorite
     And file "lorem.txt" with path "/simple-folder" should be listed in the favorites page on the webUI
     And folder "simple-empty-folder" with path "/" should be listed in the favorites page on the webUI
     And file "simple-empty-folder" with path "/simple-folder" should be listed in the favorites page on the webUI
-    And file "lorem.txt" with path "/strängé नेपाली folder" should be listed in the favorites page on the webUI
\ No newline at end of file
+    And file "lorem.txt" with path "/strängé नेपाली folder" should be listed in the favorites page on the webUI
diff --git a/tests/acceptance/features/webUIFavorites/unfavoriteFile.feature b/tests/acceptance/features/webUIFavorites/unfavoriteFile.feature
index 4b6adc33e2b2..7a7d92428684 100644
--- a/tests/acceptance/features/webUIFavorites/unfavoriteFile.feature
+++ b/tests/acceptance/features/webUIFavorites/unfavoriteFile.feature
@@ -6,7 +6,9 @@ Feature: Unmark file/folder as favorite
   So that I can remove my favorite file/folder from favorite page
 
   Background:
-    Given user "user1" has been created with default attributes and skeleton files
+    Given user "user1" has been created with default attributes and without skeleton files
+    And user "user1" has uploaded file "filesForUpload/data.zip" to "/data.zip"
+    And user "user1" has created folder "/simple-folder"
     And user "user1" has logged in using the webUI
     And the user has browsed to the files page
 
@@ -35,11 +37,11 @@ Feature: Unmark file/folder as favorite
     When the user browses to the files page
     Then file "data.zip" should not be marked as favorite on the webUI
 
-  Scenario: unmark a folder as favorite from files page
+  Scenario: unmark a folder as favorite from favorite page
     Given the user has marked folder "simple-folder" as favorite using the webUI
     And the user has browsed to the favorites page
     When the user unmarks the favorited folder "simple-folder" using the webUI
     And the user reloads the current page of the webUI
     Then folder "simple-folder" should not be listed in the favorites page on the webUI
     When the user browses to the files page
-    Then folder "simple-folder" should not be marked as favorite on the webUI
\ No newline at end of file
+    Then folder "simple-folder" should not be marked as favorite on the webUI

From 2c3ffbd950c92790ba7a8800daf47e867e9becc3 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Mon, 3 Jun 2019 12:34:11 +0545
Subject: [PATCH 107/131] Adjust webUI acceptance tests for multi-line approach
 to display share autocomplete

---
 .../features/bootstrap/Provisioning.php       | 18 ++++-
 .../bootstrap/WebUISharingContext.php         | 71 +++++++++++++------
 .../lib/FilesPageElement/SharingDialog.php    | 27 ++++++-
 .../restrictSharing.feature                   |  8 +--
 4 files changed, 96 insertions(+), 28 deletions(-)

diff --git a/tests/acceptance/features/bootstrap/Provisioning.php b/tests/acceptance/features/bootstrap/Provisioning.php
index 6183fef793bb..ab74eb59f52e 100644
--- a/tests/acceptance/features/bootstrap/Provisioning.php
+++ b/tests/acceptance/features/bootstrap/Provisioning.php
@@ -126,7 +126,7 @@ public function getUserDisplayName($username) {
 	}
 
 	/**
-	 * returns an array of the display names, keyed by username
+	 * returns an array of the user display names, keyed by username
 	 * if no "Display Name" is set the user-name is returned instead
 	 *
 	 * @return array
@@ -139,6 +139,22 @@ public function getCreatedUserDisplayNames() {
 		return $result;
 	}
 
+	/**
+	 * returns an array of the group display names, keyed by group name
+	 * currently group name and display name are always the same, so this
+	 * function is a convenience for getting the group names in a similar
+	 * format to what getCreatedUserDisplayNames() returns
+	 *
+	 * @return array
+	 */
+	public function getCreatedGroupDisplayNames() {
+		$result = [];
+		foreach ($this->getCreatedGroups() as $groupName => $groupData) {
+			$result[$groupName] = $groupName;
+		}
+		return $result;
+	}
+
 	/**
 	 *
 	 * @param string $username
diff --git a/tests/acceptance/features/bootstrap/WebUISharingContext.php b/tests/acceptance/features/bootstrap/WebUISharingContext.php
index 0b2e94ed92b5..060d13fc7f13 100644
--- a/tests/acceptance/features/bootstrap/WebUISharingContext.php
+++ b/tests/acceptance/features/bootstrap/WebUISharingContext.php
@@ -187,12 +187,14 @@ public function theUserSharesFileFolderWithUserUsingTheWebUI(
 	 *
 	 * @param string $folder
 	 * @param string $group
+	 * @param int $maxRetries
+	 * @param bool $quiet
 	 *
 	 * @return void
 	 * @throws \Exception
 	 */
 	public function theUserSharesFileFolderWithGroupUsingTheWebUI(
-		$folder, $group
+		$folder, $group, $maxRetries = STANDARD_RETRY_COUNT, $quiet = false
 	) {
 		$this->filesPage->waitTillPageIsloaded($this->getSession());
 		try {
@@ -203,7 +205,9 @@ public function theUserSharesFileFolderWithGroupUsingTheWebUI(
 		$this->sharingDialog = $this->filesPage->openSharingDialog(
 			$folder, $this->getSession()
 		);
-		$this->sharingDialog->shareWithGroup($group, $this->getSession());
+		$this->sharingDialog->shareWithGroup(
+			$group, $this->getSession(), $maxRetries, $quiet
+		);
 		$this->theUserClosesTheShareDialog();
 	}
 
@@ -878,7 +882,7 @@ public function allUsersAndGroupsThatContainTheStringInTheirNameShouldBeListedIn
 		$requiredString
 	) {
 		$this->allUsersAndGroupsThatContainTheStringInTheirNameShouldBeListedInTheAutocompleteListExcept(
-			$requiredString, '', ''
+			$requiredString, 'user', ''
 		);
 	}
 
@@ -898,27 +902,37 @@ public function allUsersAndGroupsThatContainTheStringInTheirNameShouldBeListedIn
 			$notToBeListed
 				= $this->sharingDialog->groupStringsToMatchAutoComplete($notToBeListed);
 		}
+		if ($userOrGroup === 'user') {
+			$notToBeListed
+				= $this->sharingDialog->userStringsToMatchAutoComplete($notToBeListed);
+		}
 		$autocompleteItems = $this->sharingDialog->getAutocompleteItemsList();
 		// Keep separate arrays of users and groups, because the names can overlap
-		$createdElements = [];
-		$createdElements['groups'] = $this->sharingDialog->groupStringsToMatchAutoComplete(
-			$this->featureContext->getCreatedGroups()
+		$createdElementsWithDisplayNames = [];
+		$createdElementsWithFullDisplayText = [];
+		$createdElementsWithDisplayNames['groups'] = $this->featureContext->getCreatedGroupDisplayNames();
+		$createdElementsWithFullDisplayText['groups'] = $this->sharingDialog->groupStringsToMatchAutoComplete(
+			$createdElementsWithDisplayNames['groups']
+		);
+		$createdElementsWithDisplayNames['users'] = $this->featureContext->getCreatedUserDisplayNames();
+		$createdElementsWithFullDisplayText['users'] = $this->sharingDialog->userStringsToMatchAutoComplete(
+			$createdElementsWithDisplayNames['users']
 		);
-		$createdElements['users'] = $this->featureContext->getCreatedUserDisplayNames();
 		$numExpectedItems = 0;
-		foreach ($createdElements as $elementArray) {
-			foreach ($elementArray as $internalName => $displayName) {
+		foreach ($createdElementsWithFullDisplayText as $usersOrGroups => $elementArray) {
+			foreach ($elementArray as $internalName => $fullDisplayText) {
+				$displayName = $createdElementsWithDisplayNames[$usersOrGroups][$internalName];
 				// Matching should be case-insensitive on the internal or display name
 				if (((\stripos($internalName, $requiredString) !== false)
 					|| (\stripos($displayName, $requiredString) !== false))
-					&& ($displayName !== $notToBeListed)
+					&& ($fullDisplayText !== $notToBeListed)
 					&& ($displayName !== $this->featureContext->getCurrentUser())
 					&& ($displayName !== $this->featureContext->getCurrentUserDisplayName())
 				) {
 					PHPUnit\Framework\Assert::assertContains(
-						$displayName,
+						$fullDisplayText,
 						$autocompleteItems,
-						"'$displayName' not in autocomplete list"
+						"'$fullDisplayText' not in autocomplete list"
 					);
 					$numExpectedItems = $numExpectedItems + 1;
 				}
@@ -976,8 +990,9 @@ public function userShouldBeListedInTheAutocompleteListOnTheWebui($username) {
 	 */
 	public function userShouldNotBeListedInTheAutocompleteListOnTheWebui($username) {
 		$names = $this->sharingDialog->getAutocompleteItemsList();
-		if (\in_array($username, $names)) {
-			throw new Exception("$username found in autocomplete list but not expected");
+		$userString = $this->sharingDialog->userStringsToMatchAutoComplete($username);
+		if (\in_array($userString, $names)) {
+			throw new Exception("$username ($userString) found in autocomplete list but not expected");
 		}
 	}
 
@@ -1171,28 +1186,44 @@ public function theNumberOfPublicLinksShouldBe($count) {
 	}
 
 	/**
-	 * @Then /^it should not be possible to share (?:file|folder) "([^"]*)"(?: with "([^"]*)")? using the webUI$/
+	 * @Then /^it should not be possible to share (?:file|folder) "([^"]*)"(?: with (user|group) "([^"]*)")? using the webUI$/
 	 *
 	 * @param string $fileName
+	 * @param string $userOrGroup
 	 * @param string|null $shareWith
 	 *
 	 * @return void
 	 * @throws \Exception
 	 */
 	public function itShouldNotBePossibleToShareFileFolderUsingTheWebUI(
-		$fileName, $shareWith = null
+		$fileName, $userOrGroup = null, $shareWith = null
 	) {
 		$sharingWasPossible = false;
 		try {
-			$this->theUserSharesFileFolderWithUserUsingTheWebUI(
-				$fileName, null, $shareWith, 2, true
-			);
+			if ($userOrGroup === "user") {
+				$this->theUserSharesFileFolderWithUserUsingTheWebUI(
+					$fileName, null, $shareWith, 2, true
+				);
+			} else {
+				$this->theUserSharesFileFolderWithGroupUsingTheWebUI(
+					$fileName, $shareWith, 2, true
+				);
+			}
 			$sharingWasPossible = true;
 		} catch (ElementNotFoundException $e) {
+			if ($shareWith === null) {
+				$shareWithText = "";
+			} else {
+				if ($userOrGroup === "user") {
+					$shareWithText = $this->sharingDialog->userStringsToMatchAutoComplete($shareWith);
+				} else {
+					$shareWithText = $this->sharingDialog->groupStringsToMatchAutoComplete($shareWith);
+				}
+			}
 			$possibleMessages = [
 				"could not find share-with-field",
 				"could not find sharing button in fileRow",
-				"could not share with '$shareWith'"
+				"could not share with '$shareWithText'"
 			];
 			$foundMessage = false;
 			foreach ($possibleMessages as $message) {
diff --git a/tests/acceptance/features/lib/FilesPageElement/SharingDialog.php b/tests/acceptance/features/lib/FilesPageElement/SharingDialog.php
index 3a655e1818ed..a02d54c423a6 100644
--- a/tests/acceptance/features/lib/FilesPageElement/SharingDialog.php
+++ b/tests/acceptance/features/lib/FilesPageElement/SharingDialog.php
@@ -46,8 +46,9 @@ class SharingDialog extends OwncloudPage {
 	private $shareWithTooltipXpath = "/..//*[@class='tooltip-inner']";
 	private $shareWithAutocompleteListXpath = ".//ul[contains(@class,'ui-autocomplete')]";
 	private $autocompleteItemsTextXpath = "//*[@class='autocomplete-item-text']";
-	private $suffixToIdentifyGroups = " (group)";
-	private $suffixToIdentifyRemoteUsers = " (federated)";
+	private $suffixToIdentifyGroups = " Group";
+	private $suffixToIdentifyUsers = " User";
+	private $suffixToIdentifyRemoteUsers = " Federated";
 	private $sharerInformationXpath = ".//*[@class='reshare']";
 	private $sharedWithAndByRegEx = "^(?:[A-Z]\s)?Shared with you(?: and the group (.*))? by (.*)$";
 	private $permissionsFieldByUserName = ".//*[@id='shareWithList']//*[@class='has-tooltip username' and .='%s']/..";
@@ -151,6 +152,25 @@ public function getAutocompleteNodeElement() {
 		return $autocompleteNodeElement;
 	}
 
+	/**
+	 * returns the user names as they could appear in an autocomplete list
+	 *
+	 * @param string|array $userNames
+	 *
+	 * @return string|array
+	 */
+	public function userStringsToMatchAutoComplete($userNames) {
+		if (\is_array($userNames)) {
+			$autocompleteStrings = [];
+			foreach ($userNames as $userName => $userDisplayName) {
+				$autocompleteStrings[$userName] = $userDisplayName . $this->suffixToIdentifyUsers;
+			}
+		} else {
+			$autocompleteStrings = $userNames . $this->suffixToIdentifyUsers;
+		}
+		return $autocompleteStrings;
+	}
+
 	/**
 	 * returns the group names as they could appear in an autocomplete list
 	 *
@@ -252,7 +272,8 @@ public function shareWithUser(
 		$name, Session $session, $maxRetries = 5, $quiet = false
 	) {
 		$this->shareWithUserOrGroup(
-			$name, $name, $session, $maxRetries, $quiet
+			$name, $name . $this->suffixToIdentifyUsers,
+			$session, $maxRetries, $quiet
 		);
 	}
 
diff --git a/tests/acceptance/features/webUIRestrictSharing/restrictSharing.feature b/tests/acceptance/features/webUIRestrictSharing/restrictSharing.feature
index 44eddb2eed16..87d7b3ad044e 100644
--- a/tests/acceptance/features/webUIRestrictSharing/restrictSharing.feature
+++ b/tests/acceptance/features/webUIRestrictSharing/restrictSharing.feature
@@ -24,7 +24,7 @@ Feature: restrict Sharing
   Scenario: Restrict users to only share with users in their groups
     Given the setting "Restrict users to only share with users in their groups" in the section "Sharing" has been enabled
     When the user browses to the files page
-    Then it should not be possible to share folder "simple-folder" with "User Three" using the webUI
+    Then it should not be possible to share folder "simple-folder" with user "User Three" using the webUI
     When the user shares folder "simple-folder" with user "User One" using the webUI
     And the user re-logs in as "user1" using the webUI
     Then folder "simple-folder (2)" should be listed on the webUI
@@ -34,7 +34,7 @@ Feature: restrict Sharing
   Scenario: Restrict users to only share with groups they are member of
     Given the setting "Restrict users to only share with groups they are member of" in the section "Sharing" has been enabled
     When the user browses to the files page
-    Then it should not be possible to share folder "simple-folder" with "grp2" using the webUI
+    Then it should not be possible to share folder "simple-folder" with group "grp2" using the webUI
     When the user shares folder "simple-folder" with group "grp1" using the webUI
     And the user re-logs in as "user1" using the webUI
     Then folder "simple-folder (2)" should be listed on the webUI
@@ -55,8 +55,8 @@ Feature: restrict Sharing
   Scenario: Forbid sharing with groups
     Given the setting "Allow sharing with groups" in the section "Sharing" has been disabled
     When the user browses to the files page
-    Then it should not be possible to share folder "simple-folder" with "grp1" using the webUI
-    And it should not be possible to share folder "simple-folder" with "grp2" using the webUI
+    Then it should not be possible to share folder "simple-folder" with group "grp1" using the webUI
+    And it should not be possible to share folder "simple-folder" with group "grp2" using the webUI
     When the user shares folder "simple-folder" with user "User One" using the webUI
     And the user re-logs in as "user1" using the webUI
     Then folder "simple-folder (2)" should be listed on the webUI

From 0c1f5d631d431dc1b1252dbe93792eb0e41cf8f5 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Mon, 3 Jun 2019 17:05:45 +0545
Subject: [PATCH 108/131] Set up remote server share with permissions using API

---
 .../features/bootstrap/FederationContext.php  | 50 ++++++++++++++++++-
 .../federationSharing.feature                 |  8 ++-
 2 files changed, 51 insertions(+), 7 deletions(-)

diff --git a/tests/acceptance/features/bootstrap/FederationContext.php b/tests/acceptance/features/bootstrap/FederationContext.php
index 7642ea4db317..ab576545ed9e 100644
--- a/tests/acceptance/features/bootstrap/FederationContext.php
+++ b/tests/acceptance/features/bootstrap/FederationContext.php
@@ -58,6 +58,26 @@ class FederationContext implements Context {
 	 */
 	public function userFromServerSharesWithUserFromServerUsingTheSharingAPI(
 		$sharerUser, $sharerServer, $sharerPath, $shareeUser, $shareeServer
+	) {
+		$this->userFromServerSharesWithUserFromServerUsingTheSharingAPIWithPermissions(
+			$sharerUser, $sharerServer, $sharerPath, $shareeUser, $shareeServer
+		);
+	}
+	
+	/**
+	 * @When /^user "([^"]*)" from server "(LOCAL|REMOTE)" shares "([^"]*)" with user "([^"]*)" from server "(LOCAL|REMOTE)" using the sharing API with permissions (.*)$/
+	 *
+	 * @param string $sharerUser
+	 * @param string $sharerServer "LOCAL" or "REMOTE"
+	 * @param string $sharerPath
+	 * @param string $shareeUser
+	 * @param string $shareeServer "LOCAL" or "REMOTE"
+	 * @param int $permissions
+	 *
+	 * @return void
+	 */
+	public function userFromServerSharesWithUserFromServerUsingTheSharingAPIWithPermissions(
+		$sharerUser, $sharerServer, $sharerPath, $shareeUser, $shareeServer, $permissions = null
 	) {
 		if ($shareeServer == "REMOTE") {
 			$shareWith
@@ -68,11 +88,11 @@ public function userFromServerSharesWithUserFromServerUsingTheSharingAPI(
 		}
 		$previous = $this->featureContext->usingServer($sharerServer);
 		$this->featureContext->createShare(
-			$sharerUser, $sharerPath, 6, $shareWith, null, null, null
+			$sharerUser, $sharerPath, 6, $shareWith, null, null, $permissions
 		);
 		$this->featureContext->usingServer($previous);
 	}
-	
+
 	/**
 	 * @Given /^user "([^"]*)" from server "(LOCAL|REMOTE)" has shared "([^"]*)" with user "([^"]*)" from server "(LOCAL|REMOTE)"$/
 	 *
@@ -98,6 +118,32 @@ public function userFromServerHasSharedWithUserFromServer(
 		);
 	}
 
+	/**
+	 * @Given /^user "([^"]*)" from server "(LOCAL|REMOTE)" has shared "([^"]*)" with user "([^"]*)" from server "(LOCAL|REMOTE)" with permissions (.*)$/
+	 *
+	 * @param string $sharerUser
+	 * @param string $sharerServer "LOCAL" or "REMOTE"
+	 * @param string $sharerPath
+	 * @param string $shareeUser
+	 * @param string $shareeServer "LOCAL" or "REMOTE"
+	 * @param int $permissions
+	 *
+	 * @return void
+	 */
+	public function userFromServerHasSharedWithUserFromServerWithPermissions(
+		$sharerUser, $sharerServer, $sharerPath, $shareeUser, $shareeServer, $permissions = null
+	) {
+		$this->userFromServerSharesWithUserFromServerUsingTheSharingAPIWithPermissions(
+			$sharerUser, $sharerServer, $sharerPath, $shareeUser, $shareeServer, $permissions
+		);
+		$this->ocsContext->assertOCSResponseIndicatesSuccess(
+			'Could not share file/folder! message: "' .
+			$this->ocsContext->getOCSResponseStatusMessage(
+				$this->featureContext->getResponse()
+			) . '"'
+		);
+	}
+
 	/**
 	 * @When /^user "([^"]*)" from server "(LOCAL|REMOTE)" accepts the last pending share using the sharing API$/
 	 *
diff --git a/tests/acceptance/features/webUISharingExternal/federationSharing.feature b/tests/acceptance/features/webUISharingExternal/federationSharing.feature
index 0a5db836a249..e48ab6add61b 100644
--- a/tests/acceptance/features/webUISharingExternal/federationSharing.feature
+++ b/tests/acceptance/features/webUISharingExternal/federationSharing.feature
@@ -125,11 +125,9 @@ Feature: Federation Sharing - sharing with users on other cloud storages
 
   @skipOnMICROSOFTEDGE
   Scenario: share a folder with an remote user and prohibit deleting - remote server shares - local server receives
-    When user "user1" re-logs in to "%remote_server%" using the webUI
-    And the user shares folder "simple-folder" with remote user "user1@%local_server_without_scheme%" using the webUI
-    And the user sets the sharing permissions of "user1@%local_server_without_scheme% (federated)" for "simple-folder" using the webUI to
-      | delete | no |
-    And user "user1" re-logs in to "%local_server%" using the webUI
+    # permissions read+update+create = 7 (no delete, no (re)share permission)
+    Given user "user1" from server "REMOTE" has shared "simple-folder" with user "user1" from server "LOCAL" with permissions 7
+    When the user browses to the files page
     And the user accepts the offered remote shares using the webUI
     And the user opens folder "simple-folder (2)" using the webUI
     Then it should not be possible to delete file "lorem.txt" using the webUI

From e455ab243ba16e38bdd55c3c02ca9cd1d75239a8 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Tue, 4 Jun 2019 11:38:53 +0545
Subject: [PATCH 109/131] Refactor
 theUserSharesFileFolderWithUserOrGroupUsingTheWebUI

---
 .../bootstrap/WebUISharingContext.php         | 71 +++++++++++--------
 1 file changed, 40 insertions(+), 31 deletions(-)

diff --git a/tests/acceptance/features/bootstrap/WebUISharingContext.php b/tests/acceptance/features/bootstrap/WebUISharingContext.php
index 060d13fc7f13..1c788cc639e5 100644
--- a/tests/acceptance/features/bootstrap/WebUISharingContext.php
+++ b/tests/acceptance/features/bootstrap/WebUISharingContext.php
@@ -159,26 +159,9 @@ private function addToListOfCreatedPublicLinks($name, $url) {
 	public function theUserSharesFileFolderWithUserUsingTheWebUI(
 		$folder, $remote, $user, $maxRetries = STANDARD_RETRY_COUNT, $quiet = false
 	) {
-		$this->filesPage->waitTillPageIsloaded($this->getSession());
-		try {
-			$this->filesPage->closeDetailsDialog();
-		} catch (Exception $e) {
-			//we don't care
-		}
-		$this->sharingDialog = $this->filesPage->openSharingDialog(
-			$folder, $this->getSession()
+		$this->theUserSharesFileFolderWithUserOrGroupUsingTheWebUI(
+			$folder, "user", $remote, $user, $maxRetries, $quiet
 		);
-		$user = $this->featureContext->substituteInLineCodes($user);
-		if ($remote === "remote") {
-			$this->sharingDialog->shareWithRemoteUser(
-				$user, $this->getSession(), $maxRetries, $quiet
-			);
-		} else {
-			$this->sharingDialog->shareWithUser(
-				$user, $this->getSession(), $maxRetries, $quiet
-			);
-		}
-		$this->theUserClosesTheShareDialog();
 	}
 
 	/**
@@ -195,6 +178,25 @@ public function theUserSharesFileFolderWithUserUsingTheWebUI(
 	 */
 	public function theUserSharesFileFolderWithGroupUsingTheWebUI(
 		$folder, $group, $maxRetries = STANDARD_RETRY_COUNT, $quiet = false
+	) {
+		$this->theUserSharesFileFolderWithUserOrGroupUsingTheWebUI(
+			$folder, "group", "", $group, $maxRetries, $quiet
+		);
+	}
+
+	/**
+	 * @param string $folder
+	 * @param string $userOrGroup
+	 * @param string $remote
+	 * @param string $name
+	 * @param int $maxRetries
+	 * @param bool $quiet
+	 *
+	 * @return void
+	 * @throws \Exception
+	 */
+	public function theUserSharesFileFolderWithUserOrGroupUsingTheWebUI(
+		$folder, $userOrGroup, $remote, $name, $maxRetries = STANDARD_RETRY_COUNT, $quiet = false
 	) {
 		$this->filesPage->waitTillPageIsloaded($this->getSession());
 		try {
@@ -205,9 +207,22 @@ public function theUserSharesFileFolderWithGroupUsingTheWebUI(
 		$this->sharingDialog = $this->filesPage->openSharingDialog(
 			$folder, $this->getSession()
 		);
-		$this->sharingDialog->shareWithGroup(
-			$group, $this->getSession(), $maxRetries, $quiet
-		);
+		if ($userOrGroup === "user") {
+			$user = $this->featureContext->substituteInLineCodes($name);
+			if ($remote === "remote") {
+				$this->sharingDialog->shareWithRemoteUser(
+					$user, $this->getSession(), $maxRetries, $quiet
+				);
+			} else {
+				$this->sharingDialog->shareWithUser(
+					$user, $this->getSession(), $maxRetries, $quiet
+				);
+			}
+		} else {
+			$this->sharingDialog->shareWithGroup(
+				$name, $this->getSession(), $maxRetries, $quiet
+			);
+		}
 		$this->theUserClosesTheShareDialog();
 	}
 
@@ -1200,15 +1215,9 @@ public function itShouldNotBePossibleToShareFileFolderUsingTheWebUI(
 	) {
 		$sharingWasPossible = false;
 		try {
-			if ($userOrGroup === "user") {
-				$this->theUserSharesFileFolderWithUserUsingTheWebUI(
-					$fileName, null, $shareWith, 2, true
-				);
-			} else {
-				$this->theUserSharesFileFolderWithGroupUsingTheWebUI(
-					$fileName, $shareWith, 2, true
-				);
-			}
+			$this->theUserSharesFileFolderWithUserOrGroupUsingTheWebUI(
+				$fileName, $userOrGroup, "", $shareWith, 2, true
+			);
 			$sharingWasPossible = true;
 		} catch (ElementNotFoundException $e) {
 			if ($shareWith === null) {

From 3745141482745fc28032cd284ca66b9136f65fbe Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Tue, 11 Jun 2019 16:45:53 +0545
Subject: [PATCH 110/131] Adjust ShouldBeListed steps

---
 .../bootstrap/WebUISharingContext.php         | 42 +++++++++++++++---
 .../shareAutocompletion.feature               | 44 +++++++++----------
 2 files changed, 57 insertions(+), 29 deletions(-)

diff --git a/tests/acceptance/features/bootstrap/WebUISharingContext.php b/tests/acceptance/features/bootstrap/WebUISharingContext.php
index 1c788cc639e5..28b8ca83365c 100644
--- a/tests/acceptance/features/bootstrap/WebUISharingContext.php
+++ b/tests/acceptance/features/bootstrap/WebUISharingContext.php
@@ -864,14 +864,42 @@ public function thePublicShouldNotGetAccessToPublicShareFile() {
 	}
 
 	/**
-	 * @Then only :userOrGroupName should be listed in the autocomplete list on the webUI
+	 * @Then only user :userName should be listed in the autocomplete list on the webUI
 	 *
-	 * @param string $userOrGroupName
+	 * @param string $userName
+	 *
+	 * @return void
+	 */
+	public function onlyUserNameShouldBeListedInTheAutocompleteList(
+		$userName
+	) {
+		$this->onlyNameShouldBeListedInTheAutocompleteList(
+			$this->sharingDialog->userStringsToMatchAutoComplete($userName)
+		);
+	}
+
+	/**
+	 * @Then only group :groupName should be listed in the autocomplete list on the webUI
+	 *
+	 * @param string $groupName
+	 *
+	 * @return void
+	 */
+	public function onlyGroupNameShouldBeListedInTheAutocompleteList(
+		$groupName
+	) {
+		$this->onlyNameShouldBeListedInTheAutocompleteList(
+			$this->sharingDialog->groupStringsToMatchAutoComplete($groupName)
+		);
+	}
+
+	/**
+	 * @param string $autocompleteString the full text expected in the autocomplete item
 	 *
 	 * @return void
 	 */
-	public function onlyUserOrGroupNameShouldBeListedInTheAutocompleteList(
-		$userOrGroupName
+	public function onlyNameShouldBeListedInTheAutocompleteList(
+		$autocompleteString
 	) {
 		$autocompleteItems = $this->sharingDialog->getAutocompleteItemsList();
 		PHPUnit\Framework\Assert::assertCount(
@@ -880,9 +908,9 @@ public function onlyUserOrGroupNameShouldBeListedInTheAutocompleteList(
 			"expected 1 autocomplete item but there are " . \count($autocompleteItems)
 		);
 		PHPUnit\Framework\Assert::assertContains(
-			$userOrGroupName,
+			$autocompleteString,
 			$autocompleteItems,
-			"'$userOrGroupName' not in autocomplete list"
+			"'$autocompleteString' not in autocomplete list"
 		);
 	}
 
@@ -989,7 +1017,7 @@ public function theUsersOwnNameShouldNotBeListedInTheAutocompleteList() {
 	public function userShouldBeListedInTheAutocompleteListOnTheWebui($username) {
 		$names = $this->sharingDialog->getAutocompleteItemsList();
 		PHPUnit\Framework\Assert::assertContains(
-			$username,
+			$this->sharingDialog->userStringsToMatchAutoComplete($username),
 			$names,
 			"$username not found in autocomplete list"
 		);
diff --git a/tests/acceptance/features/webUISharingAutocompletion/shareAutocompletion.feature b/tests/acceptance/features/webUISharingAutocompletion/shareAutocompletion.feature
index f07e20960ea0..2ebc1c4b842d 100644
--- a/tests/acceptance/features/webUISharingAutocompletion/shareAutocompletion.feature
+++ b/tests/acceptance/features/webUISharingAutocompletion/shareAutocompletion.feature
@@ -70,7 +70,7 @@ Feature: Autocompletion of share-with names
       | use      | %alt1%   | Use         | uz@oc.com.np |
     And the user has opened the share dialog for folder "simple-folder"
     When the user types "Use" in the share-with-field
-    Then only "Use" should be listed in the autocomplete list on the webUI
+    Then only user "Use" should be listed in the autocomplete list on the webUI
     And user "User Two" should not be listed in the autocomplete list on the webUI
 
   @skipOnLDAP
@@ -83,7 +83,7 @@ Feature: Autocompletion of share-with names
     And the user has browsed to the files page
     And the user has opened the share dialog for folder "simple-folder"
     When the user types "fi" in the share-with-field
-    Then only "fi (group)" should be listed in the autocomplete list on the webUI
+    Then only group "fi" should be listed in the autocomplete list on the webUI
     And user "finance1" should not be listed in the autocomplete list on the webUI
 
   @skipOnLDAP
@@ -201,8 +201,8 @@ Feature: Autocompletion of share-with names
   @skipOnLDAP
   Scenario: autocompletion of a pattern where the username of the existing user contains the pattern somewhere in the end
     Given these users have been created with default attributes and skeleton files but not initialized:
-      | username     | displayname   |
-      | regularuser3 | Guest User |
+      | username     | displayname |
+      | regularuser3 | Guest User  |
     And user "user1" has logged in using the webUI
     And the user has browsed to the files page
     And the user has opened the share dialog for folder "simple-folder"
@@ -226,7 +226,7 @@ Feature: Autocompletion of share-with names
     And the user has browsed to the files page
     And the user has opened the share dialog for folder "simple-folder"
     When the user types "finn" in the share-with-field
-    Then only "John Finn Smith" should be listed in the autocomplete list on the webUI
+    Then only user "John Finn Smith" should be listed in the autocomplete list on the webUI
 
   @skipOnLDAP
   Scenario: autocompletion of a pattern where the name of existing user contains the pattern somewhere at the end
@@ -234,7 +234,7 @@ Feature: Autocompletion of share-with names
     And the user has browsed to the files page
     And the user has opened the share dialog for folder "simple-folder"
     When the user types "group" in the share-with-field
-    Then only "User Group" should be listed in the autocomplete list on the webUI
+    Then only user "User Group" should be listed in the autocomplete list on the webUI
 
   @skipOnLDAP
   Scenario: autocompletion of a pattern where the email of the existing user contains the pattern somewhere at the beginning
@@ -242,7 +242,7 @@ Feature: Autocompletion of share-with names
     And the user has browsed to the files page
     And the user has opened the share dialog for folder "simple-folder"
     When the user types "u2" in the share-with-field
-    Then only "User Two" should be listed in the autocomplete list on the webUI
+    Then only user "User Two" should be listed in the autocomplete list on the webUI
 
   @skipOnLDAP
   Scenario: autocompletion of a pattern where the email of the existing user contains the pattern somewhere at the middle
@@ -250,7 +250,7 @@ Feature: Autocompletion of share-with names
     And the user has browsed to the files page
     And the user has opened the share dialog for folder "simple-folder"
     When the user types "net" in the share-with-field
-    Then only "User Group" should be listed in the autocomplete list on the webUI
+    Then only user "User Group" should be listed in the autocomplete list on the webUI
 
   @skipOnLDAP
   Scenario: autocompletion of a pattern where the email of the existing user contains the pattern somewhere at the end
@@ -258,7 +258,7 @@ Feature: Autocompletion of share-with names
     And the user has browsed to the files page
     And the user has opened the share dialog for folder "simple-folder"
     When the user types "de" in the share-with-field
-    Then only "John Finn Smith" should be listed in the autocomplete list on the webUI
+    Then only user "John Finn Smith" should be listed in the autocomplete list on the webUI
 
   @skipOnLDAP
   Scenario: autocompletion of a pattern where the name of existing group contains the pattern somewhere in the middle but group medial search is disabled
@@ -293,25 +293,25 @@ Feature: Autocompletion of share-with names
   Scenario: autocompletion of a pattern where the user name contains the pattern somewhere in the middle but accounts medial search is disabled
     Given these users have been created with default attributes and skeleton files but not initialized:
       | username | displayname |
-      | ivan     | Ivan         |
+      | ivan     | Ivan        |
     And user "user1" has logged in using the webUI
     And the administrator has added system config key "accounts.enable_medial_search" with value "false" and type "boolean"
     And the user has browsed to the files page
     And the user has opened the share dialog for folder "simple-folder"
     When the user types "iv" in the share-with-field
-    Then only "Ivan" should be listed in the autocomplete list on the webUI
+    Then only user "Ivan" should be listed in the autocomplete list on the webUI
 
   @skipOnLDAP
   Scenario: autocompletion of a pattern where the user name contains the pattern somewhere in the end but accounts medial search is disabled
     Given these users have been created with default attributes and skeleton files but not initialized:
-      | username     | displayname   |
-      | regularuser3 | Guest User |
+      | username     | displayname |
+      | regularuser3 | Guest User  |
     And user "user1" has logged in using the webUI
     And the administrator has added system config key "accounts.enable_medial_search" with value "false" and type "boolean"
     And the user has browsed to the files page
     And the user has opened the share dialog for folder "simple-folder"
     When the user types "user3" in the share-with-field
-    Then only "User Three" should be listed in the autocomplete list on the webUI
+    Then only user "User Three" should be listed in the autocomplete list on the webUI
 
   @skipOnLDAP
   Scenario: autocompletion of a pattern where the name of existing user contains the pattern somewhere in the middle but accounts medial search is disabled
@@ -323,19 +323,19 @@ Feature: Autocompletion of share-with names
     And the administrator has added system config key "accounts.enable_medial_search" with value "false" and type "boolean"
     And the user has opened the share dialog for folder "simple-folder"
     When the user types "finn" in the share-with-field
-    Then only "finnance typo" should be listed in the autocomplete list on the webUI
+    Then only user "finnance typo" should be listed in the autocomplete list on the webUI
 
   @skipOnLDAP
   Scenario: autocompletion of a pattern where the display name of existing user contains the pattern somewhere in the end but accounts medial search is disabled
     Given these users have been created with default attributes and skeleton files but not initialized:
-      | username | displayname   |
-      | user2    | Group User |
+      | username | displayname |
+      | user2    | Group User  |
     And user "user1" has logged in using the webUI
     And the administrator has added system config key "accounts.enable_medial_search" with value "false" and type "boolean"
     And the user has browsed to the files page
     And the user has opened the share dialog for folder "simple-folder"
     When the user types "group" in the share-with-field
-    Then only "Group User" should be listed in the autocomplete list on the webUI
+    Then only user "Group User" should be listed in the autocomplete list on the webUI
 
   @skipOnLDAP
   Scenario: autocompletion of a pattern where the email of the existing user contains the pattern somewhere at the beginning but accounts medial search is disabled
@@ -347,19 +347,19 @@ Feature: Autocompletion of share-with names
     And the user has browsed to the files page
     And the user has opened the share dialog for folder "simple-folder"
     When the user types "u2" in the share-with-field
-    Then only "User Two" should be listed in the autocomplete list on the webUI
+    Then only user "User Two" should be listed in the autocomplete list on the webUI
 
   @skipOnLDAP
   Scenario: autocompletion of a pattern where the email of the existing user contains the pattern somewhere at the middle but accounts medial search is disabled
     Given these users have been created with default attributes and skeleton files but not initialized:
-      | username | displayname | email              |
+      | username | displayname | email         |
       | user2    | User2       | net@oc.com.np |
     And user "user1" has logged in using the webUI
     And the administrator has added system config key "accounts.enable_medial_search" with value "false" and type "boolean"
     And the user has browsed to the files page
     And the user has opened the share dialog for folder "simple-folder"
     When the user types "net" in the share-with-field
-    Then only "User2" should be listed in the autocomplete list on the webUI
+    Then only user "User2" should be listed in the autocomplete list on the webUI
 
   @skipOnLDAP
   Scenario: autocompletion of a pattern where the email of the existing user contains the pattern somewhere at the end but accounts medial search is disabled
@@ -371,7 +371,7 @@ Feature: Autocompletion of share-with names
     And the user has browsed to the files page
     And the user has opened the share dialog for folder "simple-folder"
     When the user types "de" in the share-with-field
-    Then only "User2" should be listed in the autocomplete list on the webUI
+    Then only user "User2" should be listed in the autocomplete list on the webUI
 
   @skipOnLDAP
   Scenario: allow user to disable autocomplete in sharing dialog

From cd92a4356ba20a8abd04a0267b868a2bc914a018 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Tue, 11 Jun 2019 17:02:10 +0545
Subject: [PATCH 111/131] Adjust
 theUsersOwnNameShouldNotBeListedInTheAutocompleteList

---
 .../features/bootstrap/WebUISharingContext.php        | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/tests/acceptance/features/bootstrap/WebUISharingContext.php b/tests/acceptance/features/bootstrap/WebUISharingContext.php
index 28b8ca83365c..5466fb2f5a19 100644
--- a/tests/acceptance/features/bootstrap/WebUISharingContext.php
+++ b/tests/acceptance/features/bootstrap/WebUISharingContext.php
@@ -1001,7 +1001,9 @@ public function allUsersAndGroupsThatContainTheStringInTheirNameShouldBeListedIn
 	 */
 	public function theUsersOwnNameShouldNotBeListedInTheAutocompleteList() {
 		PHPUnit\Framework\Assert::assertNotContains(
-			$this->filesPage->getMyDisplayname(),
+			$this->sharingDialog->userStringsToMatchAutoComplete(
+				$this->filesPage->getMyDisplayname()
+			),
 			$this->sharingDialog->getAutocompleteItemsList()
 		);
 	}
@@ -1034,9 +1036,10 @@ public function userShouldBeListedInTheAutocompleteListOnTheWebui($username) {
 	public function userShouldNotBeListedInTheAutocompleteListOnTheWebui($username) {
 		$names = $this->sharingDialog->getAutocompleteItemsList();
 		$userString = $this->sharingDialog->userStringsToMatchAutoComplete($username);
-		if (\in_array($userString, $names)) {
-			throw new Exception("$username ($userString) found in autocomplete list but not expected");
-		}
+		PHPUnit\Framework\Assert::assertFalse(
+			\in_array($userString, $names),
+			"$username ($userString) found in autocomplete list but not expected"
+		);
 	}
 
 	/**

From 056384c399288bcd723aacd00ff6ac4f4205d33f Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Tue, 11 Jun 2019 21:14:50 +0545
Subject: [PATCH 112/131] Do not specially handle case when shareWith is null
 in itShouldNotBePossibleToShareFileFolderUsingTheWebUI

---
 tests/acceptance/features/bootstrap/WebUISharingContext.php | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/acceptance/features/bootstrap/WebUISharingContext.php b/tests/acceptance/features/bootstrap/WebUISharingContext.php
index 5466fb2f5a19..286a2e66bc87 100644
--- a/tests/acceptance/features/bootstrap/WebUISharingContext.php
+++ b/tests/acceptance/features/bootstrap/WebUISharingContext.php
@@ -1251,7 +1251,7 @@ public function itShouldNotBePossibleToShareFileFolderUsingTheWebUI(
 			);
 			$sharingWasPossible = true;
 		} catch (ElementNotFoundException $e) {
-			if ($shareWith === null) {
+			if ($this->sharingDialog === null) {
 				$shareWithText = "";
 			} else {
 				if ($userOrGroup === "user") {

From 558560892c532d96b6fdecfa4c0d0a98f7e36ed4 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Mon, 17 Jun 2019 22:15:09 +0545
Subject: [PATCH 113/131] Adjust SharingDialog suffixToIdentify Groups Users
 RemoteUsers to match old strings

---
 .../features/lib/FilesPageElement/SharingDialog.php         | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/acceptance/features/lib/FilesPageElement/SharingDialog.php b/tests/acceptance/features/lib/FilesPageElement/SharingDialog.php
index a02d54c423a6..c4a39b02c497 100644
--- a/tests/acceptance/features/lib/FilesPageElement/SharingDialog.php
+++ b/tests/acceptance/features/lib/FilesPageElement/SharingDialog.php
@@ -46,9 +46,9 @@ class SharingDialog extends OwncloudPage {
 	private $shareWithTooltipXpath = "/..//*[@class='tooltip-inner']";
 	private $shareWithAutocompleteListXpath = ".//ul[contains(@class,'ui-autocomplete')]";
 	private $autocompleteItemsTextXpath = "//*[@class='autocomplete-item-text']";
-	private $suffixToIdentifyGroups = " Group";
-	private $suffixToIdentifyUsers = " User";
-	private $suffixToIdentifyRemoteUsers = " Federated";
+	private $suffixToIdentifyGroups = " (group)";
+	private $suffixToIdentifyUsers = "";
+	private $suffixToIdentifyRemoteUsers = " (federated)";
 	private $sharerInformationXpath = ".//*[@class='reshare']";
 	private $sharedWithAndByRegEx = "^(?:[A-Z]\s)?Shared with you(?: and the group (.*))? by (.*)$";
 	private $permissionsFieldByUserName = ".//*[@id='shareWithList']//*[@class='has-tooltip username' and .='%s']/..";

From 331bcccacd1efe62e755dcec342229cfaa78b9c3 Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Wed, 12 Jun 2019 14:37:26 +0545
Subject: [PATCH 114/131] file operations in webui without skeleton

---
 .../browseDirectlyToDetailsTab.feature        |  9 ++-
 .../features/webUIFiles/fileDetails.feature   | 46 +++++++-----
 .../features/webUIFiles/hiddenFile.feature    |  2 +-
 .../features/webUIFiles/versions.feature      | 73 ++++++++++---------
 4 files changed, 74 insertions(+), 56 deletions(-)

diff --git a/tests/acceptance/features/webUIFiles/browseDirectlyToDetailsTab.feature b/tests/acceptance/features/webUIFiles/browseDirectlyToDetailsTab.feature
index 3d92dd8cba7b..c77cdedc172e 100644
--- a/tests/acceptance/features/webUIFiles/browseDirectlyToDetailsTab.feature
+++ b/tests/acceptance/features/webUIFiles/browseDirectlyToDetailsTab.feature
@@ -5,7 +5,14 @@ Feature: browse directly to details tab
   So that I can see the details immediately without needing to click in the UI
 
   Background:
-    Given user "user1" has been created with default attributes and skeleton files
+    Given user "user1" has been created with default attributes and without skeleton files
+    And user "user1" has created folder "simple-folder"
+    And user "user1" has uploaded file with content "some content" to "/block-aligned.txt"
+    And user "user1" has uploaded file with content "some content" to "/simple-folder/block-aligned.txt"
+    And user "user1" has uploaded file with content "some content" to "/lorem.txt"
+    And user "user1" has uploaded file with content "some content" to "/simple-folder/lorem.txt"
+    And user "user1" has uploaded file with content "some content" to "/zzzz-must-be-last-file-in-folder.txt"
+    And user "user1" has uploaded file with content "some content" to "/simple-folder/zzzz-must-be-last-file-in-folder.txt"
     And user "user1" has logged in using the webUI
 
   @smokeTest
diff --git a/tests/acceptance/features/webUIFiles/fileDetails.feature b/tests/acceptance/features/webUIFiles/fileDetails.feature
index d6a48cdfafbd..ab8131631e7a 100644
--- a/tests/acceptance/features/webUIFiles/fileDetails.feature
+++ b/tests/acceptance/features/webUIFiles/fileDetails.feature
@@ -8,12 +8,12 @@ Feature: User can open the details panel for any file or folder
     Given these users have been created with default attributes and skeleton files:
       | username |
       | user1    |
-    And user "user1" has logged in using the webUI
-    And the user has browsed to the files page
 
   @comments-app-required @files_versions-app-required
   Scenario: View different areas of the details panel in files page
-    When the user opens the file action menu of file "lorem.txt" on the webUI
+    Given user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And user "user1" has logged in using the webUI
+    When the user opens the file action menu of file "randomfile.txt" on the webUI
     And the user clicks the details file action on the webUI
     Then the details dialog should be visible on the webUI
     And the thumbnail should be visible in the details panel
@@ -26,9 +26,11 @@ Feature: User can open the details panel for any file or folder
 
   @comments-app-required @files_versions-app-required
   Scenario: View different areas of the details panel in favorites page
-    When the user marks file "lorem.txt" as favorite using the webUI
+    Given user "user1" has uploaded file with content "some content" to "/randomfile.txt"
+    And user "user1" has logged in using the webUI
+    When the user marks file "randomfile.txt" as favorite using the webUI
     And the user browses to the favorites page
-    And the user opens the file action menu of file "lorem.txt" on the webUI
+    And the user opens the file action menu of file "randomfile.txt" on the webUI
     And the user clicks the details file action on the webUI
     Then the details dialog should be visible on the webUI
     And the thumbnail should be visible in the details panel
@@ -41,10 +43,12 @@ Feature: User can open the details panel for any file or folder
 
   @comments-app-required @public_link_share-feature-required
   Scenario: user shares a file through public link and then the details dialog should work in a Shared by link page
-    Given the user has created a new public link for folder "simple-folder" using the webUI
+    Given user "user1" has created folder "a-folder"
+    And user "user1" has logged in using the webUI
+    And the user has created a new public link for folder "a-folder" using the webUI
     When the user browses to the shared-by-link page
-    Then folder "simple-folder" should be listed on the webUI
-    When the user opens the file action menu of folder "simple-folder" on the webUI
+    Then folder "a-folder" should be listed on the webUI
+    When the user opens the file action menu of folder "a-folder" on the webUI
     And the user clicks the details file action on the webUI
     Then the details dialog should be visible on the webUI
     And the thumbnail should be visible in the details panel
@@ -55,11 +59,13 @@ Feature: User can open the details panel for any file or folder
 
   @comments-app-required
   Scenario: user shares a file and then the details dialog should work in a Shared with others page
-    Given user "user2" has been created with default attributes and skeleton files
-    And the user has shared folder "simple-folder" with user "User Two" using the webUI
+    Given user "user2" has been created with default attributes and without skeleton files
+    And user "user1" has created folder "a-folder"
+    And user "user1" has logged in using the webUI
+    And the user has shared folder "a-folder" with user "User Two" using the webUI
     When the user browses to the shared-with-others page
-    Then folder "simple-folder" should be listed on the webUI
-    When the user opens the file action menu of folder "simple-folder" on the webUI
+    Then folder "a-folder" should be listed on the webUI
+    When the user opens the file action menu of folder "a-folder" on the webUI
     And the user clicks the details file action on the webUI
     Then the details dialog should be visible on the webUI
     And the thumbnail should be visible in the details panel
@@ -71,11 +77,13 @@ Feature: User can open the details panel for any file or folder
   @comments-app-required
   Scenario: the recipient user should be able to view different areas of details panel in Shared with you page
     Given user "user2" has been created with default attributes and skeleton files
-    And the user has shared folder "simple-folder" with user "User Two" using the webUI
+    And user "user1" has created folder "a-folder"
+    And user "user1" has logged in using the webUI
+    And the user has shared folder "a-folder" with user "User Two" using the webUI
     And the user re-logs in as "user2" using the webUI
     When the user browses to the shared-with-you page
-    Then folder "simple-folder (2)" should be listed on the webUI
-    When the user opens the file action menu of folder "simple-folder (2)" on the webUI
+    Then folder "a-folder" should be listed on the webUI
+    When the user opens the file action menu of folder "a-folder" on the webUI
     And the user clicks the details file action on the webUI
     Then the details dialog should be visible on the webUI
     And the thumbnail should be visible in the details panel
@@ -87,11 +95,13 @@ Feature: User can open the details panel for any file or folder
   @comments-app-required
   Scenario: View different areas of details panel for the folder with given tag in Tags page
     Given user "user1" has created a "normal" tag with name "simple"
-    And user "user1" has added tag "simple" to folder "simple-folder"
+    And user "user1" has created folder "a-folder"
+    And user "user1" has added tag "simple" to folder "a-folder"
+    And user "user1" has logged in using the webUI
     When the user browses to the tags page
     And the user searches for tag "simple" using the webUI
-    Then folder "simple-folder" should be listed on the webUI
-    When the user opens the file action menu of folder "simple-folder" on the webUI
+    Then folder "a-folder" should be listed on the webUI
+    When the user opens the file action menu of folder "a-folder" on the webUI
     And the user clicks the details file action on the webUI
     Then the details dialog should be visible on the webUI
     And the thumbnail should be visible in the details panel
diff --git a/tests/acceptance/features/webUIFiles/hiddenFile.feature b/tests/acceptance/features/webUIFiles/hiddenFile.feature
index fe42e0cbd90f..a002e5ce779d 100644
--- a/tests/acceptance/features/webUIFiles/hiddenFile.feature
+++ b/tests/acceptance/features/webUIFiles/hiddenFile.feature
@@ -6,7 +6,7 @@ Feature: Hide file/folders
   So that I can choose to see the files that I want.
 
   Background:
-    Given user "user1" has been created with default attributes and skeleton files
+    Given user "user1" has been created with default attributes and without skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the files page
 
diff --git a/tests/acceptance/features/webUIFiles/versions.feature b/tests/acceptance/features/webUIFiles/versions.feature
index 5120f7829623..7802ceb8deac 100644
--- a/tests/acceptance/features/webUIFiles/versions.feature
+++ b/tests/acceptance/features/webUIFiles/versions.feature
@@ -7,84 +7,85 @@ Feature: Versions of a file
   So that I can have more control over the files
 
   Background:
-    Given these users have been created with default attributes and skeleton files:
+    Given these users have been created with default attributes and without skeleton files:
       | username |
       | user0    |
 
   @skipOnStorage:ceph @files_primary_s3-issue-67
   Scenario: upload new file with same name to see if different versions are shown
-    Given user "user0" has logged in using the webUI
+    Given user "user0" has uploaded file with content "some content" to "/randomfile.txt"
+    And user "user0" has logged in using the webUI
     And the user has browsed to the files page
-    And user "user0" has uploaded file with content "lorem content" to "/lorem.txt"
-    And user "user0" has uploaded file with content "new lorem content" to "/lorem.txt"
-    When the user browses directly to display the "versions" details of file "lorem.txt" in folder "/"
-    Then the content of file "lorem.txt" for user "user0" should be "new lorem content"
+    And user "user0" has uploaded file with content "lorem content" to "/randomfile.txt"
+    And user "user0" has uploaded file with content "new lorem content" to "/randomfile.txt"
+    When the user browses directly to display the "versions" details of file "randomfile.txt" in folder "/"
+    Then the content of file "randomfile.txt" for user "user0" should be "new lorem content"
     And the versions list should contain 2 entries
 
   Scenario: restoring file to old version changes the content of the file
-    Given user "user0" has logged in using the webUI
+    Given user "user0" has uploaded file with content "lorem content" to "/randomfile.txt"
+    And user "user0" has logged in using the webUI
     And the user has browsed to the files page
-    And user "user0" has uploaded file with content "lorem content" to "/lorem-file.txt"
-    And user "user0" has uploaded file with content "new lorem content" to "/lorem-file.txt"
-    When the user browses directly to display the "versions" details of file "lorem-file.txt" in folder "/"
+    And user "user0" has uploaded file with content "new lorem content" to "/randomfile.txt"
+    When the user browses directly to display the "versions" details of file "randomfile.txt" in folder "/"
     And the user restores the file to last version using the webUI
-    Then the content of file "lorem-file.txt" for user "user0" should be "lorem content"
+    Then the content of file "randomfile.txt" for user "user0" should be "lorem content"
 
   Scenario: sharee can see the versions of a file
-    Given user "user1" has been created with default attributes and skeleton files
-    And user "user0" has uploaded file with content "lorem content" to "/lorem-file.txt"
-    And user "user0" has uploaded file with content "lorem" to "/lorem-file.txt"
-    And user "user0" has uploaded file with content "new lorem content" to "/lorem-file.txt"
-    And user "user0" has shared file "lorem-file.txt" with user "user1"
+    Given user "user1" has been created with default attributes and without skeleton files
+    And user "user0" has uploaded file with content "lorem content" to "/randomfile.txt"
+    And user "user0" has uploaded file with content "lorem" to "/randomfile.txt"
+    And user "user0" has uploaded file with content "new lorem content" to "/randomfile.txt"
+    And user "user0" has shared file "randomfile.txt" with user "user1"
     And user "user1" has logged in using the webUI
     And the user has browsed to the files page
-    When the user browses directly to display the "versions" details of file "lorem-file.txt" in folder "/"
-    Then the content of file "lorem-file.txt" for user "user1" should be "new lorem content"
+    When the user browses directly to display the "versions" details of file "randomfile.txt" in folder "/"
+    Then the content of file "randomfile.txt" for user "user1" should be "new lorem content"
     And the versions list should contain 2 entries
 
   @skipOnStorage:ceph @files_primary_s3-issue-155
   Scenario: file versions cannot be seen on the webUI after deleting versions
-    Given user "user0" has uploaded file with content "lorem content" to "/lorem-file.txt"
-    And user "user0" has uploaded file with content "lorem" to "/lorem-file.txt"
-    And user "user0" has uploaded file with content "new lorem content" to "/lorem-file.txt"
+    Given user "user0" has uploaded file with content "lorem content" to "/randomfile.txt"
+    And user "user0" has uploaded file with content "lorem" to "/randomfile.txt"
+    And user "user0" has uploaded file with content "new lorem content" to "/randomfile.txt"
     And user "user0" has logged in using the webUI
     And the user has browsed to the files page
     And the administrator has cleared the versions for user "user0"
-    When the user browses directly to display the "versions" details of file "lorem-file.txt" in folder "/"
+    When the user browses directly to display the "versions" details of file "randomfile.txt" in folder "/"
     And the versions list should contain 0 entries
 
   @skipOnStorage:ceph @files_primary_s3-issue-155
   Scenario: file versions cannot be seen on the webUI only for user whose versions is deleted
-    Given user "user1" has been created with default attributes and skeleton files
-    And user "user0" has uploaded file with content "lorem content" to "/lorem-file.txt"
-    And user "user0" has uploaded file with content "lorem" to "/lorem-file.txt"
-    And user "user1" has uploaded file with content "lorem content" to "/lorem-file.txt"
-    And user "user1" has uploaded file with content "lorem" to "/lorem-file.txt"
+    Given user "user1" has been created with default attributes and without skeleton files
+    And user "user0" has uploaded file with content "lorem content" to "/randomfile.txt"
+    And user "user0" has uploaded file with content "lorem" to "/randomfile.txt"
+    And user "user1" has uploaded file with content "lorem content" to "/randomfile.txt"
+    And user "user1" has uploaded file with content "lorem" to "/randomfile.txt"
     And user "user0" has logged in using the webUI
     And the user has browsed to the files page
     And the administrator has cleared the versions for user "user0"
-    When the user browses directly to display the "versions" details of file "lorem-file.txt" in folder "/"
+    When the user browses directly to display the "versions" details of file "randomfile.txt" in folder "/"
     Then the versions list should contain 0 entries
     When the user logs out of the webUI
     And user "user1" logs in using the webUI
     And the user has browsed to the files page
-    And the user browses directly to display the "versions" details of file "lorem-file.txt" in folder "/"
+    And the user browses directly to display the "versions" details of file "randomfile.txt" in folder "/"
     Then the versions list should contain 1 entries
 
   @skipOnStorage:ceph @files_primary_s3-issue-155
   Scenario: file versions cannot be seen on the webUI for all users after deleting versions for all users
-    Given user "user1" has been created with default attributes and skeleton files
-    And user "user0" has uploaded file with content "lorem content" to "/lorem-file.txt"
-    And user "user0" has uploaded file with content "lorem" to "/lorem-file.txt"
-    And user "user1" has uploaded file with content "lorem content" to "/lorem-file.txt"
-    And user "user1" has uploaded file with content "lorem" to "/lorem-file.txt"
+    Given user "user1" has been created with default attributes and without skeleton files
+    And user "user0" has uploaded file with content "lorem content" to "/randomfile.txt"
+    And user "user0" has uploaded file with content "lorem" to "/randomfile.txt"
+    And user "user1" has uploaded file with content "lorem content" to "/randomfile.txt"
+    And user "user1" has uploaded file with content "lorem" to "/randomfile.txt"
     And user "user0" has logged in using the webUI
     And the user has browsed to the files page
     And the administrator has cleared the versions for all users
-    When the user browses directly to display the "versions" details of file "lorem-file.txt" in folder "/"
+    When the user browses directly to display the "versions" details of file "randomfile.txt" in folder "/"
     Then the versions list should contain 0 entries
     When the user logs out of the webUI
     And user "user1" logs in using the webUI
     And the user has browsed to the files page
-    And the user browses directly to display the "versions" details of file "lorem-file.txt" in folder "/"
+    And the user browses directly to display the "versions" details of file "randomfile.txt" in folder "/"
     Then the versions list should contain 0 entries

From a3d28d105bfe2c90bc0c1db16c11935a4c29af57 Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Thu, 13 Jun 2019 10:28:04 +0545
Subject: [PATCH 115/131] webui sharing notifications without skeleton

---
 .../notificationLink.feature                  |  5 ++-
 .../shareWithGroups.feature                   | 16 ++++----
 .../shareWithUsers.feature                    | 38 ++++++++++---------
 3 files changed, 32 insertions(+), 27 deletions(-)

diff --git a/tests/acceptance/features/webUISharingNotifications/notificationLink.feature b/tests/acceptance/features/webUISharingNotifications/notificationLink.feature
index bbe256f11b55..202c4197ef7b 100644
--- a/tests/acceptance/features/webUISharingNotifications/notificationLink.feature
+++ b/tests/acceptance/features/webUISharingNotifications/notificationLink.feature
@@ -6,7 +6,7 @@ Feature: Display notifications when receiving a share and follow embedded links
 
   Background:
     Given app "notifications" has been enabled
-    And these users have been created with default attributes and skeleton files:
+    And these users have been created with default attributes and without skeleton files:
       | username |
       | user1    |
       | user2    |
@@ -15,6 +15,7 @@ Feature: Display notifications when receiving a share and follow embedded links
   @smokeTest
   Scenario: notification link redirection in case a share is pending
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been disabled
-    And user "user1" has shared folder "/simple-folder" with user "user2"
+    And user "user1" has created folder "a-folder"
+    And user "user1" has shared folder "a-folder" with user "user2"
     When the user follows the link of the first notification on the webUI
     Then the user should be redirected to a webUI page with the title "Shared with you - %productname%"
\ No newline at end of file
diff --git a/tests/acceptance/features/webUISharingNotifications/shareWithGroups.feature b/tests/acceptance/features/webUISharingNotifications/shareWithGroups.feature
index 10a2335f2362..b21c0b58fb80 100644
--- a/tests/acceptance/features/webUISharingNotifications/shareWithGroups.feature
+++ b/tests/acceptance/features/webUISharingNotifications/shareWithGroups.feature
@@ -6,7 +6,7 @@ Feature: Sharing files and folders with internal groups
 
   Background:
     Given app "notifications" has been enabled
-    And these users have been created with default attributes and skeleton files:
+    And these users have been created with default attributes and without skeleton files:
       | username |
       | user1    |
       | user2    |
@@ -20,14 +20,16 @@ Feature: Sharing files and folders with internal groups
 
   Scenario: notifications about new share is displayed
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been disabled
-    When user "user3" has shared folder "/simple-folder" with group "grp1"
-    And user "user3" has shared folder "/data.zip" with group "grp1"
+    And user "user3" has created folder "a-folder"
+    And user "user3" has uploaded file "filesForUpload/data.zip" to "/data.zip"
+    When user "user3" has shared folder "/a-folder" with group "grp1"
+    And user "user3" has shared file "/data.zip" with group "grp1"
     Then the user should see 2 notifications on the webUI with these details
       | title                                        |
-      | "User Three" shared "simple-folder" with you |
-      | "User Three" shared "data.zip" with you      |
+      | "User Three" shared "a-folder" with you      |
+      | "User Three" shared "data.zip" with you    |
     When the user re-logs in as "user1" using the webUI
     Then the user should see 2 notifications on the webUI with these details
       | title                                        |
-      | "User Three" shared "simple-folder" with you |
-      | "User Three" shared "data.zip" with you      |
\ No newline at end of file
+      | "User Three" shared "a-folder" with you      |
+      | "User Three" shared "data.zip" with you    |
\ No newline at end of file
diff --git a/tests/acceptance/features/webUISharingNotifications/shareWithUsers.feature b/tests/acceptance/features/webUISharingNotifications/shareWithUsers.feature
index 89128535459a..2b3d69177b3c 100644
--- a/tests/acceptance/features/webUISharingNotifications/shareWithUsers.feature
+++ b/tests/acceptance/features/webUISharingNotifications/shareWithUsers.feature
@@ -6,49 +6,51 @@ Feature: Sharing files and folders with internal users
 
   Background:
     Given app "notifications" has been enabled
-    And these users have been created with default attributes and skeleton files:
+    And these users have been created with default attributes and without skeleton files:
       | username |
       | user1    |
       | user2    |
+    And user "user1" has created folder "a-folder"
+    And user "user1" has uploaded file "filesForUpload/data.zip" to "/data.zip"
     And user "user2" has logged in using the webUI
 
   @smokeTest
   Scenario: notifications about new share is displayed when autoacepting is disabled
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been disabled
-    And user "user1" has shared folder "/simple-folder" with user "user2"
-    And user "user1" has shared folder "/data.zip" with user "user2"
+    And user "user1" has shared folder "/a-folder" with user "user2"
+    And user "user1" has shared file "/data.zip" with user "user2"
     Then the user should see 2 notifications on the webUI with these details
       | title                                      |
-      | "User One" shared "simple-folder" with you |
+      | "User One" shared "a-folder" with you |
       | "User One" shared "data.zip" with you      |
 
   @smokeTest
   Scenario: Notification is gone after accepting a share
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been disabled
-    And user "user1" has shared folder "/simple-folder" with user "user2"
-    And user "user1" has shared folder "/simple-empty-folder" with user "user2"
+    And user "user1" has shared folder "/a-folder" with user "user2"
+    And user "user1" has shared file "/data.zip" with user "user2"
     When the user accepts all shares displayed in the notifications on the webUI
     Then user "user2" should have 0 notifications
 
   @smokeTest
   Scenario: accept an offered share
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been disabled
-    And user "user1" has shared folder "/simple-folder" with user "user2"
-    And user "user1" has shared folder "/simple-empty-folder" with user "user2"
+    And user "user1" has shared folder "/a-folder" with user "user2"
+    And user "user1" has shared file "/data.zip" with user "user2"
     When the user accepts all shares displayed in the notifications on the webUI
-    Then folder "simple-folder (2)" should be listed in the files page on the webUI
-    And folder "simple-empty-folder (2)" should be listed in the files page on the webUI
-    And folder "simple-folder (2)" should be in state "" in the shared-with-you page on the webUI
-    And folder "simple-empty-folder (2)" should be in state "" in the shared-with-you page on the webUI
+    Then folder "a-folder" should be listed in the files page on the webUI
+    And file "data.zip" should be listed in the files page on the webUI
+    And folder "a-folder" should be in state "" in the shared-with-you page on the webUI
+    And file "data.zip" should be in state "" in the shared-with-you page on the webUI
 
   @smokeTest
   Scenario: reject an offered share
     Given the setting "Automatically accept new incoming local user shares" in the section "Sharing" has been disabled
-    And user "user1" has shared folder "/simple-folder" with user "user2"
-    And user "user1" has shared folder "/simple-empty-folder" with user "user2"
+    And user "user1" has shared folder "/a-folder" with user "user2"
+    And user "user1" has shared file "/data.zip" with user "user2"
     When the user declines all shares displayed in the notifications on the webUI
-    Then folder "simple-folder (2)" should not be listed in the files page on the webUI
-    And folder "simple-empty-folder (2)" should not be listed in the files page on the webUI
-    And folder "simple-folder" should be in state "Declined" in the shared-with-you page on the webUI
-    And folder "simple-empty-folder" should be in state "Declined" in the shared-with-you page on the webUI
+    Then folder "a-folder" should not be listed in the files page on the webUI
+    And file "data.zip" should not be listed in the files page on the webUI
+    And folder "a-folder" should be in state "Declined" in the shared-with-you page on the webUI
+    And file "data.zip" should be in state "Declined" in the shared-with-you page on the webUI
 

From 1164dd0ff178e8e3261b1349a75a4797fd27c605 Mon Sep 17 00:00:00 2001
From: Artur Neumann <artur@jankaritech.com>
Date: Thu, 13 Jun 2019 15:08:40 +0545
Subject: [PATCH 116/131] test adding a user to a group after the group
 received a share

---
 .../createShare.feature                       | 44 +++++++++++++++++++
 .../shareWithGroups.feature                   |  2 +-
 2 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/tests/acceptance/features/apiShareManagementBasic/createShare.feature b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
index 1307285189aa..dde73b5238f3 100644
--- a/tests/acceptance/features/apiShareManagementBasic/createShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
@@ -719,6 +719,50 @@ Feature: sharing
     # Here the last response has permissions = 9 which is equivalent to permissons: read(1) + share(16)
     And as "user1" folder "zzzfolder/user2" should exist
     And as "user1" folder "zzzfolder (2)/user3" should exist
+    Examples:
+      | ocs_api_version |
+      | 1               |
+      | 2               |
+
+  @skipOnEncryptionType:user-keys @encryption-issue-132
+  Scenario Outline: share with a group and then add a user to that group
+    Given using OCS API version "<ocs_api_version>"
+    And these users have been created with default attributes and without skeleton files:
+      | username |
+      | user1    |
+      | user2    |
+    And these groups have been created:
+      | groupname |
+      | grp1      |
+    And user "user1" has been added to group "grp1"
+    And user "user0" has uploaded file with content "some content" to "lorem.txt"
+    When user "user0" shares file "lorem.txt" with group "grp1" using the sharing API
+    And the administrator adds user "user2" to group "grp1" using the provisioning API
+    Then the content of file "lorem.txt" for user "user1" should be "some content"
+    And the content of file "lorem.txt" for user "user2" should be "some content"
+    Examples:
+      | ocs_api_version |
+      | 1               |
+      | 2               |
+
+  @skipOnEncryptionType:user-keys @encryption-issue-132
+  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 "<ocs_api_version>"
+    And these users have been created with default attributes and without skeleton files:
+      | username |
+      | user1    |
+      | user2    |
+    And these groups have been created:
+      | groupname |
+      | grp1      |
+    And user "user1" has been added to group "grp1"
+    And user "user0" has uploaded file with content "user0 content" to "lorem.txt"
+    And user "user2" has uploaded file with content "user2 content" to "lorem.txt"
+    When user "user0" shares file "lorem.txt" with group "grp1" using the sharing API
+    And the administrator adds user "user2" to group "grp1" using the provisioning API
+    Then the content of file "lorem.txt" for user "user1" should be "user0 content"
+    And the content of file "lorem.txt" for user "user2" should be "user2 content"
+    And the content of file "lorem (2).txt" for user "user2" should be "user0 content"
     Examples:
       | ocs_api_version |
       | 1               |
diff --git a/tests/acceptance/features/webUISharingInternalGroups/shareWithGroups.feature b/tests/acceptance/features/webUISharingInternalGroups/shareWithGroups.feature
index 72335c54be8f..a83ccf11123a 100644
--- a/tests/acceptance/features/webUISharingInternalGroups/shareWithGroups.feature
+++ b/tests/acceptance/features/webUISharingInternalGroups/shareWithGroups.feature
@@ -207,8 +207,8 @@ Feature: Sharing files and folders with internal groups
       """
   Scenario: user added to a group has a share that matches the skeleton of added user
     Given user "user1" has uploaded file with content "some content" to "lorem.txt"
-    And user "user1" has shared file "lorem.txt" with group "grp1"
     And user "user3" has been added to group "grp1"
+    And user "user1" has shared file "lorem.txt" with group "grp1"
     When user "user3" logs in using the webUI
     Then file "lorem.txt" should be listed on the webUI
     And file "lorem (2).txt" should be listed on the webUI

From 355f15cc1b89069cfa28f6a16b8b9d3a31a6bb3b Mon Sep 17 00:00:00 2001
From: Dipak Acharya <dpakach@gmail.com>
Date: Tue, 11 Jun 2019 12:31:46 +0545
Subject: [PATCH 117/131] Add batch user creation step for speeding up the
 requests

---
 tests/TestHelpers/HttpRequestHelper.php       |  99 +++++++++++--
 tests/TestHelpers/OcsApiHelper.php            |  40 +++++
 tests/TestHelpers/UserHelper.php              |  41 +++++-
 .../apiShareManagement/acceptShares.feature   |   8 +-
 .../apiShareManagement/disableSharing.feature |   6 +-
 .../apiShareManagement/mergeShare.feature     |   6 +-
 .../moveReceivedShare.feature                 |   8 +-
 .../apiShareManagement/reShare.feature        |   6 +-
 .../features/bootstrap/Provisioning.php       | 139 +++++++++++++++---
 9 files changed, 311 insertions(+), 42 deletions(-)

diff --git a/tests/TestHelpers/HttpRequestHelper.php b/tests/TestHelpers/HttpRequestHelper.php
index 5b4da0d96b8d..c0959bbc4946 100644
--- a/tests/TestHelpers/HttpRequestHelper.php
+++ b/tests/TestHelpers/HttpRequestHelper.php
@@ -29,6 +29,8 @@
 use SimpleXMLElement;
 use Sabre\Xml\LibXMLException;
 use Sabre\Xml\Reader;
+use GuzzleHttp\BatchResults;
+use GuzzleHttp\Pool;
 
 /**
  * Helper for HTTP requests
@@ -68,6 +70,90 @@ public static function sendRequest(
 		if ($client === null) {
 			$client = new Client();
 		}
+		$request = self::createRequest(
+			$url,
+			$method,
+			$user,
+			$password,
+			$headers,
+			$body,
+			$config,
+			$cookies,
+			$stream,
+			$timeout,
+			$client
+		);
+
+		try {
+			$response = $client->send($request);
+		} catch (BadResponseException $ex) {
+			$response = $ex->getResponse();
+
+			//if the response was null for some reason do not return it but re-throw
+			if ($response === null) {
+				throw $ex;
+			}
+		}
+		return $response;
+	}
+
+	/**
+	 * Send the requests to the server in parallel.
+	 * This function takes an array of requests and an optional client.
+	 * It will send all the requests to the server using the Pool object in guzzle.
+	 *
+	 * @param array $requests
+	 * @param Client|null $client
+	 *
+	 * @return BatchResults
+	 */
+	public static function sendBatchRequest(
+		$requests,
+		$client = null
+	) {
+		if (!isset($client)) {
+			$client = new Client();
+		}
+		$results = Pool::batch($client, $requests);
+		return $results;
+	}
+
+	/**
+	 * Create an http request based on given parameters.
+	 * This creates an RequestInterface object before sending it to the server.
+	 * This also enables to create multiple requests in advance so that we can send them to the server at once in parallel.
+	 *
+	 * @param string $url
+	 * @param string $method
+	 * @param string $user
+	 * @param string $password
+	 * @param array $headers ['X-MyHeader' => 'value']
+	 * @param mixed $body
+	 * @param array $config
+	 * @param CookieJar $cookies
+	 * @param bool $stream Set to true to stream a response rather
+	 *                     than download it all up-front.
+	 * @param int $timeout
+	 * @param Client|null $client
+	 *
+	 * @return RequestInterface
+	 */
+	public static function createRequest(
+		$url,
+		$method = 'GET',
+		$user = null,
+		$password = null,
+		$headers = null,
+		$body = null,
+		$config = null,
+		$cookies = null,
+		$stream = false,
+		$timeout = 0,
+		$client = null
+	) {
+		if ($client === null) {
+			$client = new Client();
+		}
 
 		$options = [];
 		if ($user !== null) {
@@ -95,18 +181,7 @@ public static function sendRequest(
 				}
 			}
 		}
-
-		try {
-			$response = $client->send($request);
-		} catch (BadResponseException $ex) {
-			$response = $ex->getResponse();
-			
-			//if the response was null for some reason do not return it but re-throw
-			if ($response === null) {
-				throw $ex;
-			}
-		}
-		return $response;
+		return $request;
 	}
 
 	/**
diff --git a/tests/TestHelpers/OcsApiHelper.php b/tests/TestHelpers/OcsApiHelper.php
index 66900123904c..72f18ea1de53 100644
--- a/tests/TestHelpers/OcsApiHelper.php
+++ b/tests/TestHelpers/OcsApiHelper.php
@@ -21,7 +21,10 @@
  */
 namespace TestHelpers;
 
+use GuzzleHttp\BatchResults;
 use GuzzleHttp\Message\ResponseInterface;
+use GuzzleHttp\Client;
+use GuzzleHttp\Pool;
 
 /**
  * Helper to make requests to the OCS API
@@ -53,4 +56,41 @@ public static function sendRequest(
 
 		return HttpRequestHelper::sendRequest($fullUrl, $method, $user, $password, $headers, $body);
 	}
+
+	/**
+	 *
+	 * @param string $baseUrl
+	 * @param string $user if set to null no authentication header will be sent
+	 * @param string $password
+	 * @param string $method HTTP Method
+	 * @param string $path
+	 * @param array $body array of key, value pairs e.g ['value' => 'yes']
+	 * @param Client|null $client
+	 * @param int $ocsApiVersion (1|2) default 2
+	 * @param array $headers
+	 *
+	 * @return RequestInterface
+	 */
+	public static function createOcsRequest(
+		$baseUrl, $user, $password, $method, $path, $body = [], $client = null, $ocsApiVersion = 2, $headers = []
+	) {
+		$fullUrl = $baseUrl;
+		if (\substr($fullUrl, -1) !== '/') {
+			$fullUrl .= '/';
+		}
+		$fullUrl .= "ocs/v{$ocsApiVersion}.php" . $path;
+		return HttpRequestHelper::createRequest(
+			$fullUrl,
+			$method,
+			$user,
+			$password,
+			$headers,
+			$body,
+			null,
+			null,
+			null,
+			null,
+			$client
+		);
+	}
 }
diff --git a/tests/TestHelpers/UserHelper.php b/tests/TestHelpers/UserHelper.php
index f6ab7927a680..b8a649729e4c 100644
--- a/tests/TestHelpers/UserHelper.php
+++ b/tests/TestHelpers/UserHelper.php
@@ -21,7 +21,9 @@
  */
 namespace TestHelpers;
 
+use GuzzleHttp\BatchResults;
 use GuzzleHttp\Message\ResponseInterface;
+use GuzzleHttp\Client;
 
 /**
  * Helper to administrate users (and groups) through the provisioning API
@@ -30,7 +32,6 @@
  *
  */
 class UserHelper {
-	
 	/**
 	 * @param string $baseUrl
 	 * @param string $user
@@ -103,6 +104,44 @@ public static function editUser(
 		);
 	}
 
+	/**
+	 * Send batch requests to edit the user.
+	 * This will send multiple requests in parallel to the server which will be faster in comparison to waiting for each request to complete.
+	 *
+	 * @param string $baseUrl
+	 * @param array $editData ['user' => '', 'key' => '', 'value' => '']
+	 * @param string $adminUser
+	 * @param string $adminPassword
+	 * @param int $ocsApiVersion
+	 *
+	 * @return BatchResults
+	 */
+	public static function editUserBatch(
+		$baseUrl, $editData, $adminUser, $adminPassword, $ocsApiVersion = 2
+	) {
+		$client = new Client();
+		$requests = [];
+		foreach ($editData as $data) {
+			$path = "/cloud/users/" . $data['user'];
+			$body = ["key" => $data['key'], 'value' => $data["value"]];
+			// Create the OCS API requests and push them to an array.
+			\array_push(
+				$requests,
+				OcsApiHelper::createOcsRequest(
+					$baseUrl,
+					$adminUser,
+					$adminPassword,
+					'PUT',
+					$path,
+					$body,
+					$client
+				)
+			);
+		}
+		// Send the array of requests at once in parallel.
+		return HttpRequestHelper::sendBatchRequest($requests, $client);
+	}
+
 	/**
 	 *
 	 * @param string $baseUrl
diff --git a/tests/acceptance/features/apiShareManagement/acceptShares.feature b/tests/acceptance/features/apiShareManagement/acceptShares.feature
index 1fdb38588b8a..5c905cb6abae 100644
--- a/tests/acceptance/features/apiShareManagement/acceptShares.feature
+++ b/tests/acceptance/features/apiShareManagement/acceptShares.feature
@@ -7,9 +7,11 @@ Feature: accept/decline shares coming from internal users
   Background:
     Given using OCS API version "1"
     And using new DAV path
-    And user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
-    And user "user2" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
+      | user2    |
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
     And user "user2" has been added to group "grp1"
diff --git a/tests/acceptance/features/apiShareManagement/disableSharing.feature b/tests/acceptance/features/apiShareManagement/disableSharing.feature
index 7f98007c687a..921018bee6a7 100644
--- a/tests/acceptance/features/apiShareManagement/disableSharing.feature
+++ b/tests/acceptance/features/apiShareManagement/disableSharing.feature
@@ -6,8 +6,10 @@ Feature: sharing
 
   Background:
     Given using old DAV path
-    And user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
 
   @smokeTest
   Scenario Outline: user tries to share a file with another user when the sharing api has been disabled
diff --git a/tests/acceptance/features/apiShareManagement/mergeShare.feature b/tests/acceptance/features/apiShareManagement/mergeShare.feature
index 858375e2250d..49bd70216fdb 100644
--- a/tests/acceptance/features/apiShareManagement/mergeShare.feature
+++ b/tests/acceptance/features/apiShareManagement/mergeShare.feature
@@ -4,8 +4,10 @@ Feature: sharing
   Background:
     Given using OCS API version "1"
     And using old DAV path
-    And user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
 
diff --git a/tests/acceptance/features/apiShareManagement/moveReceivedShare.feature b/tests/acceptance/features/apiShareManagement/moveReceivedShare.feature
index de65ee327fc7..a9bc2636d6da 100644
--- a/tests/acceptance/features/apiShareManagement/moveReceivedShare.feature
+++ b/tests/acceptance/features/apiShareManagement/moveReceivedShare.feature
@@ -4,9 +4,11 @@ Feature: sharing
   Background:
     Given using OCS API version "1"
     And using old DAV path
-    And user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
-    And user "user2" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
+      | user2    |
 
   Scenario: Keep usergroup shares (#22143)
     Given group "grp1" has been created
diff --git a/tests/acceptance/features/apiShareManagement/reShare.feature b/tests/acceptance/features/apiShareManagement/reShare.feature
index 09354bc74f43..508d5f5f5951 100644
--- a/tests/acceptance/features/apiShareManagement/reShare.feature
+++ b/tests/acceptance/features/apiShareManagement/reShare.feature
@@ -3,8 +3,10 @@ Feature: sharing
 
   Background:
     Given using old DAV path
-    And user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
 
   Scenario Outline: User is not allowed to reshare file
     Given using OCS API version "<ocs_api_version>"
diff --git a/tests/acceptance/features/bootstrap/Provisioning.php b/tests/acceptance/features/bootstrap/Provisioning.php
index ab74eb59f52e..3b6b6362ed27 100644
--- a/tests/acceptance/features/bootstrap/Provisioning.php
+++ b/tests/acceptance/features/bootstrap/Provisioning.php
@@ -25,6 +25,7 @@
 use TestHelpers\SetupHelper;
 use TestHelpers\UserHelper;
 use TestHelpers\HttpRequestHelper;
+use GuzzleHttp\Client;
 
 require __DIR__ . '/../../../../lib/composer/autoload.php';
 
@@ -347,47 +348,113 @@ public function theseUsersHaveBeenCreatedWithoutSkeletonFiles(TableNode $table)
 
 	/**
 	 * @Given /^these users have been created with ?(default attributes and|) skeleton files ?(but not initialized|):$/
+	 * This function will allow us to send user creation requests in parallel.
+	 * This will be faster in comparision to waiting for each request to complete before sending another request.
+	 *
 	 * expects a table of users with the heading
 	 * "|username|password|displayname|email|"
 	 * password, displayname & email are optional
 	 *
-	 * @param string $setDefaultAttributes just set the defaults if it doesn't exist
-	 * @param string $doNotInitialize just create the user, do not trigger creating skeleton files etc
+	 * @param string $setDefaultAttributes
+	 * @param string $doNotInitialize
 	 * @param TableNode $table
 	 *
 	 * @return void
 	 * @throws \Exception
 	 */
 	public function theseUsersHaveBeenCreated($setDefaultAttributes, $doNotInitialize, TableNode $table) {
+		$table = $table->getColumnsHash();
+		$setDefaultAttributes = $setDefaultAttributes !== "";
+		$initialize = $doNotInitialize === "";
+		// We add all the request bodies in an array.
+		$bodies = [];
+		// We add all the request objects in an array so that we can send all the requests in parallel.
+		$requests = [];
+		$client = new Client();
 		foreach ($table as $row) {
+			$body['userid'] = $this->getActualUsername($row['username']);
+
 			if (isset($row['displayname'])) {
-				$displayName = $row['displayname'];
+				$body['displayName'] = $row['displayname'];
+			} elseif ($setDefaultAttributes) {
+				$body['displayName'] = $this->getDisplayNameForUser($body['userid']);
+				if ($body['displayName'] === null) {
+					$body['displayName'] = $this->getDisplayNameForUser('regularuser');
+				}
 			} else {
-				$displayName = null;
+				$body['displayName'] = null;
 			}
 
 			if (isset($row['email'])) {
-				$email = $row['email'];
+				$body['email'] = $row['email'];
+			} elseif ($setDefaultAttributes) {
+				$body['email'] = $this->getEmailAddressForUser($body['userid']);
+				if ($body['email'] === null) {
+					$body['email'] = $row['username'] . '@owncloud.org';
+				}
 			} else {
-				$email = null;
+				$body['email'] = null;
 			}
 
 			if (isset($row['password'])) {
-				$password = $this->getActualPassword($row['password']);
+				$body['password'] = $this->getActualPassword($row['password']);
 			} else {
-				// Let createUser() select the password
-				$password = null;
+				$body['password'] =  $this->getPasswordForUser($row['username']);
 			}
 
-			$this->createUser(
-				$row ['username'],
-				$password,
-				$displayName,
-				$email,
-				($doNotInitialize === ""),
-				null,
-				!($setDefaultAttributes === "")
+			// Add request body to the bodies array. we will use that later to loop through created users.
+			\array_push($bodies, $body);
+
+			// Create a OCS request for creating the user. The request is not sent to the server yet.
+			$request = OcsApiHelper::createOcsRequest(
+				$this->getBaseUrl(),
+				$this->getAdminUsername(),
+				$this->getAdminPassword(),
+				'POST',
+				"/cloud/users",
+				$body,
+				$client
 			);
+			// Add the request to the $requests array so that they can be sent in parallel.
+			\array_push($requests, $request);
+		}
+
+		$results = HttpRequestHelper::sendBatchRequest($requests, $client);
+		// Retrieve all failures.
+		foreach ($results->getFailures() as $e) {
+			throw $e;
+		}
+
+		// Create requests for setting displayname and email for the newly created users.
+		// These values cannot be set while creating the user, so we have to edit the newly created user to set these values.
+		$users = [];
+		$editData = [];
+		foreach ($bodies as $user) {
+			\array_push($users, $user['userid']);
+			$this->addUserToCreatedUsersList($user['userid'], $user['password'], $user['displayName'], $user['email']);
+			if (isset($user['displayName'])) {
+				\array_push($editData, ['user' => $user['userid'], 'key' => 'displayname', 'value' => $user['displayName']]);
+			}
+			if (isset($user['email'])) {
+				\array_push($editData, ['user' => $user['userid'], 'key' => 'email', 'value' => $user['email']]);
+			}
+		}
+		// Edit the users in parallel to make the process faster.
+		if (\count($editData) > 0) {
+			$results = UserHelper::editUserBatch(
+				$this->getBaseUrl(),
+				$editData,
+				$this->getAdminUsername(),
+				$this->getAdminPassword()
+			);
+			foreach ($results->getFailures() as $e) {
+				throw new \Exception("Could not edit user\n" . $e->getMessage());
+			}
+		}
+
+		// If the users need to be initialized then initialize them in parallel.
+		if ($initialize) {
+			$this->initializeUserBatch($users);
 		}
 	}
 
@@ -1209,6 +1276,44 @@ public function initializeUser($user, $password) {
 		$this->lastUploadTime = \time();
 	}
 
+	/**
+	 * Make a request about the users to initialize them in parallel.
+	 * This will be faster than sequential requests to initialize the users.
+	 * That will force the server to fully initialize the users, including their skeleton files.
+	 *
+	 * @param array $users
+	 *
+	 * @return void
+	 * @throws \Exception
+	 */
+	public function initializeUserBatch($users) {
+		$url = "/cloud/users/%s";
+		$requests = [];
+		$client = new Client();
+		foreach ($users as $user) {
+			// create a new request for each user but do not send it yet.
+			// push the newly created request to an array.
+			\array_push(
+				$requests,
+				OcsApiHelper::createOcsRequest(
+					$this->getBaseUrl(),
+					$user,
+					$this->getPasswordForUser($user),
+					$method = 'GET',
+					\sprintf($url, $user),
+					[],
+					$client
+				)
+			);
+		}
+		// Send all the requests in parallel.
+		$response = HttpRequestHelper::sendBatchRequest($requests, $client);
+		// throw an exception if any request fails.
+		foreach ($response->getFailures() as $e) {
+			throw new \Exception("Could not initialize user\n" . $e->getMessage());
+		}
+	}
+
 	/**
 	 * adds a user to the list of users that were created during test runs
 	 * makes it possible to use this list in other test steps

From 8ad608486947ad245ace4f39e9614784a6fbae25 Mon Sep 17 00:00:00 2001
From: paurakhsharma <paurakh011@gmail.com>
Date: Wed, 12 Jun 2019 16:37:30 +0545
Subject: [PATCH 118/131] Use no skeleton files on webUIPersonalSettings

---
 .../accessToChangeFullNameThroughConfig.feature  | 12 ++++++------
 .../changeOwnEmailAddress.feature                |  2 +-
 .../changeOwnFullName.feature                    |  4 ++--
 .../changePasswordFromSetting.feature            |  2 +-
 .../personalGeneralSettings.feature              | 16 +++++++++++-----
 .../personalSecuritySettings.feature             |  2 +-
 6 files changed, 22 insertions(+), 16 deletions(-)

diff --git a/tests/acceptance/features/webUIPersonalSettings/accessToChangeFullNameThroughConfig.feature b/tests/acceptance/features/webUIPersonalSettings/accessToChangeFullNameThroughConfig.feature
index 97f853a25941..df21e8dc7832 100644
--- a/tests/acceptance/features/webUIPersonalSettings/accessToChangeFullNameThroughConfig.feature
+++ b/tests/acceptance/features/webUIPersonalSettings/accessToChangeFullNameThroughConfig.feature
@@ -4,9 +4,11 @@ Feature: Control access to edit fullname of user through config file
   I want to control the access to users to edit their fullname in settings page
   So that users can edit their fullname after getting permission from administrator
 
-  Scenario: Admin gives access to users to change their full name
-    Given user "user1" has been created with default attributes and skeleton files
+  Background:
+    Given user "user1" has been created with default attributes and without skeleton files
     And user "user1" has logged in using the webUI
+
+  Scenario: Admin gives access to users to change their full name
     When the administrator updates system config key "allow_user_to_change_display_name" with value "true" and type "boolean" using the occ command
     And the user browses to the personal general settings page
     And the user changes the full name to "my#very&weird?नेपालि%name" using the webUI
@@ -15,9 +17,7 @@ Feature: Control access to edit fullname of user through config file
     And the attributes of user "user1" returned by the API should include
       | displayname | my#very&weird?नेपालि%name |
 
-  Scenario: Admin doesnot give access to users to change their full name
-    Given user "user1" has been created with default attributes and skeleton files
-    And user "user1" has logged in using the webUI
+  Scenario: Admin does not give access to users to change their full 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 user browses to the personal general settings page
-    Then the user should not be able to change the full name using the webUI
\ No newline at end of file
+    Then the user should not be able to change the full name using the webUI
diff --git a/tests/acceptance/features/webUIPersonalSettings/changeOwnEmailAddress.feature b/tests/acceptance/features/webUIPersonalSettings/changeOwnEmailAddress.feature
index 08fafc260f07..a0d192226e73 100644
--- a/tests/acceptance/features/webUIPersonalSettings/changeOwnEmailAddress.feature
+++ b/tests/acceptance/features/webUIPersonalSettings/changeOwnEmailAddress.feature
@@ -5,7 +5,7 @@ Feature: Change own email address on the personal settings page
   So that I can be reached by the owncloud server
 
   Background:
-    Given user "user1" has been created with default attributes and skeleton files
+    Given user "user1" has been created with default attributes and without skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the personal general settings page
 
diff --git a/tests/acceptance/features/webUIPersonalSettings/changeOwnFullName.feature b/tests/acceptance/features/webUIPersonalSettings/changeOwnFullName.feature
index 1d0a958910a7..406cc28bbdaf 100644
--- a/tests/acceptance/features/webUIPersonalSettings/changeOwnFullName.feature
+++ b/tests/acceptance/features/webUIPersonalSettings/changeOwnFullName.feature
@@ -5,7 +5,7 @@ Feature: Change own full name on the personal settings page
   So that other users can recognize me by it
 
   Background:
-    Given user "user1" has been created with default attributes and skeleton files
+    Given user "user1" has been created with default attributes and without skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the personal general settings page
 
@@ -15,4 +15,4 @@ Feature: Change own full name on the personal settings page
     And the user reloads the current page of the webUI
     Then "my#very&weird?नेपालि%name" should be shown as the name of the current user on the WebUI
     And the attributes of user "user1" returned by the API should include
-      | displayname | my#very&weird?नेपालि%name |
\ No newline at end of file
+      | displayname | my#very&weird?नेपालि%name |
diff --git a/tests/acceptance/features/webUIPersonalSettings/changePasswordFromSetting.feature b/tests/acceptance/features/webUIPersonalSettings/changePasswordFromSetting.feature
index 26ceca9f4785..0539fcdb4383 100644
--- a/tests/acceptance/features/webUIPersonalSettings/changePasswordFromSetting.feature
+++ b/tests/acceptance/features/webUIPersonalSettings/changePasswordFromSetting.feature
@@ -5,7 +5,7 @@ Feature: Change Login Password
   So that I can login with my new password
 
   Background:
-    Given user "user1" has been created with default attributes and skeleton files
+    Given user "user1" has been created with default attributes and without skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the personal general settings page
 
diff --git a/tests/acceptance/features/webUIPersonalSettings/personalGeneralSettings.feature b/tests/acceptance/features/webUIPersonalSettings/personalGeneralSettings.feature
index e3a45922b1af..59935a19940e 100644
--- a/tests/acceptance/features/webUIPersonalSettings/personalGeneralSettings.feature
+++ b/tests/acceptance/features/webUIPersonalSettings/personalGeneralSettings.feature
@@ -5,7 +5,7 @@ Feature: personal general settings
   So that I can personalise the User Interface
 
   Background:
-    Given user "user1" has been created with default attributes and skeleton files
+    Given user "user1" has been created with default attributes and without skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the personal general settings page
 
@@ -15,6 +15,7 @@ Feature: personal general settings
     Then the user should be redirected to a webUI page with the title "Настройки - %productname%"
 
   Scenario: change language and check that file actions menu have been translated
+    Given the user has created folder "simple-folder"
     When the user changes the language to "हिन्दी" using the webUI
     And the user browses to the files page
     And the user opens the file action menu of folder "simple-folder" on the webUI
@@ -22,6 +23,7 @@ Feature: personal general settings
     And the user should see "Delete" file action translated to "हटाना" on the webUI
 
   Scenario: change language using the occ command and check that file actions menu have been translated
+    Given the user has created folder "simple-folder"
     When the administrator changes the language of user "user1" to "fr" using the occ command
     And the user browses to the files page
     And the user opens the file action menu of folder "simple-folder" on the webUI
@@ -29,6 +31,7 @@ Feature: personal general settings
     And the user should see "Delete" file action translated to "Supprimer" on the webUI
 
   Scenario: change language to invalid language using the occ command and check that the language defaults back to english
+    Given the user has created folder "simple-folder"
     When the administrator changes the language of user "user1" to "not-valid-lan" using the occ command
     And the user browses to the files page
     And the user opens the file action menu of folder "simple-folder" on the webUI
@@ -47,17 +50,20 @@ Feature: personal general settings
     And group "another-group" should be displayed on the personal general settings page on the webUI
 
   Scenario: User sets profile picture from their existing cloud file
-    Given the user has deleted any existing profile picture
+    Given user "user1" has uploaded file "filesForUpload/testavatar.jpg" to "/testimage.jpg"
+    And the user has deleted any existing profile picture
     When the user sets profile picture to "testimage.jpg" from their cloud files using the webUI
     Then the preview of the profile picture should be shown on the webUI
 
   Scenario: User deletes the existing profile picture
-    Given the user has set profile picture to "testimage.jpg" from their cloud files
+    Given user "user1" has uploaded file "filesForUpload/testavatar.jpg" to "/testimage.jpg"
+    And the user has set profile picture to "testimage.jpg" from their cloud files
     When the user deletes the existing profile picture
     Then the preview of the profile picture should not be shown on the webUI
 
   Scenario: User uploads new profile picture
-    Given the user has deleted any existing profile picture
+    Given user "user1" has uploaded file "filesForUpload/testavatar.jpg" to "/testimage.jpg"
+    And the user has deleted any existing profile picture
     When the user uploads "testavatar.png" as a new profile picture using the webUI
     Then the preview of the profile picture should be shown on the webUI
 
@@ -73,4 +79,4 @@ Feature: personal general settings
       | new-lorem.txt  | should not    |
       | simple.pdf     | should not    |
       | simple.odt     | should not    |
-      | data.tar.gz    | should not    |
\ No newline at end of file
+      | data.tar.gz    | should not    |
diff --git a/tests/acceptance/features/webUIPersonalSettings/personalSecuritySettings.feature b/tests/acceptance/features/webUIPersonalSettings/personalSecuritySettings.feature
index f0f163536f35..fac2c8ab2df3 100644
--- a/tests/acceptance/features/webUIPersonalSettings/personalSecuritySettings.feature
+++ b/tests/acceptance/features/webUIPersonalSettings/personalSecuritySettings.feature
@@ -5,7 +5,7 @@ Feature: personal security settings
   So that I can enable, allow and deny access to and from other storage systems or resources
 
   Background:
-    Given user "user1" has been created with default attributes and skeleton files
+    Given user "user1" has been created with default attributes and without skeleton files
     And user "user1" has logged in using the webUI
     And the user has browsed to the personal security settings page
 

From 490b2ff54e69f723fa134287bcf5694938950a0e Mon Sep 17 00:00:00 2001
From: Dipak Acharya <dpakach@gmail.com>
Date: Thu, 13 Jun 2019 15:46:59 +0545
Subject: [PATCH 119/131] Create multiple users in single steps in acceptance
 test feature files

---
 .../apiComments/createComments.feature        |  6 ++--
 .../apiComments/deleteComments.feature        |  6 ++--
 .../features/apiComments/editComments.feature |  6 ++--
 .../features/apiMain/external-storage.feature | 18 ++++++----
 .../acceptance/features/apiMain/quota.feature | 36 ++++++++++++-------
 .../apiProvisioningUsingAppPassword.feature   | 18 ++++++----
 .../apiProvisioning-v1/createSubAdmin.feature |  6 ++--
 .../apiProvisioning-v1/deleteUser.feature     | 12 ++++---
 .../apiProvisioning-v1/disableUser.feature    | 24 ++++++++-----
 .../apiProvisioning-v1/editUser.feature       |  6 ++--
 .../apiProvisioning-v1/enableUser.feature     |  6 ++--
 .../apiProvisioning-v1/getSubAdmins.feature   | 12 ++++---
 .../apiProvisioning-v1/getUser.feature        | 12 ++++---
 .../apiProvisioning-v1/getUsers.feature       | 12 ++++---
 .../apiProvisioning-v1/removeSubAdmin.feature | 12 ++++---
 .../apiProvisioningUsingAppPassword.feature   | 20 +++++++----
 .../apiProvisioning-v2/createSubAdmin.feature |  6 ++--
 .../apiProvisioning-v2/deleteUser.feature     | 12 ++++---
 .../apiProvisioning-v2/disableUser.feature    | 24 ++++++++-----
 .../apiProvisioning-v2/editUser.feature       |  6 ++--
 .../apiProvisioning-v2/enableUser.feature     |  6 ++--
 .../apiProvisioning-v2/getSubAdmins.feature   | 12 ++++---
 .../apiProvisioning-v2/getUser.feature        | 12 ++++---
 .../apiProvisioning-v2/getUsers.feature       | 12 ++++---
 .../apiProvisioning-v2/removeSubAdmin.feature | 12 ++++---
 25 files changed, 209 insertions(+), 105 deletions(-)

diff --git a/tests/acceptance/features/apiComments/createComments.feature b/tests/acceptance/features/apiComments/createComments.feature
index 3afb74021593..885647ae8d54 100644
--- a/tests/acceptance/features/apiComments/createComments.feature
+++ b/tests/acceptance/features/apiComments/createComments.feature
@@ -3,8 +3,10 @@ Feature: Comments
 
   Background:
     Given using new DAV path
-    And user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
     And as user "user0"
 
   @smokeTest
diff --git a/tests/acceptance/features/apiComments/deleteComments.feature b/tests/acceptance/features/apiComments/deleteComments.feature
index 1ac589600a57..e5efc6366f96 100644
--- a/tests/acceptance/features/apiComments/deleteComments.feature
+++ b/tests/acceptance/features/apiComments/deleteComments.feature
@@ -3,8 +3,10 @@ Feature: Comments
 
   Background:
     Given using new DAV path
-    And user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
     And as user "user0"
 
   @smokeTest
diff --git a/tests/acceptance/features/apiComments/editComments.feature b/tests/acceptance/features/apiComments/editComments.feature
index c87bf8ac96ae..20483f6c2599 100644
--- a/tests/acceptance/features/apiComments/editComments.feature
+++ b/tests/acceptance/features/apiComments/editComments.feature
@@ -3,8 +3,10 @@ Feature: Comments
 
   Background:
     Given using new DAV path
-    And user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
     And as user "user0"
 
   @smokeTest
diff --git a/tests/acceptance/features/apiMain/external-storage.feature b/tests/acceptance/features/apiMain/external-storage.feature
index def7226a9529..f4067bb34872 100644
--- a/tests/acceptance/features/apiMain/external-storage.feature
+++ b/tests/acceptance/features/apiMain/external-storage.feature
@@ -7,8 +7,10 @@ Feature: external-storage
 
   @public_link_share-feature-required
   Scenario: Share by public link a file inside a local external storage
-    Given user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
     And user "user0" has created folder "/local_storage/foo"
     And user "user0" has moved file "/textfile0.txt" to "/local_storage/foo/textfile0.txt"
     And user "user0" has shared folder "/local_storage/foo" with user "user1"
@@ -23,16 +25,20 @@ Feature: external-storage
       | mimetype | httpd/unix-directory |
 
   Scenario: Move a file into storage
-    Given user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
     And user "user0" has created folder "/local_storage/foo1"
     When user "user0" moves file "/textfile0.txt" to "/local_storage/foo1/textfile0.txt" using the WebDAV API
     Then as "user1" file "/local_storage/foo1/textfile0.txt" should exist
     And as "user0" file "/local_storage/foo1/textfile0.txt" should exist
 
   Scenario: Move a file out of storage
-    Given user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
     And user "user0" has created folder "/local_storage/foo2"
     And user "user0" has moved file "/textfile0.txt" to "/local_storage/foo2/textfile0.txt"
     When user "user1" moves file "/local_storage/foo2/textfile0.txt" to "/local.txt" using the WebDAV API
diff --git a/tests/acceptance/features/apiMain/quota.feature b/tests/acceptance/features/apiMain/quota.feature
index 6be9d50f8796..f89a5eda26d8 100644
--- a/tests/acceptance/features/apiMain/quota.feature
+++ b/tests/acceptance/features/apiMain/quota.feature
@@ -59,8 +59,10 @@ Feature: quota
 
   Scenario Outline: Uploading a file in received folder having enough quota
     Given using <dav_version> DAV path
-    And user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
     And the quota of user "user0" has been set to "20 B"
     And the quota of user "user1" has been set to "10 MB"
     And user "user1" has created folder "/testquota"
@@ -74,8 +76,10 @@ Feature: quota
 
   Scenario Outline: Uploading a file in received folder having insufficient quota
     Given using <dav_version> DAV path
-    And user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
     And the quota of user "user0" has been set to "10 MB"
     And the quota of user "user1" has been set to "20 B"
     And user "user1" has created folder "/testquota"
@@ -90,8 +94,10 @@ Feature: quota
 
   Scenario Outline: Overwriting a file in received folder having enough quota
     Given using <dav_version> DAV path
-    And user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
     And the quota of user "user0" has been set to "20 B"
     And the quota of user "user1" has been set to "10 MB"
     And user "user1" has created folder "/testquota"
@@ -106,8 +112,10 @@ Feature: quota
 
   Scenario Outline: Overwriting a file in received folder having insufficient quota
     Given using <dav_version> DAV path
-    And user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
     And the quota of user "user0" has been set to "10 MB"
     And the quota of user "user1" has been set to "20 B"
     And user "user1" has created folder "/testquota"
@@ -125,8 +133,10 @@ Feature: quota
 
   Scenario Outline: Overwriting a received file having enough quota
     Given using <dav_version> DAV path
-    And user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
     And the quota of user "user0" has been set to "20 B"
     And the quota of user "user1" has been set to "10 MB"
     And user "user1" has uploaded file with content "test" to "/testquota.txt"
@@ -140,8 +150,10 @@ Feature: quota
 
   Scenario Outline: Overwriting a received file having insufficient quota
     Given using <dav_version> DAV path
-    And user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
     And the quota of user "user0" has been set to "10 MB"
     And the quota of user "user1" has been set to "20 B"
     And user "user1" has moved file "/textfile0.txt" to "/testquota.txt"
diff --git a/tests/acceptance/features/apiProvisioning-v1/apiProvisioningUsingAppPassword.feature b/tests/acceptance/features/apiProvisioning-v1/apiProvisioningUsingAppPassword.feature
index f7dd240d660a..a4ce11658905 100644
--- a/tests/acceptance/features/apiProvisioning-v1/apiProvisioningUsingAppPassword.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/apiProvisioningUsingAppPassword.feature
@@ -19,8 +19,10 @@ Feature: access user provisioning API using app password
     And user "brand-new-user" should not exist
 
   Scenario: subadmin gets users in their group
-    Given user "brand-new-user" has been created with default attributes and skeleton files
-    And user "another-new-user" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username         |
+      | brand-new-user   |
+      | another-new-user |
     And group "new-group" has been created
     And user "another-new-user" has been added to group "new-group"
     And user "brand-new-user" has been made a subadmin of group "new-group"
@@ -45,8 +47,10 @@ Feature: access user provisioning API using app password
     And the display name returned by the API should be "New User"
 
   Scenario: subadmin tries to get users of other group
-    Given user "brand-new-user" has been created with default attributes and skeleton files
-    And user "another-new-user" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username         |
+      | brand-new-user   |
+      | another-new-user |
     And group "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"
@@ -59,8 +63,10 @@ Feature: access user provisioning API using app password
     And the HTTP status code should be "200"
 
   Scenario: normal user tries to get other user information using the app password
-    Given user "newuser" has been created with default attributes and skeleton files
-    And user "anotheruser" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username    |
+      | newuser     |
+      | anotheruser |
     And a new client token for "newuser" has been generated
     And a new browser session for "newuser" has been started
     And the user has generated a new app password named "my-client"
diff --git a/tests/acceptance/features/apiProvisioning-v1/createSubAdmin.feature b/tests/acceptance/features/apiProvisioning-v1/createSubAdmin.feature
index 97f8c5ab2ed7..cf913c65b774 100644
--- a/tests/acceptance/features/apiProvisioning-v1/createSubAdmin.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/createSubAdmin.feature
@@ -33,8 +33,10 @@ Feature: create a subadmin
     And the API should not return any data
 
   Scenario: subadmin of a group tries to make another user subadmin of their group
-    Given user "subadmin" has been created with default attributes and skeleton files
-    And user "brand-new-user" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and 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"
     And user "brand-new-user" has been added to group "new-group"
diff --git a/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature b/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature
index ac4be9a945ef..68707f416061 100644
--- a/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/deleteUser.feature
@@ -24,8 +24,10 @@ Feature: delete users
 
   @smokeTest
   Scenario: subadmin deletes a user in their group
-    Given user "subadmin" has been created with default attributes and skeleton files
-    And user "brand-new-user" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and 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"
@@ -35,8 +37,10 @@ Feature: delete users
     And user "brand-new-user" should not exist
 
   Scenario: normal user tries to delete a user
-    Given user "user1" has been created with default attributes and skeleton files
-    And user "user2" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username |
+      | user1    |
+      | user2    |
     When user "user1" deletes user "user2" 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/apiProvisioning-v1/disableUser.feature b/tests/acceptance/features/apiProvisioning-v1/disableUser.feature
index ac7e993bde9f..691a6a9100e5 100644
--- a/tests/acceptance/features/apiProvisioning-v1/disableUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/disableUser.feature
@@ -17,8 +17,10 @@ Feature: disable user
 
   @smokeTest
   Scenario: Subadmin should be able to disable an user in their group
-    Given user "subadmin" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username |
+      | user1    |
+      | subadmin |
     And group "new-group" has been created
     And user "subadmin" has been added to group "new-group"
     And user "user1" has been added to group "new-group"
@@ -29,8 +31,10 @@ Feature: disable user
     And user "user1" should be disabled
 
   Scenario: Subadmin should not be able to disable an user not in their group
-    Given user "subadmin" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username |
+      | user1    |
+      | subadmin |
     And group "new-group" has been created
     And group "another-group" has been created
     And user "subadmin" has been added to group "new-group"
@@ -42,8 +46,10 @@ Feature: disable user
     And user "user1" should be enabled
 
   Scenario: Subadmins should not be able to disable users that have admin permissions in their group
-    Given user "another-admin" has been created with default attributes and skeleton files
-    And user "subadmin" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username      |
+      | subadmin      |
+      | another-admin |
     And group "new-group" has been created
     And user "another-admin" has been added to group "admin"
     And user "subadmin" has been added to group "new-group"
@@ -82,8 +88,10 @@ Feature: disable user
     And user "another-admin" should be enabled
 
   Scenario: disable an user with a regular user
-    Given user "user1" has been created with default attributes and skeleton files
-    And user "user2" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username |
+      | user1    |
+      | user2    |
     When user "user1" disables user "user2" 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/apiProvisioning-v1/editUser.feature b/tests/acceptance/features/apiProvisioning-v1/editUser.feature
index 797fa6c896b4..0485672bb8f3 100644
--- a/tests/acceptance/features/apiProvisioning-v1/editUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/editUser.feature
@@ -50,8 +50,10 @@ Feature: edit users
 
   @smokeTest
   Scenario: a subadmin should be able to edit the user information in their group
-    Given user "subadmin" has been created with default attributes and skeleton files
-    And user "brand-new-user" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and 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"
diff --git a/tests/acceptance/features/apiProvisioning-v1/enableUser.feature b/tests/acceptance/features/apiProvisioning-v1/enableUser.feature
index f9724041ed9d..f2798a5112b0 100644
--- a/tests/acceptance/features/apiProvisioning-v1/enableUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/enableUser.feature
@@ -45,8 +45,10 @@ Feature: enable user
     Then user "another-admin" should be disabled
 
   Scenario: normal user tries to enable other user
-    Given user "user1" has been created with default attributes and skeleton files
-    And user "user2" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username |
+      | user1    |
+      | user2    |
     And user "user2" has been disabled
     When user "user1" tries to enable user "user2" using the provisioning API
     Then the OCS status code should be "997"
diff --git a/tests/acceptance/features/apiProvisioning-v1/getSubAdmins.feature b/tests/acceptance/features/apiProvisioning-v1/getSubAdmins.feature
index b0382033e1c9..e86c2b95429b 100644
--- a/tests/acceptance/features/apiProvisioning-v1/getSubAdmins.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/getSubAdmins.feature
@@ -27,8 +27,10 @@ Feature: get subadmins
     And the API should not return any data
 
   Scenario: subadmin tries to get other subadmins of the same group
-    Given user "subadmin" has been created with default attributes and skeleton files
-    And user "newsubadmin" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username    |
+      | subadmin    |
+      | newsubadmin |
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     And user "newsubadmin" has been made a subadmin of group "new-group"
@@ -38,8 +40,10 @@ Feature: get subadmins
     And the API should not return any data
 
   Scenario: normal user tries to get the subadmins of the group
-    Given user "newuser" has been created with default attributes and skeleton files
-    And user "subadmin" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username    |
+      | subadmin    |
+      | newuser     |
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     When user "newuser" gets all the subadmins of group "new-group" using the provisioning API
diff --git a/tests/acceptance/features/apiProvisioning-v1/getUser.feature b/tests/acceptance/features/apiProvisioning-v1/getUser.feature
index f64d326ea846..9bce792b64d5 100644
--- a/tests/acceptance/features/apiProvisioning-v1/getUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/getUser.feature
@@ -40,8 +40,10 @@ Feature: get user
     And the quota definition returned by the API should be "default"
 
   Scenario: a subadmin tries to get information of a user not in their group
-    Given user "subadmin" has been created with default attributes and skeleton files
-    And user "newuser" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username |
+      | subadmin |
+      | newuser  |
     And group "newgroup" has been created
     And user "subadmin" has been made a subadmin of group "newgroup"
     When user "subadmin" retrieves the information of user "newuser" using the provisioning API
@@ -50,8 +52,10 @@ Feature: get user
     And the API should not return any data
 
   Scenario: a normal user tries to get information of another user
-    Given user "newuser" has been created with default attributes and skeleton files
-    And user "anotheruser" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username    |
+      | newuser     |
+      | anotheruser |
     When user "anotheruser" retrieves the information of user "newuser" using the provisioning API
     Then the OCS status code should be "997"
     And the HTTP status code should be "401"
diff --git a/tests/acceptance/features/apiProvisioning-v1/getUsers.feature b/tests/acceptance/features/apiProvisioning-v1/getUsers.feature
index 6da886b0ef02..b4455474528a 100644
--- a/tests/acceptance/features/apiProvisioning-v1/getUsers.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/getUsers.feature
@@ -19,8 +19,10 @@ Feature: get users
 
   @smokeTest
   Scenario: subadmin gets the users in their group
-    Given user "brand-new-user" has been created with default attributes and skeleton files
-    And user "another-new-user" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username         |
+      | brand-new-user   |
+      | another-new-user |
     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"
@@ -31,8 +33,10 @@ Feature: get users
     And the HTTP status code should be "200"
 
   Scenario: normal user tries to get other users
-    Given user "normaluser" has been created with default attributes and skeleton files
-    And user "newuser" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username   |
+      | normaluser |
+      | newuser    |
     When user "normaluser" 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"
diff --git a/tests/acceptance/features/apiProvisioning-v1/removeSubAdmin.feature b/tests/acceptance/features/apiProvisioning-v1/removeSubAdmin.feature
index 68ffbd49b18f..9d6d40577f38 100644
--- a/tests/acceptance/features/apiProvisioning-v1/removeSubAdmin.feature
+++ b/tests/acceptance/features/apiProvisioning-v1/removeSubAdmin.feature
@@ -18,10 +18,12 @@ Feature: remove subadmin
     And user "brand-new-user" should not be a subadmin of group "new-group"
 
   Scenario: subadmin tries to remove other subadmin in the group
-    Given user "subadmin" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username    |
+      | subadmin    |
+      | newsubadmin |
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
-    And user "newsubadmin" has been created with default attributes and skeleton files
     And user "newsubadmin" has been made a subadmin of group "new-group"
     When user "subadmin" removes user "newsubadmin" from being a subadmin of group "new-group" using the provisioning API
     Then the OCS status code should be "997"
@@ -29,8 +31,10 @@ Feature: remove subadmin
     And user "newsubadmin" should be a subadmin of group "new-group"
 
   Scenario: normal user tries to remove subadmin in the group
-    Given user "subadmin" has been created with default attributes and skeleton files
-    And user "newuser" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username |
+      | subadmin |
+      | newuser |
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     And user "newuser" has been added to group "new-group"
diff --git a/tests/acceptance/features/apiProvisioning-v2/apiProvisioningUsingAppPassword.feature b/tests/acceptance/features/apiProvisioning-v2/apiProvisioningUsingAppPassword.feature
index d02deca49174..5e2af17e39e2 100644
--- a/tests/acceptance/features/apiProvisioning-v2/apiProvisioningUsingAppPassword.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/apiProvisioningUsingAppPassword.feature
@@ -19,8 +19,10 @@ Feature: access user provisioning API using app password
     And user "brand-new-user" should not exist
 
   Scenario: subadmin gets users in their group
-    Given user "brand-new-user" has been created with default attributes and skeleton files
-    And user "another-new-user" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username         |
+      | brand-new-user   |
+      | another-new-user |
     And group "new-group" has been created
     And user "another-new-user" has been added to group "new-group"
     And user "brand-new-user" has been made a subadmin of group "new-group"
@@ -45,8 +47,10 @@ Feature: access user provisioning API using app password
     And the display name returned by the API should be "New User"
 
   Scenario: subadmin tries to get users of other group
-    Given user "brand-new-user" has been created with default attributes and skeleton files
-    And user "another-new-user" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username         |
+      | brand-new-user   |
+      | another-new-user |
     And group "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"
@@ -54,13 +58,15 @@ Feature: access user provisioning API using app password
     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
+    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 user "newuser" has been created with default attributes and skeleton files
-    And user "anotheruser" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username    |
+      | newuser     |
+      | anotheruser |
     And a new client token for "newuser" has been generated
     And a new browser session for "newuser" has been started
     And the user has generated a new app password named "my-client"
diff --git a/tests/acceptance/features/apiProvisioning-v2/createSubAdmin.feature b/tests/acceptance/features/apiProvisioning-v2/createSubAdmin.feature
index 77bf13d95af9..75d97a66da46 100644
--- a/tests/acceptance/features/apiProvisioning-v2/createSubAdmin.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/createSubAdmin.feature
@@ -33,8 +33,10 @@ Feature: create a subadmin
 
   @issue-31276
   Scenario: subadmin of a group tries to make another user subadmin of their group
-    Given user "subadmin" has been created with default attributes and skeleton files
-    And user "brand-new-user" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and 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"
     And user "brand-new-user" has been added to group "new-group"
diff --git a/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature b/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature
index 3418f77237d6..e3fa5c5fc117 100644
--- a/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/deleteUser.feature
@@ -24,8 +24,10 @@ Feature: delete users
 
   @smokeTest
   Scenario: subadmin deletes a user in their group
-    Given user "subadmin" has been created with default attributes and skeleton files
-    And user "brand-new-user" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and 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"
@@ -36,8 +38,10 @@ Feature: delete users
 
   @issue-31276
   Scenario: normal user tries to delete a user
-    Given user "user1" has been created with default attributes and skeleton files
-    And user "user2" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username |
+      | user1    |
+      | user2    |
     When user "user1" deletes user "user2" using the provisioning API
     Then the OCS status code should be "997"
     #And the OCS status code should be "401"
diff --git a/tests/acceptance/features/apiProvisioning-v2/disableUser.feature b/tests/acceptance/features/apiProvisioning-v2/disableUser.feature
index 37e65e6f113e..234d82bba22b 100644
--- a/tests/acceptance/features/apiProvisioning-v2/disableUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/disableUser.feature
@@ -17,8 +17,10 @@ Feature: disable user
 
   @smokeTest
   Scenario: Subadmin should be able to disable an user in their group
-    Given user "subadmin" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username |
+      | user1    |
+      | subadmin |
     And group "new-group" has been created
     And user "subadmin" has been added to group "new-group"
     And user "user1" has been added to group "new-group"
@@ -30,8 +32,10 @@ Feature: disable user
 
   @issue-31276
   Scenario: Subadmin should not be able to disable an user not in their group
-    Given user "subadmin" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username |
+      | user1    |
+      | subadmin |
     And group "new-group" has been created
     And group "another-group" has been created
     And user "subadmin" has been added to group "new-group"
@@ -45,8 +49,10 @@ Feature: disable user
 
   @issue-31276
   Scenario: Subadmins should not be able to disable users that have admin permissions in their group
-    Given user "another-admin" has been created with default attributes and skeleton files
-    And user "subadmin" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username      |
+      | subadmin      |
+      | another-admin |
     And group "new-group" has been created
     And user "another-admin" has been added to group "admin"
     And user "subadmin" has been added to group "new-group"
@@ -87,8 +93,10 @@ Feature: disable user
 
   @issue-31276
   Scenario: disable an user with a regular user
-    Given user "user1" has been created with default attributes and skeleton files
-    And user "user2" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username |
+      | user1    |
+      | user2    |
     When user "user1" disables user "user2" using the provisioning API
     Then the OCS status code should be "997"
     #And the OCS status code should be "401"
diff --git a/tests/acceptance/features/apiProvisioning-v2/editUser.feature b/tests/acceptance/features/apiProvisioning-v2/editUser.feature
index 508ba8911945..a7cca92cfeaf 100644
--- a/tests/acceptance/features/apiProvisioning-v2/editUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/editUser.feature
@@ -50,8 +50,10 @@ Feature: edit users
 
   @smokeTest
   Scenario: a subadmin should be able to edit the user information in their group
-    Given user "subadmin" has been created with default attributes and skeleton files
-    And user "brand-new-user" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and 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"
diff --git a/tests/acceptance/features/apiProvisioning-v2/enableUser.feature b/tests/acceptance/features/apiProvisioning-v2/enableUser.feature
index ba11c97ee519..763ef2233cc3 100644
--- a/tests/acceptance/features/apiProvisioning-v2/enableUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/enableUser.feature
@@ -46,8 +46,10 @@ Feature: enable user
 
   @issue-31276
   Scenario: normal user tries to enable other user
-    Given user "user1" has been created with default attributes and skeleton files
-    And user "user2" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username |
+      | user1    |
+      | user2    |
     And user "user2" has been disabled
     When user "user1" tries to enable user "user2" using the provisioning API
     Then the OCS status code should be "997"
diff --git a/tests/acceptance/features/apiProvisioning-v2/getSubAdmins.feature b/tests/acceptance/features/apiProvisioning-v2/getSubAdmins.feature
index a2ae13adec51..4d6f90a8e231 100644
--- a/tests/acceptance/features/apiProvisioning-v2/getSubAdmins.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/getSubAdmins.feature
@@ -28,8 +28,10 @@ Feature: get subadmins
 
   @issue-31276
   Scenario: subadmin tries to get other subadmins of the same group
-    Given user "subadmin" has been created with default attributes and skeleton files
-    And user "newsubadmin" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username    |
+      | subadmin    |
+      | newsubadmin |
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     And user "newsubadmin" has been made a subadmin of group "new-group"
@@ -41,8 +43,10 @@ Feature: get subadmins
 
   @issue-31276
   Scenario: normal user tries to get the subadmins of the group
-    Given user "newuser" has been created with default attributes and skeleton files
-    And user "subadmin" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username    |
+      | subadmin    |
+      | newuser     |
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     When user "newuser" gets all the subadmins of group "new-group" using the provisioning API
diff --git a/tests/acceptance/features/apiProvisioning-v2/getUser.feature b/tests/acceptance/features/apiProvisioning-v2/getUser.feature
index a0a5e56faeea..b661dd1c9efb 100644
--- a/tests/acceptance/features/apiProvisioning-v2/getUser.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/getUser.feature
@@ -40,8 +40,10 @@ Feature: get user
     And the quota definition returned by the API should be "default"
 
   Scenario: a subadmin tries to get information of a user not in their group
-    Given user "subadmin" has been created with default attributes and skeleton files
-    And user "newuser" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username |
+      | subadmin |
+      | newuser  |
     And group "newgroup" has been created
     And user "subadmin" has been made a subadmin of group "newgroup"
     When user "subadmin" retrieves the information of user "newuser" using the provisioning API
@@ -51,8 +53,10 @@ Feature: get user
 
   @issue-31276
   Scenario: a normal user tries to get information of another user
-    Given user "newuser" has been created with default attributes and skeleton files
-    And user "anotheruser" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username    |
+      | newuser     |
+      | anotheruser |
     When user "anotheruser" retrieves the information of user "newuser" using the provisioning API
     Then the OCS status code should be "997"
     #And the OCS status code should be "401"
diff --git a/tests/acceptance/features/apiProvisioning-v2/getUsers.feature b/tests/acceptance/features/apiProvisioning-v2/getUsers.feature
index d2e1a5ee7e09..350a2588a7da 100644
--- a/tests/acceptance/features/apiProvisioning-v2/getUsers.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/getUsers.feature
@@ -19,8 +19,10 @@ Feature: get users
 
   @smokeTest
   Scenario: subadmin gets the users in their group
-    Given user "brand-new-user" has been created with default attributes and skeleton files
-    And user "another-new-user" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username         |
+      | brand-new-user   |
+      | another-new-user |
     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"
@@ -32,8 +34,10 @@ Feature: get users
 
   @issue-31276
   Scenario: normal user tries to get other users
-    Given user "normaluser" has been created with default attributes and skeleton files
-    And user "newuser" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username   |
+      | normaluser |
+      | newuser    |
     When user "normaluser" gets the list of all users using the provisioning API
     Then the OCS status code should be "997"
     #And the OCS status code should be "401"
diff --git a/tests/acceptance/features/apiProvisioning-v2/removeSubAdmin.feature b/tests/acceptance/features/apiProvisioning-v2/removeSubAdmin.feature
index 63a068e02f1f..4fe21bb9d8cc 100644
--- a/tests/acceptance/features/apiProvisioning-v2/removeSubAdmin.feature
+++ b/tests/acceptance/features/apiProvisioning-v2/removeSubAdmin.feature
@@ -19,10 +19,12 @@ Feature: remove subadmin
 
   @issue-31276
   Scenario: subadmin tries to remove other subadmin in the group
-    Given user "subadmin" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username    |
+      | subadmin    |
+      | newsubadmin |
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
-    And user "newsubadmin" has been created with default attributes and skeleton files
     And user "newsubadmin" has been made a subadmin of group "new-group"
     When user "subadmin" removes user "newsubadmin" from being a subadmin of group "new-group" using the provisioning API
     Then the OCS status code should be "997"
@@ -32,8 +34,10 @@ Feature: remove subadmin
 
   @issue-31276
   Scenario: normal user tries to remove subadmin in the group
-    Given user "subadmin" has been created with default attributes and skeleton files
-    And user "newuser" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username |
+      | subadmin |
+      | newuser |
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     And user "newuser" has been added to group "new-group"

From 310329ab1dd71cb28d3ab117f6228d1dcbb5ce16 Mon Sep 17 00:00:00 2001
From: Dipak Acharya <dpakach@gmail.com>
Date: Thu, 13 Jun 2019 17:06:27 +0545
Subject: [PATCH 120/131] Create multiple users in single steps feature files

---
 .../addToGroup.feature                        | 12 ++++++----
 .../apiProvisioningGroups-v1/getGroup.feature | 14 +++++++----
 .../getUserGroups.feature                     | 12 ++++++----
 .../removeFromGroup.feature                   | 18 +++++++++-----
 .../addToGroup.feature                        | 12 ++++++----
 .../apiProvisioningGroups-v2/getGroup.feature |  8 ++++---
 .../getUserGroups.feature                     | 12 ++++++----
 .../removeFromGroup.feature                   | 18 +++++++++-----
 .../createShare.feature                       | 18 +++++++++-----
 .../deleteShare.feature                       |  6 +++--
 .../apiShareOperations/accessToShare.feature  |  6 +++--
 .../changingFilesShare.feature                |  6 +++--
 .../downloadFromShare.feature                 |  6 +++--
 .../getWebDAVSharePermissions.feature         |  6 +++--
 .../apiShareOperations/gettingShares.feature  | 18 +++++++++-----
 .../apiTrashbin/trashbinFilesFolders.feature  | 24 ++++++++++++-------
 .../apiTrashbin/trashbinRestore.feature       |  6 +++--
 17 files changed, 134 insertions(+), 68 deletions(-)

diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature
index 5b4bfc602f3e..b7993fba4779 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v1/addToGroup.feature
@@ -113,8 +113,10 @@ Feature: add users to group
     And the API should not return any data
 
   Scenario: a subadmin cannot add users to groups the subadmin is responsible for
-    Given user "subadmin" has been created with default attributes and skeleton files
-    And user "brand-new-user" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username       |
+      | brand-new-user |
+      | subadmin       |
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     When user "subadmin" tries to add user "brand-new-user" to group "new-group" using the provisioning API
@@ -123,8 +125,10 @@ Feature: add users to group
     And user "brand-new-user" should not belong to group "new-group"
 
   Scenario: a subadmin cannot add users to groups the subadmin is not responsible for
-    Given user "other-subadmin" has been created with default attributes and skeleton files
-    And user "brand-new-user" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username       |
+      | brand-new-user |
+      | other-subadmin |
     And group "new-group" has been created
     And group "other-group" has been created
     And user "other-subadmin" has been made a subadmin of group "other-group"
diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/getGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/getGroup.feature
index de496b949164..29af25f354d9 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v1/getGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v1/getGroup.feature
@@ -9,8 +9,10 @@ Feature: get group
 
   @smokeTest
   Scenario: admin gets users in the group
-    Given user "brand-new-user" has been created with default attributes and skeleton files
-    And user "123" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username       |
+      | brand-new-user |
+      | 123            |
     And group "new-group" has been created
     And user "brand-new-user" has been added to group "new-group"
     And user "123" has been added to group "new-group"
@@ -50,9 +52,11 @@ Feature: get group
 
   @smokeTest
   Scenario: subadmin gets users in a group they are responsible for
-    Given user "user1" has been created with default attributes and skeleton files
-    And user "user2" has been created with default attributes and skeleton files
-    And user "subadmin" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username |
+      | user1    |
+      | user2    |
+      | subadmin |
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     And user "user1" has been added to group "new-group"
diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/getUserGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v1/getUserGroups.feature
index 83ed73503d30..f1546a76918f 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v1/getUserGroups.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v1/getUserGroups.feature
@@ -79,8 +79,10 @@ Feature: get user groups
 
   @smokeTest
   Scenario: subadmin tries to get other groups of a user in their group
-    Given user "newuser" has been created with default attributes and skeleton files
-    And user "subadmin" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username |
+      | newuser  |
+      | subadmin |
     And group "newgroup" has been created
     And group "anothergroup" has been created
     And user "subadmin" has been made a subadmin of group "newgroup"
@@ -93,8 +95,10 @@ Feature: get user groups
     And the HTTP status code should be "200"
 
   Scenario: normal user tries to get the groups of another user
-    Given user "newuser" has been created with default attributes and skeleton files
-    And user "anotheruser" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username    |
+      | newuser     |
+      | anotheruser |
     And group "newgroup" has been created
     And user "newuser" has been added to group "newgroup"
     When user "anotheruser" gets all the groups of user "newuser" using the provisioning API
diff --git a/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature
index 19010ee50c76..dbcda4b18ea6 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v1/removeFromGroup.feature
@@ -101,8 +101,10 @@ Feature: remove a user from a group
 
   @smokeTest
   Scenario: a subadmin can remove users from groups the subadmin is responsible for
-    Given user "subadmin" has been created with default attributes and skeleton files
-    And user "brand-new-user" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username       |
+      | brand-new-user |
+      | subadmin       |
     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"
@@ -112,8 +114,10 @@ Feature: remove a user from a group
     And user "brand-new-user" should not belong to group "new-group"
 
   Scenario: a subadmin cannot remove users from groups the subadmin is not responsible for
-    Given user "other-subadmin" has been created with default attributes and skeleton files
-    And user "brand-new-user" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username       |
+      | brand-new-user |
+      | other-subadmin |
     And group "new-group" has been created
     And group "other-group" has been created
     And user "brand-new-user" has been added to group "new-group"
@@ -124,8 +128,10 @@ Feature: remove a user from a group
     And user "brand-new-user" should belong to group "new-group"
 
   Scenario: normal user tries to remove a user in their group
-    Given user "newuser" has been created with default attributes and skeleton files
-    And user "anotheruser" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username    |
+      | newuser     |
+      | anotheruser |
     And group "new-group" has been created
     And user "newuser" has been added to group "new-group"
     And user "anotheruser" has been added to group "new-group"
diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature
index 271fb7bd967a..104e687371a5 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v2/addToGroup.feature
@@ -115,8 +115,10 @@ Feature: add users to group
     And the API should not return any data
 
   Scenario: subadmin adds users to groups the subadmin is responsible for
-    Given user "subadmin" has been created with default attributes and skeleton files
-    And user "brand-new-user" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username       |
+      | brand-new-user |
+      | subadmin       |
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     When user "subadmin" tries to add user "brand-new-user" to group "new-group" using the provisioning API
@@ -125,8 +127,10 @@ Feature: add users to group
     And user "brand-new-user" should not belong to group "new-group"
 
   Scenario: subadmin tries to add user to groups the subadmin is not responsible for
-    Given user "other-subadmin" has been created with default attributes and skeleton files
-    And user "brand-new-user" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username       |
+      | brand-new-user |
+      | other-subadmin |
     And group "new-group" has been created
     And group "other-group" has been created
     And user "other-subadmin" has been made a subadmin of group "other-group"
diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/getGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/getGroup.feature
index 9b581a43ecee..d139e6d4cc90 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v2/getGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v2/getGroup.feature
@@ -50,9 +50,11 @@ Feature: get group
 
   @smokeTest
   Scenario: subadmin gets users in a group they are responsible for
-    Given user "user1" has been created with default attributes and skeleton files
-    And user "user2" has been created with default attributes and skeleton files
-    And user "subadmin" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username |
+      | user1    |
+      | user2    |
+      | subadmin |
     And group "new-group" has been created
     And user "subadmin" has been made a subadmin of group "new-group"
     And user "user1" has been added to group "new-group"
diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/getUserGroups.feature b/tests/acceptance/features/apiProvisioningGroups-v2/getUserGroups.feature
index 7ca3691eb185..376f09433a60 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v2/getUserGroups.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v2/getUserGroups.feature
@@ -79,8 +79,10 @@ Feature: get user groups
 
   @smokeTest
   Scenario: subadmin tries to get other groups of a user in their group
-    Given user "newuser" has been created with default attributes and skeleton files
-    And user "subadmin" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username |
+      | newuser  |
+      | subadmin |
     And group "newgroup" has been created
     And group "anothergroup" has been created
     And user "subadmin" has been made a subadmin of group "newgroup"
@@ -94,8 +96,10 @@ Feature: get user groups
 
   @issue-31276
   Scenario: normal user tries to get the groups of another user
-    Given user "newuser" has been created with default attributes and skeleton files
-    And user "anotheruser" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username    |
+      | newuser     |
+      | anotheruser |
     And group "newgroup" has been created
     And user "newuser" has been added to group "newgroup"
     When user "anotheruser" gets all the groups of user "newuser" using the provisioning API
diff --git a/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature b/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature
index 75a99dcbaa03..d6d73ad2fbc5 100644
--- a/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature
+++ b/tests/acceptance/features/apiProvisioningGroups-v2/removeFromGroup.feature
@@ -101,8 +101,10 @@ Feature: remove a user from a group
 
   @smokeTest
   Scenario: a subadmin can remove users from groups the subadmin is responsible for
-    Given user "subadmin" has been created with default attributes and skeleton files
-    And user "brand-new-user" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username       |
+      | brand-new-user |
+      | subadmin       |
     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"
@@ -112,8 +114,10 @@ Feature: remove a user from a group
     And user "brand-new-user" should not belong to group "new-group"
 
   Scenario: a subadmin cannot remove users from groups the subadmin is not responsible for
-    Given user "other-subadmin" has been created with default attributes and skeleton files
-    And user "brand-new-user" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username       |
+      | brand-new-user |
+      | other-subadmin |
     And group "new-group" has been created
     And group "other-group" has been created
     And user "brand-new-user" has been added to group "new-group"
@@ -125,8 +129,10 @@ Feature: remove a user from a group
 
   @issue-31276
   Scenario: normal user tries to remove a user in their group
-    Given user "newuser" has been created with default attributes and skeleton files
-    And user "anotheruser" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username    |
+      | newuser     |
+      | anotheruser |
     And group "new-group" has been created
     And user "newuser" has been added to group "new-group"
     And user "anotheruser" has been added to group "new-group"
diff --git a/tests/acceptance/features/apiShareManagementBasic/createShare.feature b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
index dde73b5238f3..d377a3e553bf 100644
--- a/tests/acceptance/features/apiShareManagementBasic/createShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
@@ -261,8 +261,10 @@ Feature: sharing
   @smokeTest
   Scenario Outline: Share of folder to a group
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes and skeleton files
-    And user "user2" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user1    |
+      | user2    |
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
     And user "user2" has been added to group "grp1"
@@ -315,8 +317,10 @@ Feature: sharing
   @smokeTest
   Scenario: unique target names for incoming shares
     Given using OCS API version "1"
-    And user "user1" has been created with default attributes and skeleton files
-    And user "user2" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user1    |
+      | user2    |
     And user "user0" has created folder "/foo"
     And user "user1" has created folder "/foo"
     When user "user0" shares file "/foo" with user "user2" using the sharing API
@@ -628,8 +632,10 @@ Feature: sharing
 
   Scenario Outline: Share of folder to a group with emoji in the name
     Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes and skeleton files
-    And user "user2" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user1    |
+      | user2    |
     And group "😀 😁" has been created
     And user "user1" has been added to group "😀 😁"
     And user "user2" has been added to group "😀 😁"
diff --git a/tests/acceptance/features/apiShareManagementBasic/deleteShare.feature b/tests/acceptance/features/apiShareManagementBasic/deleteShare.feature
index 1bcdb6613e81..c52ba8b6d40d 100644
--- a/tests/acceptance/features/apiShareManagementBasic/deleteShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/deleteShare.feature
@@ -5,8 +5,10 @@ Feature: sharing
     Given using old DAV path
 
   Scenario Outline: Delete all group shares
-    Given user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
     And using OCS API version "<ocs_api_version>"
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
diff --git a/tests/acceptance/features/apiShareOperations/accessToShare.feature b/tests/acceptance/features/apiShareOperations/accessToShare.feature
index b1e32e2db01b..2ea2c78c5cfb 100644
--- a/tests/acceptance/features/apiShareOperations/accessToShare.feature
+++ b/tests/acceptance/features/apiShareOperations/accessToShare.feature
@@ -3,8 +3,10 @@ Feature: sharing
 
   Background:
     Given using old DAV path
-    And user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
 
   @smokeTest
   Scenario Outline: Sharee can see the share
diff --git a/tests/acceptance/features/apiShareOperations/changingFilesShare.feature b/tests/acceptance/features/apiShareOperations/changingFilesShare.feature
index 86848dc6c2f4..cf073e30cd8e 100644
--- a/tests/acceptance/features/apiShareOperations/changingFilesShare.feature
+++ b/tests/acceptance/features/apiShareOperations/changingFilesShare.feature
@@ -4,8 +4,10 @@ Feature: sharing
   Background:
     Given using OCS API version "1"
     And using old DAV path
-    And user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
 
   @smokeTest
   Scenario: moving a file into a share as recipient
diff --git a/tests/acceptance/features/apiShareOperations/downloadFromShare.feature b/tests/acceptance/features/apiShareOperations/downloadFromShare.feature
index b20b3de2165a..f2d1ee0e43fa 100644
--- a/tests/acceptance/features/apiShareOperations/downloadFromShare.feature
+++ b/tests/acceptance/features/apiShareOperations/downloadFromShare.feature
@@ -16,8 +16,10 @@ Feature: sharing
     And the HTTP status code should be "404"
 
   Scenario: Share a file by multiple channels and download from sub-folder and direct file share
-    Given user "user1" has been created with default attributes and skeleton files
-    And user "user2" has been created with default attributes and skeleton files
+    Given these users have been created with default attributes and skeleton files:
+      | username |
+      | user1    |
+      | user2    |
     And group "grp1" has been created
     And user "user1" has been added to group "grp1"
     And user "user2" has been added to group "grp1"
diff --git a/tests/acceptance/features/apiShareOperations/getWebDAVSharePermissions.feature b/tests/acceptance/features/apiShareOperations/getWebDAVSharePermissions.feature
index 9d85147003cb..1ff48ace0d9d 100644
--- a/tests/acceptance/features/apiShareOperations/getWebDAVSharePermissions.feature
+++ b/tests/acceptance/features/apiShareOperations/getWebDAVSharePermissions.feature
@@ -3,8 +3,10 @@ Feature: sharing
 
   Background:
     Given using OCS API version "1"
-    And user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
 
   @smokeTest
   Scenario Outline: Correct webdav share-permissions for owned file
diff --git a/tests/acceptance/features/apiShareOperations/gettingShares.feature b/tests/acceptance/features/apiShareOperations/gettingShares.feature
index e1564710d4d1..b30eb642a198 100644
--- a/tests/acceptance/features/apiShareOperations/gettingShares.feature
+++ b/tests/acceptance/features/apiShareOperations/gettingShares.feature
@@ -3,8 +3,10 @@ Feature: sharing
 
   Background:
     Given using old DAV path
-    And user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
 
   @smokeTest
   Scenario Outline: getting all shares of a user using that user
@@ -35,8 +37,10 @@ Feature: sharing
   @smokeTest
   Scenario Outline: getting all shares of a file
     Given using OCS API version "<ocs_api_version>"
-    And user "user2" has been created with default attributes and skeleton files
-    And user "user3" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user2    |
+      | user3    |
     And user "user0" has shared file "textfile0.txt" with user "user1"
     And user "user0" has shared file "textfile0.txt" with user "user2"
     When user "user0" gets all the shares from the file "textfile0.txt" using the sharing API
@@ -53,8 +57,10 @@ Feature: sharing
   @smokeTest
   Scenario Outline: getting all shares of a file with reshares
     Given using OCS API version "<ocs_api_version>"
-    And user "user2" has been created with default attributes and skeleton files
-    And user "user3" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user2    |
+      | user3    |
     And user "user0" has shared file "textfile0.txt" with user "user1"
     And user "user1" has shared file "textfile0 (2).txt" with user "user2"
     When user "user0" gets all the shares with reshares from the file "textfile0.txt" using the sharing API
diff --git a/tests/acceptance/features/apiTrashbin/trashbinFilesFolders.feature b/tests/acceptance/features/apiTrashbin/trashbinFilesFolders.feature
index 914d63ff20e7..3f4a5c8974b7 100644
--- a/tests/acceptance/features/apiTrashbin/trashbinFilesFolders.feature
+++ b/tests/acceptance/features/apiTrashbin/trashbinFilesFolders.feature
@@ -47,8 +47,10 @@ Feature: files and folders exist in the trashbin after being deleted
 
   Scenario Outline: deleting a file in a shared folder moves it to the trashbin root
     Given using <dav-path> DAV path
-    And user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
     And user "user0" has created folder "/shared"
     And user "user0" has moved file "/textfile0.txt" to "/shared/shared_file.txt"
     And user "user0" has shared folder "/shared" with user "user1"
@@ -63,8 +65,10 @@ Feature: files and folders exist in the trashbin after being deleted
 
   Scenario Outline: deleting a shared folder moves it to trashbin
     Given using <dav-path> DAV path
-    And user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
     And user "user0" has created folder "/shared"
     And user "user0" has moved file "/textfile0.txt" to "/shared/shared_file.txt"
     And user "user0" has shared folder "/shared" with user "user1"
@@ -77,8 +81,10 @@ Feature: files and folders exist in the trashbin after being deleted
 
   Scenario Outline: deleting a received folder doesn't move it to trashbin
     Given using <dav-path> DAV path
-    And user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
     And user "user0" has created folder "/shared"
     And user "user0" has moved file "/textfile0.txt" to "/shared/shared_file.txt"
     And user "user0" has shared folder "/shared" with user "user1"
@@ -92,8 +98,10 @@ Feature: files and folders exist in the trashbin after being deleted
 
   Scenario Outline: deleting a file in a received folder moves it to trashbin
     Given using <dav-path> DAV path
-    And user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
     And user "user0" has created folder "/shared"
     And user "user0" has moved file "/textfile0.txt" to "/shared/shared_file.txt"
     And user "user0" has shared folder "/shared" with user "user1"
diff --git a/tests/acceptance/features/apiTrashbin/trashbinRestore.feature b/tests/acceptance/features/apiTrashbin/trashbinRestore.feature
index 610c190bef7d..6e3bcb8cada6 100644
--- a/tests/acceptance/features/apiTrashbin/trashbinRestore.feature
+++ b/tests/acceptance/features/apiTrashbin/trashbinRestore.feature
@@ -10,8 +10,10 @@ Feature: Restore deleted files/folders
 
   Scenario Outline: deleting a file in a received folder when restored it comes back to the original path
     Given using <dav-path> DAV path
-    And user "user0" has been created with default attributes and skeleton files
-    And user "user1" has been created with default attributes and skeleton files
+    And these users have been created with default attributes and skeleton files:
+      | username |
+      | user0    |
+      | user1    |
     And user "user0" has created folder "/shared"
     And user "user0" has moved file "/textfile0.txt" to "/shared/shared_file.txt"
     And user "user0" has shared folder "/shared" with user "user1"

From 3935826293f59972df0553df68b05c34299093f8 Mon Sep 17 00:00:00 2001
From: Hari Bhandari <bhandarihari07@gmail.com>
Date: Fri, 14 Jun 2019 09:51:02 +0545
Subject: [PATCH 121/131] webui upload without skeleton

---
 .../features/webUIUpload/upload.feature       | 41 +++++++++++++++----
 .../webUIUpload/uploadEdgecases.feature       | 23 ++++++++---
 .../uploadFileGreaterThanQuotaSize.feature    |  2 +-
 3 files changed, 52 insertions(+), 14 deletions(-)

diff --git a/tests/acceptance/features/webUIUpload/upload.feature b/tests/acceptance/features/webUIUpload/upload.feature
index f8c2e05c5b38..22815a2a3391 100644
--- a/tests/acceptance/features/webUIUpload/upload.feature
+++ b/tests/acceptance/features/webUIUpload/upload.feature
@@ -6,11 +6,11 @@ Feature: File Upload
   So that I can store files in ownCloud
 
   Background:
-    Given user "user1" has been created with default attributes and skeleton files
-    And user "user1" has logged in using the webUI
+    Given user "user1" has been created with default attributes and without skeleton files
 
   @smokeTest
   Scenario: simple upload of a file that does not exist before
+    Given user "user1" has logged in using the webUI
     When the user uploads file "new-lorem.txt" using the webUI
     Then no notification should be displayed on the webUI
     And file "new-lorem.txt" should be listed on the webUI
@@ -19,6 +19,7 @@ Feature: File Upload
   @smokeTest
   Scenario: chunking upload
     Given a file with the size of "30000000" bytes and the name "big-video.mp4" has been created locally
+    And user "user1" has logged in using the webUI
     When the user uploads file "big-video.mp4" using the webUI
     Then no notification should be displayed on the webUI
     And file "big-video.mp4" should be listed on the webUI
@@ -27,12 +28,16 @@ Feature: File Upload
   @skipOnFIREFOX
   Scenario: conflict with a chunked file
     Given a file with the size of "30000000" bytes and the name "big-video.mp4" has been created locally
+    And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt"
+    And user "user1" has logged in using the webUI
     When the user renames file "lorem.txt" to "big-video.mp4" using the webUI
     And the user uploads overwriting file "big-video.mp4" using the webUI and retries if the file is locked
     Then file "big-video.mp4" should be listed on the webUI
     And the content of "big-video.mp4" should be the same as the local "big-video.mp4"
 
   Scenario: upload a new file into a sub folder
+    Given user "user1" has created folder "/simple-folder"
+    And user "user1" has logged in using the webUI
     When the user opens folder "simple-folder" using the webUI
     And the user uploads file "new-lorem.txt" using the webUI
     Then no notification should be displayed on the webUI
@@ -41,6 +46,8 @@ Feature: File Upload
 
   @smokeTest
   Scenario: overwrite an existing file
+    Given user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt"
+    And user "user1" has logged in using the webUI
     When the user uploads overwriting file "lorem.txt" using the webUI and retries if the file is locked
     Then no dialog should be displayed on the webUI
     And file "lorem.txt" should be listed on the webUI
@@ -49,6 +56,8 @@ Feature: File Upload
 
   @smokeTest
   Scenario: keep new and existing file
+    Given user "user1" has uploaded file with content "original content" to "/lorem.txt"
+    And user "user1" has logged in using the webUI
     When the user uploads file "lorem.txt" using the webUI
     And the user chooses to keep the new files in the upload dialog
     And the user chooses to keep the existing files in the upload dialog
@@ -56,26 +65,35 @@ Feature: File Upload
     Then no dialog should be displayed on the webUI
     And no notification should be displayed on the webUI
     And file "lorem.txt" should be listed on the webUI
-    And the content of "lorem.txt" should not have changed
+    And the content of file "lorem.txt" for user "user1" should be "original content"
     And file "lorem (2).txt" should be listed on the webUI
     And the content of "lorem (2).txt" should be the same as the local "lorem.txt"
 
   Scenario: cancel conflict dialog
+    Given user "user1" has uploaded file with content "original content" to "/lorem.txt"
+    And user "user1" has logged in using the webUI
     When the user uploads file "lorem.txt" using the webUI
     And the user chooses "Cancel" in the upload dialog
     Then no dialog should be displayed on the webUI
     And no notification should be displayed on the webUI
     And file "lorem.txt" should be listed on the webUI
-    And the content of "lorem.txt" should not have changed
+    And the content of file "lorem.txt" for user "user1" should be "original content"
     And file "lorem (2).txt" should not be listed on the webUI
 
   Scenario: overwrite an existing file in a sub-folder
+    Given user "user1" has created folder "/simple-folder"
+    And user "user1" has uploaded file with content "original content" to "/simple-folder/lorem.txt"
+    And user "user1" has logged in using the webUI
     When the user opens folder "simple-folder" using the webUI
     And the user uploads overwriting file "lorem.txt" using the webUI and retries if the file is locked
     Then file "lorem.txt" should be listed on the webUI
     And the content of "lorem.txt" should be the same as the local "lorem.txt"
 
   Scenario: keep new and existing file in a sub-folder
+    Given user "user1" has created folder "/simple-folder"
+    And user "user1" has uploaded file with content "original content" to "/simple-folder/lorem.txt"
+    And user "user1" has uploaded file with content "original content" to "/lorem.txt"
+    And user "user1" has logged in using the webUI
     When the user opens folder "simple-folder" using the webUI
     And the user uploads file "lorem.txt" using the webUI
     And the user chooses to keep the new files in the upload dialog
@@ -84,12 +102,14 @@ Feature: File Upload
     Then no dialog should be displayed on the webUI
     And no notification should be displayed on the webUI
     And file "lorem.txt" should be listed on the webUI
-    And the content of "lorem.txt" should not have changed
+    And the content of file "lorem.txt" for user "user1" should be "original content"
     And file "lorem (2).txt" should be listed on the webUI
     And the content of "lorem (2).txt" should be the same as the local "lorem.txt"
 
   Scenario: upload a file into a public share
-    Given the user has created a new public link for folder "simple-folder" using the webUI with
+    Given user "user1" has created folder "/simple-folder"
+    And user "user1" has logged in using the webUI
+    And the user has created a new public link for folder "simple-folder" using the webUI with
       | permission | read-write |
     And the public accesses the last created public link using the webUI
     And the user uploads file "new-lorem.txt" using the webUI
@@ -97,7 +117,10 @@ Feature: File Upload
     And the content of "simple-folder/new-lorem.txt" should be the same as the local "new-lorem.txt"
 
   Scenario: upload overwriting a file into a public share
-    Given the user has created a new public link for folder "simple-folder" using the webUI with
+    Given user "user1" has created folder "/simple-folder"
+    And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/simple-folder/lorem.txt"
+    And user "user1" has logged in using the webUI
+    And the user has created a new public link for folder "simple-folder" using the webUI with
       | permission | read-write |
     And the public accesses the last created public link using the webUI
     And the user uploads overwriting file "lorem.txt" using the webUI and retries if the file is locked
@@ -105,7 +128,9 @@ Feature: File Upload
     And the content of "simple-folder/lorem.txt" should be the same as the local "lorem.txt"
 
   Scenario: upload a file into files_drop share
-    Given the user has created a new public link for folder "simple-folder" using the webUI with
+    Given user "user1" has created folder "/simple-folder"
+    And user "user1" has logged in using the webUI
+    And the user has created a new public link for folder "simple-folder" using the webUI with
       | permission | upload |
     And the public accesses the last created public link using the webUI
     Then the user uploads file "lorem.txt" using the webUI
diff --git a/tests/acceptance/features/webUIUpload/uploadEdgecases.feature b/tests/acceptance/features/webUIUpload/uploadEdgecases.feature
index cb0e5b76b657..3a58b979da40 100644
--- a/tests/acceptance/features/webUIUpload/uploadEdgecases.feature
+++ b/tests/acceptance/features/webUIUpload/uploadEdgecases.feature
@@ -8,10 +8,10 @@ Feature: File Upload
   that is not academically correct but saves a lot of time
 
   Background:
-    Given user "user1" has been created with default attributes and skeleton files
-    And user "user1" has logged in using the webUI
+    Given user "user1" has been created with default attributes and without skeleton files
 
   Scenario: simple upload of a file that does not exist before
+    Given user "user1" has logged in using the webUI
     When the user uploads file "new-'single'quotes.txt" using the webUI
     Then file "new-'single'quotes.txt" should be listed on the webUI
     And the content of "new-'single'quotes.txt" should be the same as the local "new-'single'quotes.txt"
@@ -27,6 +27,8 @@ Feature: File Upload
   @smokeTest
   Scenario Outline: upload a new file into a sub folder
     Given a file with the size of "3000" bytes and the name "0" has been created locally
+    And user "user1" has created folder <folder-to-upload-to>
+    And user "user1" has logged in using the webUI
     When the user opens folder <folder-to-upload-to> using the webUI
     And the user uploads file "0" using the webUI
     Then file "0" should be listed on the webUI
@@ -50,6 +52,10 @@ Feature: File Upload
       | "strängé नेपाली folder" |
 
   Scenario: overwrite an existing file
+    Given user "user1" has uploaded file "filesForUpload/'single'quotes.txt" to "/'single'quotes.txt"
+    And user "user1" has uploaded file "filesForUpload/strängé filename (duplicate #2 &).txt" to "/strängé filename (duplicate #2 &).txt"
+    And user "user1" has uploaded file "filesForUpload/zzzz-must-be-last-file-in-folder.txt" to "/zzzz-must-be-last-file-in-folder.txt"
+    And user "user1" has logged in using the webUI
     When the user uploads overwriting file "'single'quotes.txt" using the webUI and retries if the file is locked
     Then file "'single'quotes.txt" should be listed on the webUI
     And the content of "'single'quotes.txt" should be the same as the local "'single'quotes.txt"
@@ -63,26 +69,31 @@ Feature: File Upload
     And the content of "zzzz-must-be-last-file-in-folder.txt" should be the same as the local "zzzz-must-be-last-file-in-folder.txt"
 
   Scenario: keep new and existing file
+    Given user "user1" has uploaded file with content "single quote content" to "/'single'quotes.txt"
+    And user "user1" has uploaded file with content "strange content" to "/strängé filename (duplicate #2 &).txt"
+    And user "user1" has uploaded file with content "zzz content" to "/zzzz-must-be-last-file-in-folder.txt"
+    And user "user1" has logged in using the webUI
     When the user uploads file "'single'quotes.txt" keeping both new and existing files using the webUI
     Then file "'single'quotes.txt" should be listed on the webUI
-    And the content of "'single'quotes.txt" should not have changed
+    And the content of file "'single'quotes.txt" for user "user1" should be "single quote content"
     And file "'single'quotes (2).txt" should be listed on the webUI
     And the content of "'single'quotes (2).txt" should be the same as the local "'single'quotes.txt"
 
     When the user uploads file "strängé filename (duplicate #2 &).txt" keeping both new and existing files using the webUI
     Then file "strängé filename (duplicate #2 &).txt" should be listed on the webUI
-    And the content of "strängé filename (duplicate #2 &).txt" should not have changed
+    And the content of file "strängé filename (duplicate #2 &).txt" for user "user1" should be "strange content"
     And file "strängé filename (duplicate #2 &) (2).txt" should be listed on the webUI
     And the content of "strängé filename (duplicate #2 &) (2).txt" should be the same as the local "strängé filename (duplicate #2 &).txt"
 
     When the user uploads file "zzzz-must-be-last-file-in-folder.txt" keeping both new and existing files using the webUI
     Then file "zzzz-must-be-last-file-in-folder.txt" should be listed on the webUI
-    And the content of "zzzz-must-be-last-file-in-folder.txt" should not have changed
+    And the content of file "zzzz-must-be-last-file-in-folder.txt" for user "user1" should be "zzz content"
     And file "zzzz-must-be-last-file-in-folder (2).txt" should be listed on the webUI
     And the content of "zzzz-must-be-last-file-in-folder (2).txt" should be the same as the local "zzzz-must-be-last-file-in-folder.txt"
 
   Scenario Outline: chunking upload using difficult names
     Given a file with the size of "30000000" bytes and the name <file-name> has been created locally
+    And user "user1" has logged in using the webUI
     When the user uploads file <file-name> using the webUI
     Then file <file-name> should be listed on the webUI
     And the content of <file-name> should be the same as the local <file-name>
@@ -94,6 +105,8 @@ Feature: File Upload
   # upload into "simple-folder" because there is already a folder called "0" in the root
   Scenario: Upload a file called "0" using chunking
     Given a file with the size of "30000000" bytes and the name "0" has been created locally
+    And user "user1" has created folder "simple-folder"
+    And user "user1" has logged in using the webUI
     When the user opens folder "simple-folder" using the webUI
     And the user uploads file "0" using the webUI
     Then file "0" should be listed on the webUI
diff --git a/tests/acceptance/features/webUIUpload/uploadFileGreaterThanQuotaSize.feature b/tests/acceptance/features/webUIUpload/uploadFileGreaterThanQuotaSize.feature
index e012ea494786..18298957345b 100644
--- a/tests/acceptance/features/webUIUpload/uploadFileGreaterThanQuotaSize.feature
+++ b/tests/acceptance/features/webUIUpload/uploadFileGreaterThanQuotaSize.feature
@@ -6,7 +6,7 @@ Feature: Upload a file
   So that I can store it in owncloud
 
   Background:
-    Given user "user1" has been created with default attributes and skeleton files
+    Given user "user1" has been created with default attributes and without skeleton files
 
   @smokeTest
   Scenario: simple upload of a file with the size greater than the size of quota

From 12e0822287461d4eddc1c9d1f8d453290452e00e Mon Sep 17 00:00:00 2001
From: bhawana <bhawana.prs@gmail.com>
Date: Fri, 7 Jun 2019 15:44:07 +0545
Subject: [PATCH 122/131] API test for sharing files when receiver has matching
 files

---
 .../apiShareManagement/acceptShares.feature   | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/tests/acceptance/features/apiShareManagement/acceptShares.feature b/tests/acceptance/features/apiShareManagement/acceptShares.feature
index 5c905cb6abae..cf0c7c172c19 100644
--- a/tests/acceptance/features/apiShareManagement/acceptShares.feature
+++ b/tests/acceptance/features/apiShareManagement/acceptShares.feature
@@ -432,3 +432,22 @@ Feature: accept/decline shares coming from internal users
       | path     |
       | /PARENT/ |
     And the sharing API should report that no shares are shared with user "user0"
+
+  Scenario: 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 "user0" has uploaded file with content "file from user0" to "/testfile.txt"
+    And user "user1" has uploaded file with content "file from user1" to "/testfile.txt"
+    And user "user2" has uploaded file with content "file from user2" to "/testfile.txt"
+    And user "user0" has shared file "/testfile.txt" with user "user2"
+    And user "user2" has accepted the share "/testfile.txt" offered by user "user0"
+    When user "user2" declines the share "/testfile (2).txt" offered by user "user0" using the sharing API
+    And user "user1" shares file "/testfile.txt" with user "user2" using the sharing API
+    And user "user2" accepts the share "/testfile.txt" offered by user "user1" using the sharing API
+    And user "user2" accepts the share "/testfile.txt" offered by user "user0" using the sharing API
+    Then the sharing API should report to user "user2" 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 "user2" should be "file from user2"
+    And the content of file "/testfile (2).txt" for user "user2" should be "file from user1"
+    And the content of file "/testfile (2) (2).txt" for user "user2" should be "file from user0"

From 2963dc072d43325f58589ab49fe91e4a1831739c Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Thu, 13 Jun 2019 19:23:39 +0545
Subject: [PATCH 123/131] Add test steps for upload download of files in public
 share

---
 .../bootstrap/PublicWebDavContext.php         | 112 +++++++++++++++---
 1 file changed, 93 insertions(+), 19 deletions(-)

diff --git a/tests/acceptance/features/bootstrap/PublicWebDavContext.php b/tests/acceptance/features/bootstrap/PublicWebDavContext.php
index 186ad3923f37..e019f1351204 100644
--- a/tests/acceptance/features/bootstrap/PublicWebDavContext.php
+++ b/tests/acceptance/features/bootstrap/PublicWebDavContext.php
@@ -106,6 +106,35 @@ public function renameFileFromPublicShare($fileName, $toFileName) {
 		);
 	}
 	
+	/**
+	 * @When /^the public downloads file "([^"]*)" from inside the last public shared folder using the public WebDAV API$/
+	 *
+	 * @param string $path
+	 *
+	 * @return void
+	 */
+	public function downloadPublicFileInsideAFolder($path) {
+		$this->publicDownloadsTheFileInsideThePublicSharedFolderWithPasswordAndRange(
+			$path, "", ""
+		);
+	}
+
+	/**
+	 * @When /^the public downloads file "([^"]*)" from inside the last public shared folder with password "([^"]*)" using the public WebDAV API$/
+	 *
+	 * @param string $path
+	 * @param string $password
+	 *
+	 * @return void
+	 */
+	public function publicDownloadsTheFileInsideThePublicSharedFolderWithPassword(
+		$path, $password = ""
+	) {
+		$this->publicDownloadsTheFileInsideThePublicSharedFolderWithPasswordAndRange(
+			$path, $password, ""
+		);
+	}
+
 	/**
 	 * @When /^the public downloads file "([^"]*)" from inside the last public shared folder with range "([^"]*)" using the public WebDAV API$/
 	 *
@@ -115,17 +144,9 @@ public function renameFileFromPublicShare($fileName, $toFileName) {
 	 * @return void
 	 */
 	public function downloadPublicFileInsideAFolderWithRange($path, $range) {
-		$path = \ltrim($path, "/");
-		$fullUrl = $this->featureContext->getBaseUrl() . "/public.php/webdav/$path";
-		$headers = [
-			'X-Requested-With' => 'XMLHttpRequest',
-			'Range' => $range
-		];
-		$response = HttpRequestHelper::get(
-			$fullUrl, $this->featureContext->getLastShareData()->data->token,
-			"", $headers
+		$this->publicDownloadsTheFileInsideThePublicSharedFolderWithPasswordAndRange(
+			$path, "", $range
 		);
-		$this->featureContext->setResponse($response);
 	}
 
 	/**
@@ -137,16 +158,18 @@ public function downloadPublicFileInsideAFolderWithRange($path, $range) {
 	 *
 	 * @return void
 	 */
-	public function publicDownloadsTheFileInsideThePublicSharedFolderWithPassword(
+	public function publicDownloadsTheFileInsideThePublicSharedFolderWithPasswordAndRange(
 		$path, $password, $range
 	) {
 		$path = \ltrim($path, "/");
 		$password = $this->featureContext->getActualPassword($password);
 		$fullUrl = $this->featureContext->getBaseUrl() . "/public.php/webdav/$path";
 		$headers = [
-			'X-Requested-With' => 'XMLHttpRequest',
-			'Range' => $range
+			'X-Requested-With' => 'XMLHttpRequest'
 		];
+		if ($range !== "") {
+			$headers['Range'] = $range;
+		}
 		$response = HttpRequestHelper::get(
 			$fullUrl, $this->featureContext->getLastShareData()->data->token,
 			$password, $headers
@@ -222,6 +245,39 @@ public function publiclyUploadingContent($filename, $body = 'test') {
 		$this->publicUploadContent($filename, '', $body);
 	}
 
+	/**
+	 * @Then /^the public should be able to download file "([^"]*)" from inside the last public shared folder and the content should be "([^"]*)"$/
+	 *
+	 * @param string $path
+	 * @param string $content
+	 *
+	 * @return void
+	 */
+	public function shouldBeAbleToDownloadFileInsidePublicSharedFolder(
+		$path, $content
+	) {
+		$this->shouldBeAbleToDownloadRangeOfFileInsidePublicSharedFolderWithPassword(
+			"", $path, "", $content
+		);
+	}
+
+	/**
+	 * @Then /^the public should be able to download file "([^"]*)" from inside the last public shared folder with password "([^"]*)" and the content should be "([^"]*)"$/
+	 *
+	 * @param string $path
+	 * @param string $password
+	 * @param string $content
+	 *
+	 * @return void
+	 */
+	public function shouldBeAbleToDownloadFileInsidePublicSharedFolderWithPassword(
+		$path, $password, $content
+	) {
+		$this->shouldBeAbleToDownloadRangeOfFileInsidePublicSharedFolderWithPassword(
+			"", $path, $password, $content
+		);
+	}
+
 	/**
 	 * @Then /^the public should be able to download the range "([^"]*)" of file "([^"]*)" from inside the last public shared folder with password "([^"]*)" and the content should be "([^"]*)"$/
 	 *
@@ -232,10 +288,10 @@ public function publiclyUploadingContent($filename, $body = 'test') {
 	 *
 	 * @return void
 	 */
-	public function shouldBeAbleToDownloadFileInsidePublicSharedFolderWithPassword(
+	public function shouldBeAbleToDownloadRangeOfFileInsidePublicSharedFolderWithPassword(
 		$range, $path, $password, $content
 	) {
-		$this->publicDownloadsTheFileInsideThePublicSharedFolderWithPassword(
+		$this->publicDownloadsTheFileInsideThePublicSharedFolderWithPasswordAndRange(
 			$path, $password, $range
 		);
 		$this->featureContext->downloadedContentShouldBe($content);
@@ -250,12 +306,30 @@ public function shouldBeAbleToDownloadFileInsidePublicSharedFolderWithPassword(
 	 *
 	 * @return void
 	 */
-	public function shouldBeAbleToDownloadFileInsidePublicSharedFolder(
+	public function shouldBeAbleToDownloadRangeOfFileInsidePublicSharedFolder(
 		$range, $path, $content
 	) {
-		$this->publicDownloadsTheFileInsideThePublicSharedFolderWithPassword(
-			$path, null, $range
+		$this->shouldBeAbleToDownloadRangeOfFileInsidePublicSharedFolderWithPassword(
+			$range, $path, "", $content
+		);
+	}
+
+	/**
+	 * @Then /^the public should be able to upload file "([^"]*)" with content "([^"]*)" to the last public shared folder$/
+	 *
+	 * @param string $path
+	 * @param string $content
+	 *
+	 * @return void
+	 */
+	public function shouldBeAbleToUploadFileWithContentToTheLastPublicSharedFolder(
+		$path, $content
+	) {
+		$this->publiclyUploadingContent($path, $content);
+		$this->featureContext->theHTTPStatusCodeShouldBe(
+			"201", "Failed to upload file to public share"
 		);
+		$this->downloadPublicFileInsideAFolder($path);
 		$this->featureContext->downloadedContentShouldBe($content);
 	}
 
@@ -294,7 +368,7 @@ public function publiclyUploadingShouldWork() {
 			$response->getStatusCode()
 		);
 		$this->shouldBeAbleToDownloadFileInsidePublicSharedFolder(
-			"bytes=0-3", $path, $content
+			$path, $content
 		);
 	}
 

From b62b7f1eee5c5ac98c307dc179177a51de5d2b96 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Thu, 13 Jun 2019 19:24:08 +0545
Subject: [PATCH 124/131] Enhance reShare acceptance test scenarios

---
 .../apiShareManagement/reShare.feature        | 402 ++++++++++++++++--
 1 file changed, 368 insertions(+), 34 deletions(-)

diff --git a/tests/acceptance/features/apiShareManagement/reShare.feature b/tests/acceptance/features/apiShareManagement/reShare.feature
index 508d5f5f5951..43ff254c3170 100644
--- a/tests/acceptance/features/apiShareManagement/reShare.feature
+++ b/tests/acceptance/features/apiShareManagement/reShare.feature
@@ -3,67 +3,162 @@ Feature: sharing
 
   Background:
     Given using old DAV path
-    And these users have been created with default attributes and skeleton files:
-      | username |
-      | user0    |
-      | user1    |
+    And user "user0" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and without skeleton files
 
   Scenario Outline: User is not allowed to reshare file
     Given using OCS API version "<ocs_api_version>"
-    And user "user2" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and without skeleton files
     And user "user0" has created a share with settings
       | path        | /textfile0.txt |
       | shareType   | 0              |
       | shareWith   | user1          |
-      | permissions | 8              |
+      | permissions | 15             |
     When user "user1" creates a share using the sharing API with settings
-      | path        | /textfile0 (2).txt |
-      | shareType   | 0                  |
-      | shareWith   | user2              |
-      | permissions | 31                 |
+      | path        | /textfile0.txt |
+      | shareType   | 0              |
+      | shareWith   | user2          |
+      | permissions | 15             |
     Then the OCS status code should be "404"
     And the HTTP status code should be "<http_status_code>"
+    And as "user2" file "/textfile0.txt" should not exist
+    But as "user1" file "/textfile0.txt" should exist
     Examples:
       | ocs_api_version | http_status_code |
       | 1               | 200              |
       | 2               | 404              |
 
+  Scenario Outline: User is allowed to reshare file with the same permissions
+    Given using OCS API version "<ocs_api_version>"
+    And user "user2" has been created with default attributes and without skeleton files
+    And user "user0" has created a share with settings
+      | path        | /textfile0.txt |
+      | shareType   | 0              |
+      | shareWith   | user1          |
+      | permissions | 17             |
+    When user "user1" creates a share using the sharing API with settings
+      | path        | /textfile0.txt |
+      | shareType   | 0              |
+      | shareWith   | user2          |
+      | permissions | 17             |
+    Then the OCS status code should be "<ocs_status_code>"
+    And the HTTP status code should be "200"
+    And as "user2" file "/textfile0.txt" 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 "<ocs_api_version>"
+    And user "user2" has been created with default attributes and without skeleton files
+    And user "user0" has created a share with settings
+      | path        | /textfile0.txt |
+      | shareType   | 0              |
+      | shareWith   | user1          |
+      | permissions | 31             |
+    When user "user1" creates a share using the sharing API with settings
+      | path        | /textfile0.txt |
+      | shareType   | 0              |
+      | shareWith   | user2          |
+      | permissions | 17             |
+    Then the OCS status code should be "<ocs_status_code>"
+    And the HTTP status code should be "200"
+    And as "user2" file "/textfile0.txt" should exist
+    Examples:
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
+
   Scenario Outline: User is not allowed to reshare file with more permissions
     Given using OCS API version "<ocs_api_version>"
-    And user "user2" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and without skeleton files
     And user "user0" has created a share with settings
       | path        | /textfile0.txt |
       | shareType   | 0              |
       | shareWith   | user1          |
-      | permissions | 16             |
+      | permissions | 17             |
     When user "user1" creates a share using the sharing API with settings
-      | path        | /textfile0 (2).txt |
-      | shareType   | 0                  |
-      | shareWith   | user2              |
-      | permissions | 31                 |
+      | path        | /textfile0.txt |
+      | shareType   | 0              |
+      | shareWith   | user2          |
+      | permissions | 31             |
+    Then the OCS status code should be "404"
+    And the HTTP status code should be "<http_status_code>"
+    And as "user2" file "/textfile0.txt" should not exist
+    But as "user1" file "/textfile0.txt" should exist
+    Examples:
+      | ocs_api_version | http_status_code |
+      | 1               | 200              |
+      | 2               | 404              |
+
+  Scenario Outline: Update of reshare can reduce permissions
+    Given using OCS API version "<ocs_api_version>"
+    And user "user2" has been created with default attributes and without skeleton files
+    And user "user0" has created folder "/TMP"
+    And user "user0" has created a share with settings
+      | path        | /TMP  |
+      | shareType   | 0     |
+      | shareWith   | user1 |
+      | permissions | 23    |
+    And user "user1" has created a share with settings
+      | path        | /TMP  |
+      | shareType   | 0     |
+      | shareWith   | user2 |
+      | permissions | 23    |
+    When user "user1" updates the last share using the sharing API with
+      | permissions | 17 |
+    Then the OCS status code should be "<ocs_status_code>"
+    And the HTTP status code should be "200"
+    Examples:
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
+
+  @issue-35528
+  Scenario Outline: Update of reshare can increase permissions to the maximum allowed
+    Given using OCS API version "<ocs_api_version>"
+    And user "user2" has been created with default attributes and without skeleton files
+    And user "user0" has created folder "/TMP"
+    And user "user0" has created a share with settings
+      | path        | /TMP  |
+      | shareType   | 0     |
+      | shareWith   | user1 |
+      | permissions | 23    |
+    And user "user1" has created a share with settings
+      | path        | /TMP  |
+      | shareType   | 0     |
+      | shareWith   | user2 |
+      | permissions | 17    |
+    When user "user1" updates the last share using the sharing API with
+      | permissions | 23 |
     Then the OCS status code should be "404"
     And the HTTP status code should be "<http_status_code>"
+    #Then the OCS status code should be "<ocs_status_code>"
+    #And the HTTP status code should be "200"
     Examples:
       | ocs_api_version | http_status_code |
       | 1               | 200              |
       | 2               | 404              |
+      #| ocs_api_version | ocs_status_code |
+      #| 1               | 100             |
+      #| 2               | 200             |
 
-  Scenario Outline: Do not allow reshare to exceed permissions
+  Scenario Outline: Do not allow update of reshare to exceed permissions
     Given using OCS API version "<ocs_api_version>"
-    And user "user2" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and without skeleton files
     And user "user0" has created folder "/TMP"
     And user "user0" has created a share with settings
       | path        | /TMP  |
       | shareType   | 0     |
       | shareWith   | user1 |
       | permissions | 21    |
-    And as user "user1"
-    And the user has created a share with settings
+    And user "user1" has created a share with settings
       | path        | /TMP  |
       | shareType   | 0     |
       | shareWith   | user2 |
       | permissions | 21    |
-    When the user updates the last share using the sharing API with
+    When user "user1" updates the last share using the sharing API with
       | permissions | 31 |
     Then the OCS status code should be "404"
     And the HTTP status code should be "<http_status_code>"
@@ -72,19 +167,134 @@ Feature: sharing
       | 1               | 200              |
       | 2               | 404              |
 
+  Scenario Outline: User is allowed to reshare a sub-folder with the same permissions
+    Given using OCS API version "<ocs_api_version>"
+    And user "user2" has been created with default attributes and without skeleton files
+    And user "user0" has created folder "/TMP"
+    And user "user0" has created folder "/TMP/SUB"
+    And user "user0" has created a share with settings
+      | path        | /TMP  |
+      | shareType   | 0     |
+      | shareWith   | user1 |
+      | permissions | 17    |
+    When user "user1" creates a share using the sharing API with settings
+      | path        | /TMP/SUB |
+      | shareType   | 0        |
+      | shareWith   | user2    |
+      | permissions | 17       |
+    Then the OCS status code should be "<ocs_status_code>"
+    And the HTTP status code should be "200"
+    And as "user2" folder "/SUB" should exist
+    And as "user1" file "/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 "<ocs_api_version>"
+    And user "user2" has been created with default attributes and without skeleton files
+    And user "user0" has created folder "/TMP"
+    And user "user0" has created folder "/TMP/SUB"
+    And user "user0" has created a share with settings
+      | path        | /TMP  |
+      | shareType   | 0     |
+      | shareWith   | user1 |
+      | permissions | 17    |
+    When user "user1" creates a share using the sharing API with settings
+      | path        | /TMP/SUB |
+      | shareType   | 0        |
+      | shareWith   | user2    |
+      | permissions | 31       |
+    Then the OCS status code should be "404"
+    And the HTTP status code should be "<http_status_code>"
+    And as "user2" folder "/SUB" should not exist
+    But as "user1" file "/TMP/SUB" should exist
+    Examples:
+      | ocs_api_version | http_status_code |
+      | 1               | 200              |
+      | 2               | 404              |
+
+  Scenario Outline: User is allowed to update reshare of a sub-folder with less permissions
+    Given using OCS API version "<ocs_api_version>"
+    And user "user2" has been created with default attributes and without skeleton files
+    And user "user0" has created folder "/TMP"
+    And user "user0" has created folder "/TMP/SUB"
+    And user "user0" has shared folder "/TMP" with user "user1" with permissions 23
+    And user "user1" has shared folder "/TMP/SUB" with user "user2" with permissions 23
+    When user "user1" updates the last share using the sharing API with
+      | permissions | 17 |
+    Then the OCS status code should be "<ocs_status_code>"
+    And the HTTP status code should be "200"
+    And as "user2" folder "/SUB" should exist
+    But user "user2" should not be able to upload file "filesForUpload/textfile.txt" to "/SUB/textfile.txt"
+    And as "user1" file "/TMP/SUB" should exist
+    And user "user1" 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             |
+
+  @issue-35528
+  Scenario Outline: User is allowed to update reshare of a sub-folder to the maximum allowed permissions
+    Given using OCS API version "<ocs_api_version>"
+    And user "user2" has been created with default attributes and without skeleton files
+    And user "user0" has created folder "/TMP"
+    And user "user0" has created folder "/TMP/SUB"
+    And user "user0" has shared folder "/TMP" with user "user1" with permissions 23
+    And user "user1" has shared folder "/TMP/SUB" with user "user2" with permissions 17
+    When user "user1" updates the last share using the sharing API with
+      | permissions | 23 |
+    Then the OCS status code should be "404"
+    And the HTTP status code should be "<http_status_code>"
+    #Then the OCS status code should be "<ocs_status_code>"
+    #And the HTTP status code should be "200"
+    And as "user2" folder "/SUB" should exist
+    And user "user2" should not be able to upload file "filesForUpload/textfile.txt" to "/SUB/textfile.txt"
+    #And user "user2" should be able to upload file "filesForUpload/textfile.txt" to "/SUB/textfile.txt"
+    And as "user1" file "/TMP/SUB" should exist
+    And user "user1" should be able to upload file "filesForUpload/textfile.txt" to "/TMP/SUB/textfile.txt"
+    Examples:
+      | ocs_api_version | http_status_code |
+      | 1               | 200              |
+      | 2               | 404              |
+      #| 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 "<ocs_api_version>"
+    And user "user2" has been created with default attributes and without skeleton files
+    And user "user0" has created folder "/TMP"
+    And user "user0" has created folder "/TMP/SUB"
+    And user "user0" has shared folder "/TMP" with user "user1" with permissions 17
+    And user "user1" has shared folder "/TMP/SUB" with user "user2" with permissions 17
+    When user "user1" updates the last share using the sharing API with
+      | permissions | 31 |
+    Then the OCS status code should be "404"
+    And the HTTP status code should be "<http_status_code>"
+    And as "user2" folder "/SUB" should exist
+    But user "user2" should not be able to upload file "filesForUpload/textfile.txt" to "/SUB/textfile.txt"
+    And as "user1" file "/TMP/SUB" should exist
+    But user "user1" 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              |
+
   Scenario: Reshared files can be still accessed if a user in the middle removes it.
-    Given user "user2" has been created with default attributes and skeleton files
-    And user "user3" has been created with default attributes and skeleton files
+    Given user "user2" has been created with default attributes and without skeleton files
+    And user "user3" has been created with default attributes and without skeleton files
     And user "user0" has shared file "textfile0.txt" with user "user1"
-    And user "user1" has moved file "/textfile0 (2).txt" to "/textfile0_shared.txt"
+    And user "user1" has moved file "/textfile0.txt" to "/textfile0_shared.txt"
     And user "user1" has shared file "textfile0_shared.txt" with user "user2"
     And user "user2" has shared file "textfile0_shared.txt" with user "user3"
     When user "user1" deletes file "/textfile0_shared.txt" using the WebDAV API
-    And user "user3" downloads file "/textfile0_shared.txt" with range "bytes=1-7" using the WebDAV API
-    Then the downloaded content should be "wnCloud"
+    Then the content of file "/textfile0_shared.txt" for user "user2" should be "ownCloud test text file 0" plus end-of-line
+    Then the content of file "/textfile0_shared.txt" for user "user3" should be "ownCloud test text file 0" plus end-of-line
 
   @public_link_share-feature-required
-  Scenario Outline: resharing using a public link with read only permissions is not allowed
+  Scenario Outline: creating a public link from a share with read permission only is not allowed
     Given using OCS API version "<ocs_api_version>"
     And user "user0" has created folder "/test"
     And user "user0" has shared folder "/test" with user "user1" with permissions 1
@@ -99,13 +309,101 @@ Feature: sharing
       | 2               | 404              |
 
   @public_link_share-feature-required
-  Scenario Outline: resharing using a public link with read and write permissions only is not allowed
+  Scenario Outline: creating a public link from a share with share+read only permissions is allowed
+    Given using OCS API version "<ocs_api_version>"
+    And user "user0" has created folder "/test"
+    And user "user0" has uploaded file with content "some content" to "/test/file.txt"
+    And user "user0" has shared folder "/test" with user "user1" with permissions 17
+    When user "user1" creates a public link share using the sharing API with settings
+      | path         | /test |
+      | publicUpload | false |
+    Then the OCS status code should be "<ocs_status_code>"
+    And the HTTP status code should be "200"
+    And the public should be able to download file "file.txt" from inside the last public shared folder and the content should be "some content"
+    But publicly uploading a file should not work
+    Examples:
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
+
+  @public_link_share-feature-required
+  Scenario Outline: creating an upload public link from a share with share+read only permissions is not allowed
+    Given using OCS API version "<ocs_api_version>"
+    And user "user0" has created folder "/test"
+    And user "user0" has shared folder "/test" with user "user1" with permissions 17
+    When user "user1" creates a public link share using the sharing API with settings
+      | path         | /test |
+      | permissions  | 15    |
+      | publicUpload | true  |
+    Then the OCS status code should be "404"
+    And the HTTP status code should be "<http_status_code>"
+    Examples:
+      | ocs_api_version | http_status_code |
+      | 1               | 200              |
+      | 2               | 404              |
+
+  @public_link_share-feature-required
+  Scenario Outline: creating a public link from a share with read+write permissions only is not allowed
     Given using OCS API version "<ocs_api_version>"
     And user "user0" has created folder "/test"
     And user "user0" has shared folder "/test" with user "user1" with permissions 15
+    When user "user1" creates a public link share using the sharing API with settings
+      | path         | /test |
+      | publicUpload | true  |
+    Then the OCS status code should be "404"
+    And the HTTP status code should be "<http_status_code>"
+    Examples:
+      | ocs_api_version | http_status_code |
+      | 1               | 200              |
+      | 2               | 404              |
+
+  @public_link_share-feature-required
+  Scenario Outline: creating a public link from a share with share+read+write permissions is allowed
+    Given using OCS API version "<ocs_api_version>"
+    And user "user0" has created folder "/test"
+    And user "user0" has uploaded file with content "some content" to "/test/file.txt"
+    And user "user0" has shared folder "/test" with user "user1" with permissions 31
     When user "user1" creates a public link share using the sharing API with settings
       | path         | /test |
       | publicUpload | false |
+    Then the OCS status code should be "<ocs_status_code>"
+    And the HTTP status code should be "200"
+    And the public should be able to download file "file.txt" from inside the last public shared folder and the content should be "some content"
+    But publicly uploading a file should not work
+    Examples:
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
+
+  @public_link_share-feature-required
+  Scenario Outline: creating an upload public link from a share with share+read+write permissions is allowed
+    Given using OCS API version "<ocs_api_version>"
+    And user "user0" has created folder "/test"
+    And user "user0" has uploaded file with content "some content" to "/test/file.txt"
+    And user "user0" has shared folder "/test" with user "user1" with permissions 31
+    When user "user1" creates a public link share using the sharing API with settings
+      | path         | /test |
+      | permissions  | 15    |
+      | publicUpload | true  |
+    Then the OCS status code should be "<ocs_status_code>"
+    And the HTTP status code should be "200"
+    And the public should be able to download file "file.txt" from inside the last public shared folder and the content should be "some content"
+    And publicly uploading a file should work
+    Examples:
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
+
+  @public_link_share-feature-required
+  Scenario Outline: creating an upload public link from a sub-folder of a share with share+read only permissions is not allowed
+    Given using OCS API version "<ocs_api_version>"
+    And user "user0" has created folder "/test"
+    And user "user0" has created folder "/test/sub"
+    And user "user0" has shared folder "/test" with user "user1" with permissions 17
+    When user "user1" creates a public link share using the sharing API with settings
+      | path         | /test/sub |
+      | permissions  | 15        |
+      | publicUpload | true      |
     Then the OCS status code should be "404"
     And the HTTP status code should be "<http_status_code>"
     Examples:
@@ -113,9 +411,29 @@ Feature: sharing
       | 1               | 200              |
       | 2               | 404              |
 
+  @public_link_share-feature-required
+  Scenario Outline: increasing permissions of a public link of a share with share+read only permissions is not allowed
+    Given using OCS API version "<ocs_api_version>"
+    And user "user0" has created folder "/test"
+    And user "user0" has created folder "/test/sub"
+    And user "user0" has shared folder "/test" with user "user1" with permissions 17
+    And user "user1" has created a public link share with settings
+      | path         | /test |
+      | permissions  | 1     |
+      | publicUpload | false |
+    When user "user1" updates the last share using the sharing API with
+      | permissions | 15 |
+    Then the OCS status code should be "404"
+    And the HTTP status code should be "<http_status_code>"
+    And publicly uploading a file should not work
+    Examples:
+      | ocs_api_version | http_status_code |
+      | 1               | 200              |
+      | 2               | 404              |
+
   Scenario Outline: resharing a file is not allowed when allow resharing has been disabled
     Given using OCS API version "<ocs_api_version>"
-    And user "user2" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and without skeleton files
     And user "user0" has created a share with settings
       | path        | /textfile0.txt |
       | shareType   | 0              |
@@ -123,14 +441,30 @@ Feature: sharing
       | permissions | 31             |
     And parameter "shareapi_allow_resharing" of app "core" has been set to "no"
     When user "user1" creates a share using the sharing API with settings
-      | path        | /textfile0 (2).txt |
-      | shareType   | 0                  |
-      | shareWith   | user2              |
-      | permissions | 31                 |
+      | path        | /textfile0.txt |
+      | shareType   | 0              |
+      | shareWith   | user2          |
+      | permissions | 31             |
     Then the OCS status code should be "404"
     And the HTTP status code should be "<http_status_code>"
-    And as "user2" file "/textfile0 (2).txt" should not exist
+    And as "user2" 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 "<ocs_api_version>"
+    And parameter "shareapi_allow_resharing" of app "core" has been set to "no"
+    When user "user0" creates a share using the sharing API with settings
+      | path        | /textfile0.txt |
+      | shareType   | 0              |
+      | shareWith   | user1          |
+      | permissions | 31             |
+    Then the OCS status code should be "<ocs_status_code>"
+    And the HTTP status code should be "200"
+    And as "user1" file "/textfile0.txt" should exist
+    Examples:
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |

From a87739c37525b32c78503b350a3c49861b45c964 Mon Sep 17 00:00:00 2001
From: Artur Neumann <artur@jankaritech.com>
Date: Mon, 17 Jun 2019 11:24:36 +0545
Subject: [PATCH 125/131] fix diff between master and stable10 in Auth tests

---
 .../features/apiAuthOcs/ocsGETAuth.feature    | 79 -------------------
 1 file changed, 79 deletions(-)

diff --git a/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature b/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature
index 279b54ce111b..b99bf82365d8 100644
--- a/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature
+++ b/tests/acceptance/features/apiAuthOcs/ocsGETAuth.feature
@@ -82,39 +82,6 @@ Feature: auth
       | 1               |/privatedata/getattribute                        | 997      | 401       |
       | 2               |/privatedata/getattribute                        | 997      | 401       |
 
-  @issue-32068
-  Scenario Outline: send POST requests to OCS endpoints as normal user with wrong password
-    Given using OCS API version "<ocs_api_version>"
-    And user "user1" has been created with default attributes and skeleton files
-    When user "user0" sends HTTP method "POST" to OCS API endpoint "<endpoint>" with body using password "invalid"
-      | data        | doesnotmatter |
-    Then the OCS status code should be "<ocs-code>"
-    And the HTTP status code should be "<http-code>"
-    Examples:
-      | ocs_api_version |endpoint                                             | ocs-code | http-code |
-      | 1               |/apps/files_sharing/api/v1/remote_shares/pending/123 | 997      | 401       |
-      | 2               |/apps/files_sharing/api/v1/remote_shares/pending/123 | 997      | 401       |
-      | 1               |/apps/files_sharing/api/v1/shares                    | 997      | 401       |
-      | 2               |/apps/files_sharing/api/v1/shares                    | 997      | 401       |
-      | 1               |/apps/files_sharing/api/v1/shares/pending/123        | 997      | 401       |
-      | 2               |/apps/files_sharing/api/v1/shares/pending/123        | 997      | 401       |
-      | 1               |/cloud/apps/testing                                  | 997      | 401       |
-      | 2               |/cloud/apps/testing                                  | 997      | 401       |
-      | 1               |/cloud/groups                                        | 997      | 401       |
-      | 2               |/cloud/groups                                        | 997      | 401       |
-      | 1               |/cloud/users                                         | 997      | 401       |
-      | 2               |/cloud/users                                         | 997      | 401       |
-      | 1               |/cloud/users/user0/groups                            | 997      | 401       |
-      | 2               |/cloud/users/user0/groups                            | 997      | 401       |
-      | 1               |/cloud/users/user0/subadmins                         | 997      | 401       |
-      | 2               |/cloud/users/user0/subadmins                         | 997      | 401       |
-      | 1               |/person/check                                        | 101      | 200       |
-      | 2               |/person/check                                        | 400      | 400       |
-      | 1               |/privatedata/deleteattribute/testing/test            | 997      | 401       |
-      | 2               |/privatedata/deleteattribute/testing/test            | 997      | 401       |
-      | 1               |/privatedata/setattribute/testing/test               | 997      | 401       |
-      | 2               |/privatedata/setattribute/testing/test               | 997      | 401       |
-
   Scenario Outline: using OCS with admin basic auth
     When the administrator requests "<endpoint>" with "GET" using basic auth
     Then the OCS status code should be "<ocs-code>"
@@ -152,52 +119,6 @@ Feature: auth
       | 1               |/privatedata/getattribute                        | 997      | 401       |
       | 2               |/privatedata/getattribute                        | 997      | 401       |
 
-  @issue-32068
-  Scenario Outline: send PUT requests to OCS endpoints as admin with wrong password
-    Given using OCS API version "<ocs_api_version>"
-    When the administrator sends HTTP method "PUT" to OCS API endpoint "<endpoint>" with body using password "invalid"
-      | data        | doesnotmatter |
-    Then the OCS status code should be "<ocs-code>"
-    And the HTTP status code should be "<http-code>"
-    Examples:
-      | ocs_api_version |endpoint                              | ocs-code | http-code |
-      | 1               |/apps/files_sharing/api/v1/shares/123 | 997      | 401       |
-      | 2               |/apps/files_sharing/api/v1/shares/123 | 997      | 401       |
-      | 1               |/cloud/users/user0                    | 997      | 401       |
-      | 2               |/cloud/users/user0                    | 997      | 401       |
-      | 1               |/cloud/users/user0/disable            | 997      | 401       |
-      | 2               |/cloud/users/user0/disable            | 997      | 401       |
-      | 1               |/cloud/users/user0/enable             | 997      | 401       |
-      | 2               |/cloud/users/user0/enable             | 997      | 401       |
-
-  @issue-32068
-  Scenario Outline: send DELETE requests to OCS endpoints as admin with wrong password
-    Given using OCS API version "<ocs_api_version>"
-    And group "group1" has been created
-    When the administrator sends HTTP method "DELETE" to OCS API endpoint "<endpoint>" using password "invalid"
-    Then the OCS status code should be "<ocs-code>"
-    And the HTTP status code should be "<http-code>"
-    Examples:
-      | ocs_api_version |endpoint                                             | ocs-code | http-code |
-      | 1               |/apps/files_sharing/api/v1/remote_shares/pending/123 | 997      | 401       |
-      | 2               |/apps/files_sharing/api/v1/remote_shares/pending/123 | 997      | 401       |
-      | 1               |/apps/files_sharing/api/v1/remote_shares/123         | 997      | 401       |
-      | 2               |/apps/files_sharing/api/v1/remote_shares/123         | 997      | 401       |
-      | 1               |/apps/files_sharing/api/v1/shares/123                | 997      | 401       |
-      | 2               |/apps/files_sharing/api/v1/shares/123                | 997      | 401       |
-      | 1               |/apps/files_sharing/api/v1/shares/pending/123        | 997      | 401       |
-      | 2               |/apps/files_sharing/api/v1/shares/pending/123        | 997      | 401       |
-      | 1               |/cloud/apps/testing                                  | 997      | 401       |
-      | 2               |/cloud/apps/testing                                  | 997      | 401       |
-      | 1               |/cloud/groups/group1                                 | 997      | 401       |
-      | 2               |/cloud/groups/group1                                 | 997      | 401       |
-      | 1               |/cloud/users/user0                                   | 997      | 401       |
-      | 2               |/cloud/users/user0                                   | 997      | 401       |
-      | 1               |/cloud/users/user0/groups                            | 997      | 401       |
-      | 2               |/cloud/users/user0/groups                            | 997      | 401       |
-      | 1               |/cloud/users/user0/subadmins                         | 997      | 401       |
-      | 2               |/cloud/users/user0/subadmins                         | 997      | 401       |
-
   Scenario Outline: using OCS with token auth of a normal user
     Given a new client token for "user0" has been generated
     When user "user0" requests "<endpoint>" with "GET" using basic token auth

From afc918b259f8341174817312e02282ed763ab5e6 Mon Sep 17 00:00:00 2001
From: paurakhsharma <paurakh011@gmail.com>
Date: Fri, 14 Jun 2019 16:34:35 +0545
Subject: [PATCH 126/131] webUISharingExternal use no skeleton

---
 .../features/bootstrap/Provisioning.php       | 38 +++++++---
 .../acceptance/features/bootstrap/WebDav.php  | 15 ++--
 .../federationSharing.feature                 | 71 +++++++++++--------
 3 files changed, 80 insertions(+), 44 deletions(-)

diff --git a/tests/acceptance/features/bootstrap/Provisioning.php b/tests/acceptance/features/bootstrap/Provisioning.php
index 3b6b6362ed27..605e9579fcbe 100644
--- a/tests/acceptance/features/bootstrap/Provisioning.php
+++ b/tests/acceptance/features/bootstrap/Provisioning.php
@@ -296,12 +296,16 @@ public function userHasBeenCreatedWithDefaultAttributes($user) {
 	 * @return void
 	 */
 	public function userHasBeenCreatedWithDefaultAttributesAndWithoutSkeletonFiles($user) {
-		$path = $this->popSkeletonDirectoryConfig();
+		$baseUrl = $this->getBaseUrl();
+		$path = $this->popSkeletonDirectoryConfig($baseUrl);
 		try {
 			$this->userHasBeenCreatedWithDefaultAttributes($user);
 		} finally {
 			// restore skeletondirectory even if user creation failed
-			$this->runOcc(["config:system:set skeletondirectory --value $path"]);
+			$this->runOcc(
+				["config:system:set skeletondirectory --value $path"],
+				null, null, $baseUrl
+			);
 		}
 	}
 
@@ -315,14 +319,18 @@ public function userHasBeenCreatedWithDefaultAttributesAndWithoutSkeletonFiles($
 	 * @return void
 	 */
 	public function theseUsersHaveBeenCreatedWithDefaultAttributesAndWithoutSkeletonFiles(TableNode $table) {
-		$path = $this->popSkeletonDirectoryConfig();
+		$baseUrl = $this->getBaseUrl();
+		$path = $this->popSkeletonDirectoryConfig($baseUrl);
 		try {
 			foreach ($table as $row) {
 				$this->userHasBeenCreatedWithDefaultAttributes($row['username']);
 			}
 		} finally {
 			// restore skeletondirectory even if user creation failed
-			$this->runOcc(["config:system:set skeletondirectory --value $path"]);
+			$this->runOcc(
+				["config:system:set skeletondirectory --value $path"],
+				null, null, $baseUrl
+			);
 		}
 	}
 
@@ -337,12 +345,16 @@ public function theseUsersHaveBeenCreatedWithDefaultAttributesAndWithoutSkeleton
 	 * @return void
 	 */
 	public function theseUsersHaveBeenCreatedWithoutSkeletonFiles(TableNode $table) {
-		$path = $this->popSkeletonDirectoryConfig();
+		$baseUrl = $this->getBaseUrl();
+		$path = $this->popSkeletonDirectoryConfig($baseUrl);
 		try {
 			$this->theseUsersHaveBeenCreated("", "", $table);
 		} finally {
 			// restore skeletondirectory even if user creation failed
-			$this->runOcc(["config:system:set skeletondirectory --value $path"]);
+			$this->runOcc(
+				["config:system:set skeletondirectory --value $path"],
+				null, null, $baseUrl
+			);
 		}
 	}
 
@@ -3069,12 +3081,20 @@ public function getDisabledApps() {
 	/**
 	 * Removes skeleton directory config from config.php and returns the config value
 	 *
+	 * @param string $baseUrl
+	 *
 	 * @return string
 	 */
-	public function popSkeletonDirectoryConfig() {
-		$this->runOcc(["config:system:get skeletondirectory"]);
+	public function popSkeletonDirectoryConfig($baseUrl) {
+		$this->runOcc(
+			["config:system:get skeletondirectory"],
+			null, null, $baseUrl
+		);
 		$path = \trim($this->getStdOutOfOccCommand());
-		$this->runOcc(["config:system:delete skeletondirectory"]);
+		$this->runOcc(
+			["config:system:delete skeletondirectory"],
+			null, null, $baseUrl
+		);
 		return $path;
 	}
 }
diff --git a/tests/acceptance/features/bootstrap/WebDav.php b/tests/acceptance/features/bootstrap/WebDav.php
index 028a1ab0aed9..d1ad1bc8a790 100644
--- a/tests/acceptance/features/bootstrap/WebDav.php
+++ b/tests/acceptance/features/bootstrap/WebDav.php
@@ -73,16 +73,16 @@ trait WebDav {
 	private $customDavPath = null;
 
 	private $oldAsyncSetting = null;
-	
+
 	private $oldDavSlowdownSetting = null;
-	
+
 	/**
 	 * response content parsed from XML to an array
 	 *
 	 * @var array
 	 */
 	private $responseXml = [];
-	
+
 	/**
 	 * response content parsed into a SimpleXMLElement
 	 *
@@ -1089,7 +1089,7 @@ public function listFolder(
 		if ($this->customDavPath !== null) {
 			$path = $this->customDavPath . $path;
 		}
-		
+
 		return WebDavHelper::listFolder(
 			$this->getBaseUrl(),
 			$this->getActualUsername($user),
@@ -1198,6 +1198,7 @@ public function theUserUploadsAFileTo($source, $destination) {
 	}
 
 	/**
+	 * @Given /^user "([^"]*)" on "(LOCAL|REMOTE)" has uploaded file "([^"]*)" to "([^"]*)"$/
 	 * @When /^user "([^"]*)" on "(LOCAL|REMOTE)" uploads file "([^"]*)" to "([^"]*)" using the WebDAV API$/
 	 *
 	 * @param string $user
@@ -1323,7 +1324,7 @@ public function userUploadsAFileAsyncToWithChunks(
 			$user, $source, $destination, $noOfChunks, $chunkingVersion, true
 		);
 	}
-	 
+
 	/**
 	 * sets the chunking version from human readable format
 	 *
@@ -2100,7 +2101,7 @@ public function headersShouldMatchRegularExpressions(TableNode $table) {
 			$expectedHeaderValue = $this->substituteInLineCodes(
 				$expectedHeaderValue, ['preg_quote' => ['/'] ]
 			);
-			
+
 			$returnedHeader = $this->response->getHeader($headerName);
 			PHPUnit\Framework\Assert::assertNotFalse(
 				(bool)\preg_match($expectedHeaderValue, $returnedHeader),
@@ -2205,7 +2206,7 @@ public function propfindResultShouldContainEntries(
 	) {
 		$elementRows = $expectedFiles->getRows();
 		$should = ($shouldOrNot !== "not");
-		
+
 		foreach ($elementRows as $expectedFile) {
 			$fileFound = $this->findEntryFromPropfindResponse(
 				$expectedFile[0]
diff --git a/tests/acceptance/features/webUISharingExternal/federationSharing.feature b/tests/acceptance/features/webUISharingExternal/federationSharing.feature
index e48ab6add61b..ea60c7807e1c 100644
--- a/tests/acceptance/features/webUISharingExternal/federationSharing.feature
+++ b/tests/acceptance/features/webUISharingExternal/federationSharing.feature
@@ -6,9 +6,17 @@ Feature: Federation Sharing - sharing with users on other cloud storages
 
   Background:
     Given using server "REMOTE"
-    And user "user1" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and without skeleton files
+    And user "user1" has created folder "simple-folder"
+    And user "user1" has created folder "simple-empty-folder"
+    And user "user1" has uploaded file with content "I am lorem.txt inside simple-folder" to "/simple-folder/lorem.txt"
+    And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt"
     And using server "LOCAL"
-    And user "user1" has been created with default attributes and skeleton files
+    And user "user1" has been created with default attributes and without skeleton files
+    And user "user1" has created folder "simple-folder"
+    And user "user1" has created folder "simple-empty-folder"
+    And user "user1" has uploaded file with content "I am lorem.txt inside simple-folder" to "/simple-folder/lorem.txt"
+    And user "user1" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt"
     And user "user1" has logged in using the webUI
     And parameter "auto_accept_trusted" of app "federatedfilesharing" has been set to "no"
 
@@ -24,10 +32,12 @@ Feature: Federation Sharing - sharing with users on other cloud storages
 
   Scenario: test the single steps of receiving a federation share
     Given using server "REMOTE"
-    And these users have been created with default attributes and skeleton files:
+    And these users have been created with default attributes and without skeleton files:
       | username |
       | user2    |
       | user3    |
+    And user "user2" has created folder "simple-empty-folder"
+    And user "user3" has uploaded file with content "I am lorem.txt" to "/lorem.txt"
     And user "user1" from server "REMOTE" has shared "simple-folder" with user "user1" from server "LOCAL"
     And user "user2" from server "REMOTE" has shared "simple-empty-folder" with user "user1" from server "LOCAL"
     And user "user3" from server "REMOTE" has shared "lorem.txt" with user "user1" from server "LOCAL"
@@ -39,10 +49,10 @@ Feature: Federation Sharing - sharing with users on other cloud storages
       | Remote share | Do you want to add the remote share /lorem.txt from user3@%remote_server_without_scheme%?           |
     When the user accepts the offered remote shares using the webUI
     Then file "lorem (2).txt" should be listed on the webUI
-    And the content of "lorem (2).txt" on the local server should be the same as the original "lorem.txt"
+    And the content of file "lorem (2).txt" for user "user1" on server "LOCAL" should be "I am lorem.txt"
     And folder "simple-folder (2)" should be listed on the webUI
     And file "lorem.txt" should be listed in folder "simple-folder (2)" on the webUI
-    And the content of "lorem.txt" on the local server should be the same as the original "simple-folder/lorem.txt"
+    And the content of file "simple-folder (2)/lorem.txt" for user "user1" on server "LOCAL" should be "I am lorem.txt inside simple-folder"
     And file "lorem (2).txt" should be listed in the shared-with-you page on the webUI
     And folder "simple-folder (2)" should be listed in the shared-with-you page on the webUI
     And folder "simple-empty-folder (2)" should be listed in the shared-with-you page on the webUI
@@ -79,7 +89,8 @@ Feature: Federation Sharing - sharing with users on other cloud storages
       | /lorem%20(2).txt |
 
   Scenario: one user disabling user-based auto accepting while global is enabled has no effect on other users
-    Given user "user2" has been created with default attributes and skeleton files
+    Given user "user2" has been created with default attributes and without skeleton files
+    And user "user2" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt"
     And parameter "autoAddServers" of app "federation" has been set to "1"
     And user "user1" from server "REMOTE" has shared "simple-folder" with user "user1" from server "LOCAL"
     And user "user1" from server "LOCAL" has accepted the last pending share
@@ -175,12 +186,12 @@ Feature: Federation Sharing - sharing with users on other cloud storages
   Scenario: rename a file in a received share - local server shares - remote server receives
     Given user "user1" from server "LOCAL" has shared "simple-folder" with user "user1" from server "REMOTE"
     And user "user1" from server "REMOTE" has accepted the last pending share
-    When user "user1" on "REMOTE" moves file "/simple-folder%20(2)/lorem-big.txt" to "/simple-folder%20(2)/renamed%20file.txt" using the WebDAV API
+    When user "user1" on "REMOTE" moves file "/simple-folder%20(2)/lorem.txt" to "/simple-folder%20(2)/renamed%20file.txt" using the WebDAV API
     And user "user1" re-logs in to "%local_server%" using the webUI
     And the user opens folder "simple-folder" using the webUI
     Then file "renamed file.txt" should be listed on the webUI
-    But file "lorem-big.txt" should not be listed on the webUI
-    And the content of "renamed file.txt" on the local server should be the same as the original "simple-folder/lorem-big.txt"
+    But file "lorem.txt" should not be listed on the webUI
+    And the content of file "simple-folder/renamed file.txt" for user "user1" on server "LOCAL" should be "I am lorem.txt inside simple-folder"
 
   @skipOnFIREFOX
   Scenario: rename a file in a received share - remote server shares - local server receives
@@ -188,15 +199,16 @@ Feature: Federation Sharing - sharing with users on other cloud storages
     And the user has reloaded the current page of the webUI
     When the user accepts the offered remote shares using the webUI
     When the user opens folder "simple-folder (2)" using the webUI
-    And the user renames file "lorem-big.txt" to "renamed file.txt" using the webUI
+    And the user renames file "lorem.txt" to "renamed file.txt" using the webUI
     And user "user1" re-logs in to "%remote_server%" using the webUI
     And the user opens folder "simple-folder" using the webUI
     Then file "renamed file.txt" should be listed on the webUI
-    And the content of "renamed file.txt" on the remote server should be the same as the original "simple-folder/lorem-big.txt"
-    But file "lorem-big.txt" should not be listed on the webUI
+    And the content of file "simple-folder/renamed file.txt" for user "user1" on server "REMOTE" should be "I am lorem.txt inside simple-folder"
+    But file "lorem.txt" should not be listed on the webUI
 
   Scenario: delete a file in a received share - local server shares - remote server receives
-    Given user "user1" from server "LOCAL" has shared "simple-folder" with user "user1" from server "REMOTE"
+    Given user "user1" has uploaded file "filesForUpload/data.zip" to "/simple-folder/data.zip"
+    And user "user1" from server "LOCAL" has shared "simple-folder" with user "user1" from server "REMOTE"
     And user "user1" from server "REMOTE" has accepted the last pending share
     When user "user1" on "REMOTE" deletes file "simple-folder (2)/data.zip" using the WebDAV API
     And user "user1" re-logs in to "%local_server%" using the webUI
@@ -204,7 +216,8 @@ Feature: Federation Sharing - sharing with users on other cloud storages
     Then file "data.zip" should not be listed on the webUI
 
   Scenario: delete a file in a received share - remote server shares - local server receives
-    Given user "user1" from server "REMOTE" has shared "simple-folder" with user "user1" from server "LOCAL"
+    Given user "user1" on "REMOTE" has uploaded file "filesForUpload/data.zip" to "/simple-folder/data.zip"
+    And user "user1" from server "REMOTE" has shared "simple-folder" with user "user1" from server "LOCAL"
     And the user has reloaded the current page of the webUI
     When the user accepts the offered remote shares using the webUI
     And the user opens folder "simple-folder (2)" using the webUI
@@ -215,7 +228,8 @@ Feature: Federation Sharing - sharing with users on other cloud storages
 
   Scenario: receive same name federation share from two users
     Given using server "REMOTE"
-    And user "user2" has been created with default attributes and skeleton files
+    And user "user2" has been created with default attributes and without skeleton files
+    And user "user2" has uploaded file "filesForUpload/lorem.txt" to "/lorem.txt"
     And user "user1" from server "REMOTE" has shared "/lorem.txt" with user "user1" from server "LOCAL"
     And user "user2" from server "REMOTE" has shared "/lorem.txt" with user "user1" from server "LOCAL"
     And the user has reloaded the current page of the webUI
@@ -245,9 +259,8 @@ Feature: Federation Sharing - sharing with users on other cloud storages
 
   Scenario: test sharing folder to a remote server and resharing it back to the local
     Given using server "LOCAL"
-    And these users have been created with skeleton files:
-      | username |
-      | user2    |
+    And user "user2" has been created with default attributes and without skeleton files
+    And user "user2" has created folder "simple-folder"
     When the user shares folder "simple-folder" with remote user "user1@%remote_server_without_scheme%" using the webUI
     And user "user1" re-logs in to "%remote_server%" using the webUI
     And the user accepts the offered remote shares using the webUI
@@ -259,9 +272,8 @@ Feature: Federation Sharing - sharing with users on other cloud storages
 
   Scenario: test resharing folder as readonly and set it as readonly by resharer
     Given using server "LOCAL"
-    And these users have been created with skeleton files:
-      | username |
-      | user2    |
+    And user "user2" has been created with default attributes and without skeleton files
+    And user "user2" has created folder "simple-folder"
     When the user shares folder "simple-folder" with remote user "user1@%remote_server_without_scheme%" using the webUI
     And user "user1" re-logs in to "%remote_server%" using the webUI
     And the user accepts the offered remote shares using the webUI
@@ -277,9 +289,8 @@ Feature: Federation Sharing - sharing with users on other cloud storages
 
   Scenario: test resharing folder and set it as readonly by owner
     Given using server "LOCAL"
-    And these users have been created with skeleton files:
-      | username |
-      | user2    |
+    And user "user2" has been created with default attributes and without skeleton files
+    And user "user2" has created folder "simple-folder"
     When the user shares folder "simple-folder" with remote user "user1@%remote_server_without_scheme%" using the webUI
     And user "user1" re-logs in to "%remote_server%" using the webUI
     And the user accepts the offered remote shares using the webUI
@@ -305,7 +316,8 @@ Feature: Federation Sharing - sharing with users on other cloud storages
     Then as "user1" file "/averylongfilenamefortestingthatfileswithlongfilenamescannotbeshared.txt" should exist
 
   Scenario: sharee should be able to access the files/folders inside other folder
-    Given user "user1" has created folder "simple-folder/simple-empty-folder/finalfolder"
+    Given user "user1" has created folder "simple-folder/simple-empty-folder"
+    And user "user1" has created folder "simple-folder/simple-empty-folder/finalfolder"
     And user "user1" has uploaded file "filesForUpload/textfile.txt" to "/simple-folder/simple-empty-folder/textfile.txt"
     And user "user1" from server "LOCAL" has shared "simple-folder" with user "user1" from server "REMOTE"
     And user "user1" from server "REMOTE" has accepted the last pending share
@@ -317,7 +329,8 @@ Feature: Federation Sharing - sharing with users on other cloud storages
     And folder "finalfolder" should be listed on the webUI
 
   Scenario: sharee uploads a file inside a folder of a folder
-    Given user "user1" from server "LOCAL" has shared "simple-folder" with user "user1" from server "REMOTE"
+    Given user "user1" has created folder "simple-folder/simple-empty-folder"
+    And user "user1" from server "LOCAL" has shared "simple-folder" with user "user1" from server "REMOTE"
     And user "user1" from server "REMOTE" has accepted the last pending share
     When user "user1" re-logs in to "%remote_server%" using the webUI
     And the user opens folder "simple-folder (2)/simple-empty-folder" using the webUI
@@ -327,7 +340,8 @@ Feature: Federation Sharing - sharing with users on other cloud storages
 
   @skipOnFIREFOX
   Scenario: rename a file in a folder inside a shared folder
-    Given user "user1" has uploaded file "filesForUpload/textfile.txt" to "/simple-folder/simple-empty-folder/textfile.txt"
+    Given user "user1" has created folder "simple-folder/simple-empty-folder"
+    And user "user1" has uploaded file "filesForUpload/textfile.txt" to "/simple-folder/simple-empty-folder/textfile.txt"
     And user "user1" from server "LOCAL" has shared "simple-folder" with user "user1" from server "REMOTE"
     And user "user1" from server "REMOTE" has accepted the last pending share
     And user "user1" re-logs in to "%remote_server%" using the webUI
@@ -338,7 +352,8 @@ Feature: Federation Sharing - sharing with users on other cloud storages
     But as "user1" file "simple-folder/simple-empty-folder/textfile.txt" should not exist
 
   Scenario: delete a file in a folder inside a shared folder
-    Given user "user1" has uploaded file "filesForUpload/textfile.txt" to "/simple-folder/simple-empty-folder/textfile.txt"
+    Given user "user1" has created folder "simple-folder/simple-empty-folder"
+    And user "user1" has uploaded file "filesForUpload/textfile.txt" to "/simple-folder/simple-empty-folder/textfile.txt"
     And user "user1" from server "LOCAL" has shared "simple-folder" with user "user1" from server "REMOTE"
     And user "user1" from server "REMOTE" has accepted the last pending share
     And user "user1" re-logs in to "%remote_server%" using the webUI

From b32e87a48dc1e6a34679d1ddd56d0e041ee0454f Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Mon, 17 Jun 2019 13:18:27 +0545
Subject: [PATCH 127/131] Refactor reShare.feature to use the 'shares file
 with, with permissions' steps

---
 .../apiShareManagement/reShare.feature        | 126 +++---------------
 .../acceptance/features/bootstrap/Sharing.php |  82 +++++++++---
 2 files changed, 86 insertions(+), 122 deletions(-)

diff --git a/tests/acceptance/features/apiShareManagement/reShare.feature b/tests/acceptance/features/apiShareManagement/reShare.feature
index 43ff254c3170..f3eb08606f0e 100644
--- a/tests/acceptance/features/apiShareManagement/reShare.feature
+++ b/tests/acceptance/features/apiShareManagement/reShare.feature
@@ -9,16 +9,8 @@ Feature: sharing
   Scenario Outline: User is not allowed to reshare file
     Given using OCS API version "<ocs_api_version>"
     And user "user2" has been created with default attributes and without skeleton files
-    And user "user0" has created a share with settings
-      | path        | /textfile0.txt |
-      | shareType   | 0              |
-      | shareWith   | user1          |
-      | permissions | 15             |
-    When user "user1" creates a share using the sharing API with settings
-      | path        | /textfile0.txt |
-      | shareType   | 0              |
-      | shareWith   | user2          |
-      | permissions | 15             |
+    And user "user0" has shared file "/textfile0.txt" with user "user1" with permissions 3
+    When user "user1" shares file "/textfile0.txt" with user "user2" with permissions 3 using the sharing API
     Then the OCS status code should be "404"
     And the HTTP status code should be "<http_status_code>"
     And as "user2" file "/textfile0.txt" should not exist
@@ -31,16 +23,8 @@ Feature: sharing
   Scenario Outline: User is allowed to reshare file with the same permissions
     Given using OCS API version "<ocs_api_version>"
     And user "user2" has been created with default attributes and without skeleton files
-    And user "user0" has created a share with settings
-      | path        | /textfile0.txt |
-      | shareType   | 0              |
-      | shareWith   | user1          |
-      | permissions | 17             |
-    When user "user1" creates a share using the sharing API with settings
-      | path        | /textfile0.txt |
-      | shareType   | 0              |
-      | shareWith   | user2          |
-      | permissions | 17             |
+    And user "user0" has shared file "/textfile0.txt" with user "user1" with permissions 17
+    When user "user1" shares file "/textfile0.txt" with user "user2" with permissions 17 using the sharing API
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
     And as "user2" file "/textfile0.txt" should exist
@@ -52,16 +36,8 @@ Feature: sharing
   Scenario Outline: User is allowed to reshare file with less permissions
     Given using OCS API version "<ocs_api_version>"
     And user "user2" has been created with default attributes and without skeleton files
-    And user "user0" has created a share with settings
-      | path        | /textfile0.txt |
-      | shareType   | 0              |
-      | shareWith   | user1          |
-      | permissions | 31             |
-    When user "user1" creates a share using the sharing API with settings
-      | path        | /textfile0.txt |
-      | shareType   | 0              |
-      | shareWith   | user2          |
-      | permissions | 17             |
+    And user "user0" has shared file "/textfile0.txt" with user "user1" with permissions 19
+    When user "user1" shares file "/textfile0.txt" with user "user2" with permissions 17 using the sharing API
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
     And as "user2" file "/textfile0.txt" should exist
@@ -73,16 +49,8 @@ Feature: sharing
   Scenario Outline: User is not allowed to reshare file with more permissions
     Given using OCS API version "<ocs_api_version>"
     And user "user2" has been created with default attributes and without skeleton files
-    And user "user0" has created a share with settings
-      | path        | /textfile0.txt |
-      | shareType   | 0              |
-      | shareWith   | user1          |
-      | permissions | 17             |
-    When user "user1" creates a share using the sharing API with settings
-      | path        | /textfile0.txt |
-      | shareType   | 0              |
-      | shareWith   | user2          |
-      | permissions | 31             |
+    And user "user0" has shared file "/textfile0.txt" with user "user1" with permissions 17
+    When user "user1" shares file "/textfile0.txt" with user "user2" with permissions 19 using the sharing API
     Then the OCS status code should be "404"
     And the HTTP status code should be "<http_status_code>"
     And as "user2" file "/textfile0.txt" should not exist
@@ -96,16 +64,8 @@ Feature: sharing
     Given using OCS API version "<ocs_api_version>"
     And user "user2" has been created with default attributes and without skeleton files
     And user "user0" has created folder "/TMP"
-    And user "user0" has created a share with settings
-      | path        | /TMP  |
-      | shareType   | 0     |
-      | shareWith   | user1 |
-      | permissions | 23    |
-    And user "user1" has created a share with settings
-      | path        | /TMP  |
-      | shareType   | 0     |
-      | shareWith   | user2 |
-      | permissions | 23    |
+    And user "user0" has shared folder "/TMP" with user "user1" with permissions 23
+    And user "user1" has shared folder "/TMP" with user "user2" with permissions 23
     When user "user1" updates the last share using the sharing API with
       | permissions | 17 |
     Then the OCS status code should be "<ocs_status_code>"
@@ -120,16 +80,8 @@ Feature: sharing
     Given using OCS API version "<ocs_api_version>"
     And user "user2" has been created with default attributes and without skeleton files
     And user "user0" has created folder "/TMP"
-    And user "user0" has created a share with settings
-      | path        | /TMP  |
-      | shareType   | 0     |
-      | shareWith   | user1 |
-      | permissions | 23    |
-    And user "user1" has created a share with settings
-      | path        | /TMP  |
-      | shareType   | 0     |
-      | shareWith   | user2 |
-      | permissions | 17    |
+    And user "user0" has shared folder "/TMP" with user "user1" with permissions 23
+    And user "user1" has shared folder "/TMP" with user "user2" with permissions 17
     When user "user1" updates the last share using the sharing API with
       | permissions | 23 |
     Then the OCS status code should be "404"
@@ -148,16 +100,8 @@ Feature: sharing
     Given using OCS API version "<ocs_api_version>"
     And user "user2" has been created with default attributes and without skeleton files
     And user "user0" has created folder "/TMP"
-    And user "user0" has created a share with settings
-      | path        | /TMP  |
-      | shareType   | 0     |
-      | shareWith   | user1 |
-      | permissions | 21    |
-    And user "user1" has created a share with settings
-      | path        | /TMP  |
-      | shareType   | 0     |
-      | shareWith   | user2 |
-      | permissions | 21    |
+    And user "user0" has shared folder "/TMP" with user "user1" with permissions 21
+    And user "user1" has shared folder "/TMP" with user "user2" with permissions 21
     When user "user1" updates the last share using the sharing API with
       | permissions | 31 |
     Then the OCS status code should be "404"
@@ -172,16 +116,8 @@ Feature: sharing
     And user "user2" has been created with default attributes and without skeleton files
     And user "user0" has created folder "/TMP"
     And user "user0" has created folder "/TMP/SUB"
-    And user "user0" has created a share with settings
-      | path        | /TMP  |
-      | shareType   | 0     |
-      | shareWith   | user1 |
-      | permissions | 17    |
-    When user "user1" creates a share using the sharing API with settings
-      | path        | /TMP/SUB |
-      | shareType   | 0        |
-      | shareWith   | user2    |
-      | permissions | 17       |
+    And user "user0" has shared folder "/TMP" with user "user1" with permissions 17
+    When user "user1" shares folder "/TMP/SUB" with user "user2" with permissions 17 using the sharing API
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
     And as "user2" folder "/SUB" should exist
@@ -196,16 +132,8 @@ Feature: sharing
     And user "user2" has been created with default attributes and without skeleton files
     And user "user0" has created folder "/TMP"
     And user "user0" has created folder "/TMP/SUB"
-    And user "user0" has created a share with settings
-      | path        | /TMP  |
-      | shareType   | 0     |
-      | shareWith   | user1 |
-      | permissions | 17    |
-    When user "user1" creates a share using the sharing API with settings
-      | path        | /TMP/SUB |
-      | shareType   | 0        |
-      | shareWith   | user2    |
-      | permissions | 31       |
+    And user "user0" has shared folder "/TMP" with user "user1" with permissions 17
+    When user "user1" shares folder "/TMP/SUB" with user "user2" with permissions 31 using the sharing API
     Then the OCS status code should be "404"
     And the HTTP status code should be "<http_status_code>"
     And as "user2" folder "/SUB" should not exist
@@ -434,17 +362,9 @@ Feature: sharing
   Scenario Outline: resharing a file is not allowed when allow resharing has been disabled
     Given using OCS API version "<ocs_api_version>"
     And user "user2" has been created with default attributes and without skeleton files
-    And user "user0" has created a share with settings
-      | path        | /textfile0.txt |
-      | shareType   | 0              |
-      | shareWith   | user1          |
-      | permissions | 31             |
+    And user "user0" has shared file "/textfile0.txt" with user "user1" with permissions 19
     And parameter "shareapi_allow_resharing" of app "core" has been set to "no"
-    When user "user1" creates a share using the sharing API with settings
-      | path        | /textfile0.txt |
-      | shareType   | 0              |
-      | shareWith   | user2          |
-      | permissions | 31             |
+    When user "user1" shares file "/textfile0.txt" with user "user2" with permissions 19 using the sharing API
     Then the OCS status code should be "404"
     And the HTTP status code should be "<http_status_code>"
     And as "user2" file "/textfile0.txt" should not exist
@@ -456,11 +376,7 @@ Feature: sharing
   Scenario Outline: ordinary sharing is allowed when allow resharing has been disabled
     Given using OCS API version "<ocs_api_version>"
     And parameter "shareapi_allow_resharing" of app "core" has been set to "no"
-    When user "user0" creates a share using the sharing API with settings
-      | path        | /textfile0.txt |
-      | shareType   | 0              |
-      | shareWith   | user1          |
-      | permissions | 31             |
+    When user "user0" shares file "/textfile0.txt" with user "user1" with permissions 19 using the sharing API
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
     And as "user1" file "/textfile0.txt" should exist
diff --git a/tests/acceptance/features/bootstrap/Sharing.php b/tests/acceptance/features/bootstrap/Sharing.php
index b56395bd69d0..48db5b535b5d 100644
--- a/tests/acceptance/features/bootstrap/Sharing.php
+++ b/tests/acceptance/features/bootstrap/Sharing.php
@@ -814,17 +814,21 @@ public function isUserOrGroupInSharedData($userOrGroup, $permissions = null) {
 	}
 
 	/**
-	 * @When /^user "([^"]*)" shares (?:file|folder|entry) "([^"]*)" with user "([^"]*)"(?: with permissions (.*))? using the sharing API$/
 	 *
 	 * @param string $user1
 	 * @param string $filepath
 	 * @param string $user2
 	 * @param string|int|string[]|int[] $permissions
+	 * @param bool $getShareData If true then only create the share if it is not
+	 *                           already existing, and at the end request the
+	 *                           share information and leave that in $this->response
+	 *                           Typically used in a "Given" step which verifies
+	 *                           that the share did get created successfully.
 	 *
 	 * @return void
 	 */
-	public function userSharesFileWithUserUsingTheSharingApi(
-		$user1, $filepath, $user2, $permissions = null
+	public function shareFileWithUserUsingTheSharingApi(
+		$user1, $filepath, $user2, $permissions = null, $getShareData = false
 	) {
 		$user1 = $this->getActualUsername($user1);
 		$user2 = $this->getActualUsername($user2);
@@ -834,15 +838,35 @@ public function userSharesFileWithUserUsingTheSharingApi(
 		$this->response = HttpRequestHelper::get(
 			$fullUrl, $user1, $this->getPasswordForUser($user1)
 		);
-		if ($this->isUserOrGroupInSharedData($user2, $permissions)) {
+		if ($getShareData && $this->isUserOrGroupInSharedData($user2, $permissions)) {
 			return;
 		} else {
 			$this->createShare(
 				$user1, $filepath, 0, $user2, null, null, $permissions
 			);
 		}
-		$this->response = HttpRequestHelper::get(
-			$fullUrl, $user1, $this->getPasswordForUser($user1)
+		if ($getShareData) {
+			$this->response = HttpRequestHelper::get(
+				$fullUrl, $user1, $this->getPasswordForUser($user1)
+			);
+		}
+	}
+
+	/**
+	 * @When /^user "([^"]*)" shares (?:file|folder|entry) "([^"]*)" with user "([^"]*)"(?: with permissions (.*))? using the sharing API$/
+	 *
+	 * @param string $user1
+	 * @param string $filepath
+	 * @param string $user2
+	 * @param string|int|string[]|int[] $permissions
+	 *
+	 * @return void
+	 */
+	public function userSharesFileWithUserUsingTheSharingApi(
+		$user1, $filepath, $user2, $permissions = null
+	) {
+		$this->shareFileWithUserUsingTheSharingApi(
+			$user1, $filepath, $user2, $permissions
 		);
 	}
 
@@ -859,8 +883,8 @@ public function userSharesFileWithUserUsingTheSharingApi(
 	public function userHasSharedFileWithUserUsingTheSharingApi(
 		$user1, $filepath, $user2, $permissions = null
 	) {
-		$this->userSharesFileWithUserUsingTheSharingApi(
-			$user1, $filepath, $user2, $permissions
+		$this->shareFileWithUserUsingTheSharingApi(
+			$user1, $filepath, $user2, $permissions, true
 		);
 		PHPUnit\Framework\Assert::assertTrue(
 			$this->isUserOrGroupInSharedData($user2, $permissions),
@@ -955,32 +979,56 @@ public function theUserHasSharedFileWithGroupUsingTheSharingApi(
 	}
 
 	/**
-	 * @When /^user "([^"]*)" shares (?:file|folder|entry) "([^"]*)" with group "([^"]*)"(?: with permissions (.*))? using the sharing API$/
 	 *
 	 * @param string $user
 	 * @param string $filepath
 	 * @param string $group
-	 * @param int $permissions
+	 * @param string|int|string[]|int[] $permissions
+	 * @param bool $getShareData If true then only create the share if it is not
+	 *                           already existing, and at the end request the
+	 *                           share information and leave that in $this->response
+	 *                           Typically used in a "Given" step which verifies
+	 *                           that the share did get created successfully.
 	 *
 	 * @return void
 	 */
-	public function userSharesFileWithGroupUsingTheSharingApi(
-		$user, $filepath, $group, $permissions = null
+	public function shareFileWithGroupUsingTheSharingApi(
+		$user, $filepath, $group, $permissions = null, $getShareData = false
 	) {
 		$fullUrl = $this->getBaseUrl()
 			. "/ocs/v{$this->ocsApiVersion}.php/apps/files_sharing/api/v{$this->sharingApiVersion}/shares?path=$filepath";
 		$this->response = HttpRequestHelper::get(
 			$fullUrl, $user, $this->getPasswordForUser($user)
 		);
-		if ($this->isUserOrGroupInSharedData($group, $permissions)) {
+		if ($getShareData && $this->isUserOrGroupInSharedData($group, $permissions)) {
 			return;
 		} else {
 			$this->createShare(
 				$user, $filepath, 1, $group, null, null, $permissions
 			);
 		}
-		$this->response = HttpRequestHelper::get(
-			$fullUrl, $user, $this->getPasswordForUser($user)
+		if ($getShareData) {
+			$this->response = HttpRequestHelper::get(
+				$fullUrl, $user, $this->getPasswordForUser($user)
+			);
+		}
+	}
+
+	/**
+	 * @When /^user "([^"]*)" shares (?:file|folder|entry) "([^"]*)" with group "([^"]*)"(?: with permissions (.*))? using the sharing API$/
+	 *
+	 * @param string $user
+	 * @param string $filepath
+	 * @param string $group
+	 * @param int $permissions
+	 *
+	 * @return void
+	 */
+	public function userSharesFileWithGroupUsingTheSharingApi(
+		$user, $filepath, $group, $permissions = null
+	) {
+		$this->shareFileWithGroupUsingTheSharingApi(
+			$user, $filepath, $group, $permissions
 		);
 	}
 
@@ -997,8 +1045,8 @@ public function userSharesFileWithGroupUsingTheSharingApi(
 	public function userHasSharedFileWithGroupUsingTheSharingApi(
 		$user, $filepath, $group, $permissions = null
 	) {
-		$this->userSharesFileWithGroupUsingTheSharingApi(
-			$user, $filepath, $group, $permissions
+		$this->shareFileWithGroupUsingTheSharingApi(
+			$user, $filepath, $group, $permissions, true
 		);
 
 		PHPUnit\Framework\Assert::assertEquals(

From 1b32ceb4a934c33d697f529dbe309e10950d834a Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Mon, 17 Jun 2019 14:47:05 +0545
Subject: [PATCH 128/131] Adjust tests for issue 33733 that now pass

---
 .../createShare.feature                       | 57 +++++++------------
 1 file changed, 21 insertions(+), 36 deletions(-)

diff --git a/tests/acceptance/features/apiShareManagementBasic/createShare.feature b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
index d377a3e553bf..c6d5f5a6aa39 100644
--- a/tests/acceptance/features/apiShareManagementBasic/createShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
@@ -290,7 +290,7 @@ Feature: sharing
       | 1               | 100             |
       | 2               | 200             |
 
-  @issue-33733 @public_link_share-feature-required
+  @public_link_share-feature-required
   Scenario Outline: Do not allow public sharing of the root
     Given using OCS API version "<ocs_api_version>"
     When user "user0" creates a public link share using the sharing API with settings
@@ -300,7 +300,6 @@ Feature: sharing
     Examples:
       | ocs_api_version | ocs_status_code | http_status_code |
       | 1               | 403             | 200              |
-    #  | 1               | 403             | 403              |
       | 2               | 403             | 403              |
 
   @public_link_share-feature-required
@@ -407,7 +406,6 @@ Feature: sharing
       | 1               | 100             |
       | 2               | 200             |
 
-  @issue-33733
   Scenario Outline: Cannot create share with zero permissions
     Given using OCS API version "<ocs_api_version>"
     And user "user1" has been created with default attributes and without skeleton files
@@ -416,15 +414,13 @@ Feature: sharing
       | shareWith   | user1       |
       | shareType   | 0           |
       | permissions | 0           |
-    Then the OCS status code should be "<ocs_status_code>"
+    Then the OCS status code should be "400"
     And the HTTP status code should be "<http_status_code>"
     Examples:
-      | ocs_api_version | ocs_status_code | http_status_code |
-      | 1               | 400             | 200              |
-    #  | 1               | 400             | 400              |
-      | 2               | 400             | 400              |
+      | ocs_api_version | http_status_code |
+      | 1               | 200              |
+      | 2               | 400              |
 
-  @issue-33733 @skipOnLDAP @user_ldap-issue-378
   Scenario Outline: user who is excluded from sharing tries to share a file with another user
     Given using OCS API version "<ocs_api_version>"
     And user "user1" has been created with default attributes and without skeleton files
@@ -434,17 +430,14 @@ Feature: sharing
     And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["excludedFromSharing"]'
     And user "user0" has moved file "welcome.txt" to "fileToShare.txt"
     When user "user0" shares file "fileToShare.txt" with user "user1" using the sharing API
-    Then the OCS status code should be "<ocs_status_code>"
+    Then the OCS status code should be "403"
     And the HTTP status code should be "<http_status_code>"
     And as "user1" file "fileToShare.txt" should not exist
     Examples:
-      | ocs_api_version | ocs_status_code | http_status_code |
-      | 1               | 100             | 200              |
-    #  | 1               | 403             | 403              |
-      | 2               | 200             | 200              |
-    #  | 2               | 403             | 403              |
+      | ocs_api_version | http_status_code |
+      | 1               | 200              |
+      | 2               | 403              |
 
-  @issue-33733
   Scenario Outline: user who is excluded from sharing tries to share a file with a group
     Given using OCS API version "<ocs_api_version>"
     And user "user1" has been created with default attributes and without skeleton files
@@ -456,17 +449,14 @@ Feature: sharing
     And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["excludedFromSharing"]'
     And user "user0" has moved file "welcome.txt" to "fileToShare.txt"
     When user "user0" shares file "fileToShare.txt" with group "anotherGroup" using the sharing API
-    Then the OCS status code should be "<ocs_status_code>"
+    Then the OCS status code should be "403"
     And the HTTP status code should be "<http_status_code>"
     And as "user1" file "fileToShare.txt" should not exist
     Examples:
-      | ocs_api_version | ocs_status_code | http_status_code |
-      | 1               | 100             | 200              |
-    #  | 1               | 403             | 403              |
-      | 2               | 200             | 200              |
-    #  | 2               | 403             | 403              |
+      | ocs_api_version | http_status_code |
+      | 1               | 200              |
+      | 2               | 403              |
 
-  @issue-33733 @skipOnLDAP @user_ldap-issue-378
   Scenario Outline: user who is excluded from sharing tries to share a folder with another user
     Given using OCS API version "<ocs_api_version>"
     And user "user1" has been created with default attributes and without skeleton files
@@ -476,17 +466,14 @@ Feature: sharing
     And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["excludedFromSharing"]'
     And user "user0" has created folder "folderToShare"
     When user "user0" shares folder "folderToShare" with user "user1" using the sharing API
-    Then the OCS status code should be "<ocs_status_code>"
+    Then the OCS status code should be "403"
     And the HTTP status code should be "<http_status_code>"
     And as "user1" folder "folderToShare" should not exist
     Examples:
-      | ocs_api_version | ocs_status_code | http_status_code |
-      | 1               | 100             | 200              |
-    #  | 1               | 403             | 403              |
-      | 2               | 200             | 200              |
-    #  | 2               | 403             | 403              |
+      | ocs_api_version | http_status_code |
+      | 1               | 200              |
+      | 2               | 403              |
 
-  @issue-33733
   Scenario Outline: user who is excluded from sharing tries to share a folder with a group
     Given using OCS API version "<ocs_api_version>"
     And user "user1" has been created with default attributes and without skeleton files
@@ -498,15 +485,13 @@ Feature: sharing
     And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["excludedFromSharing"]'
     And user "user0" has created folder "folderToShare"
     When user "user0" shares file "folderToShare" with group "anotherGroup" using the sharing API
-    Then the OCS status code should be "<ocs_status_code>"
+    Then the OCS status code should be "403"
     And the HTTP status code should be "<http_status_code>"
     And as "user1" file "folderToShare" should not exist
     Examples:
-      | ocs_api_version | ocs_status_code | http_status_code |
-      | 1               | 100             | 200              |
-    #  | 1               | 403             | 403              |
-      | 2               | 200             | 200              |
-    #  | 2               | 403             | 403              |
+      | ocs_api_version | http_status_code |
+      | 1               | 200              |
+      | 2               | 403              |
 
   Scenario Outline: user shares a file with file name longer than 64 chars to another user
     Given using OCS API version "<ocs_api_version>"

From 45d2b3b30b55c5dadba2283d55264f75b1985a23 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Mon, 17 Jun 2019 16:50:47 +0545
Subject: [PATCH 129/131] Add test scenarios for requesting combinations of
 permissions on a file share

---
 .../createShare.feature                       | 70 ++++++++++++++++++-
 1 file changed, 67 insertions(+), 3 deletions(-)

diff --git a/tests/acceptance/features/apiShareManagementBasic/createShare.feature b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
index c6d5f5a6aa39..2ecd0782f726 100644
--- a/tests/acceptance/features/apiShareManagementBasic/createShare.feature
+++ b/tests/acceptance/features/apiShareManagementBasic/createShare.feature
@@ -7,7 +7,7 @@ Feature: sharing
 
   @smokeTest
   @skipOnEncryptionType:user-keys @issue-32322
-  Scenario Outline: Creating a new share with user
+  Scenario Outline: Creating a share of a file with a user
     Given using OCS API version "<ocs_api_version>"
     And user "user1" has been created with default attributes and without skeleton files
     When user "user0" shares file "welcome.txt" with user "user1" using the sharing API
@@ -24,7 +24,54 @@ Feature: sharing
       | 1               | 100             |
       | 2               | 200             |
 
-  Scenario Outline: Creating a share with a group
+  Scenario Outline: Creating a share of a file with a user and asking for various permission combinations
+    Given using OCS API version "<ocs_api_version>"
+    And user "user1" has been created with default attributes and without skeleton files
+    When user "user0" shares file "welcome.txt" with user "user1" with permissions <requested_permissions> using the sharing API
+    Then the OCS status code should be "<ocs_status_code>"
+    And the HTTP status code should be "200"
+    And the fields of the last response should include
+      | share_with  | user1                 |
+      | file_target | /welcome.txt          |
+      | path        | /welcome.txt          |
+      | permissions | <granted_permissions> |
+      | uid_owner   | user0                 |
+    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 share (16), create and delete. You get share plus read
+      | 1               | 28                    | 17                  | 100             |
+      | 2               | 28                    | 17                  | 200             |
+      # Ask for read, update, create, delete. You get read plus update.
+      | 1               | 15                    | 3                   | 100             |
+      | 2               | 15                    | 3                   | 200             |
+      # Ask for create and delete. You get just read.
+      | 1               | 12                    | 1                   | 100             |
+      | 2               | 12                    | 1                   | 200             |
+      # Ask for just update. You get read plus update.
+      | 1               | 2                     | 3                   | 100             |
+      | 2               | 2                     | 3                   | 200             |
+
+  Scenario Outline: Creating a share of a folder with a user
+    Given using OCS API version "<ocs_api_version>"
+    And user "user1" has been created with default attributes and without skeleton files
+    When user "user0" shares folder "/FOLDER" with user "user1" using the sharing API
+    Then the OCS status code should be "<ocs_status_code>"
+    And the HTTP status code should be "200"
+    And the fields of the last response should include
+      | share_with  | user1   |
+      | file_target | /FOLDER |
+      | path        | /FOLDER |
+      | permissions | 31      |
+      | uid_owner   | user0   |
+    Examples:
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
+
+  Scenario Outline: Creating a share of a file with a group
     Given using OCS API version "<ocs_api_version>"
     And group "grp1" has been created
     When user "user0" shares file "/welcome.txt" with group "grp1" using the sharing API
@@ -41,6 +88,23 @@ Feature: sharing
       | 1               | 100             |
       | 2               | 200             |
 
+  Scenario Outline: Creating a share of a folder with a group
+    Given using OCS API version "<ocs_api_version>"
+    And group "grp1" has been created
+    When user "user0" shares folder "/FOLDER" with group "grp1" using the sharing API
+    Then the OCS status code should be "<ocs_status_code>"
+    And the HTTP status code should be "200"
+    And the fields of the last response should include
+      | share_with  | grp1    |
+      | file_target | /FOLDER |
+      | path        | /FOLDER |
+      | permissions | 31      |
+      | uid_owner   | user0   |
+    Examples:
+      | ocs_api_version | ocs_status_code |
+      | 1               | 100             |
+      | 2               | 200             |
+
   Scenario Outline: Creating a new share with user who already received a share through their group
     Given using OCS API version "<ocs_api_version>"
     And user "user1" has been created with default attributes and without skeleton files
@@ -124,7 +188,7 @@ Feature: sharing
       | 2               | 200             |
 
   @public_link_share-feature-required
-  Scenario Outline: Getting the share information of public link share form OCS API does not expose sensitive information
+  Scenario Outline: Getting the share information of public link share from the OCS API does not expose sensitive information
     Given using OCS API version "<ocs_api_version>"
     When user "user0" creates a public link share using the sharing API with settings
       | path     | welcome.txt   |

From ff783808607300237473796e4de1e74aaf1c8761 Mon Sep 17 00:00:00 2001
From: Artur Neumann <artur@jankaritech.com>
Date: Mon, 17 Jun 2019 15:44:00 +0545
Subject: [PATCH 130/131] test app version after app was updated to new patch
 version

---
 .../features/apiMain/appmanagement.feature    | 16 +++++
 .../bootstrap/AppManagementContext.php        | 58 +++++++++++++++++++
 2 files changed, 74 insertions(+)

diff --git a/tests/acceptance/features/apiMain/appmanagement.feature b/tests/acceptance/features/apiMain/appmanagement.feature
index 41c3401521b9..dbb41f877ee1 100644
--- a/tests/acceptance/features/apiMain/appmanagement.feature
+++ b/tests/acceptance/features/apiMain/appmanagement.feature
@@ -15,3 +15,19 @@ Feature: AppManagement
     And app "multidirtest" with version "1.0.5" has been put in dir "apps2"
     When the administrator gets the path for app "multidirtest" using the occ command
     Then the path to "multidirtest" should be "apps2"
+
+  Scenario: Update of patch version of an app
+    Given 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 but update is put in alternative folder
+    Given 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 "apps2"
+    And the administrator enables app "updatetest"
+    Then the installed version of "updatetest" should be "2.0.1"
\ No newline at end of file
diff --git a/tests/acceptance/features/bootstrap/AppManagementContext.php b/tests/acceptance/features/bootstrap/AppManagementContext.php
index 140525441485..a4082bdca443 100644
--- a/tests/acceptance/features/bootstrap/AppManagementContext.php
+++ b/tests/acceptance/features/bootstrap/AppManagementContext.php
@@ -21,6 +21,7 @@
 
 use Behat\Behat\Context\Context;
 use Behat\Behat\Hook\Scope\BeforeScenarioScope;
+use PHPUnit\Framework\Assert;
 use TestHelpers\SetupHelper;
 
 require __DIR__ . '/../../../../lib/composer/autoload.php';
@@ -42,6 +43,11 @@ class AppManagementContext implements Context {
 	 */
 	private $cmdOutput;
 
+	/**
+	 * @var string[]
+	 */
+	private $createdApps = [];
+
 	/**
 	 *
 	 * @param array $appsPaths of apps_paths entries
@@ -82,6 +88,7 @@ public function setAppDirectories($dir1, $dir2) {
 
 	/**
 	 * @Given app :appId with version :version has been put in dir :dir
+	 * @When the administrator puts app :appId with version :version in dir :dir
 	 *
 	 * @param string $appId app id
 	 * @param string $version app version
@@ -119,6 +126,13 @@ public function appHasBeenPutInDir($appId, $version, $dir) {
 		$targetDir = "$dir/$appId/appinfo";
 		$this->featureContext->mkDirOnServer($targetDir);
 		$this->featureContext->createFileOnServerWithContent("$targetDir/info.xml", $appInfo);
+		if (!\array_key_exists($appId, $this->createdApps)) {
+			$this->createdApps[$appId][] = $targetDir;
+		} else {
+			if (!\in_array($targetDir, $this->createdApps[$appId])) {
+				$this->createdApps[$appId][] = $targetDir;
+			}
+		}
 	}
 
 	/**
@@ -150,6 +164,21 @@ public function appPathIs($appId, $dir) {
 		);
 	}
 
+	/**
+	 * @Then the installed version of :appId should be :version
+	 *
+	 * @param string $appId
+	 * @param string $version
+	 *
+	 * @return void
+	 */
+	public function assertInstalledVersionOfAppIs($appId, $version) {
+		$cmdOutput = SetupHelper::runOcc(
+			['config:app:get', $appId, 'installed_version', '--no-ansi']
+		)['stdOut'];
+		PHPUnit\Framework\Assert::assertEquals($version, \trim($cmdOutput));
+	}
+
 	/**
 	 * This will run before EVERY scenario.
 	 * It will set the properties for this object.
@@ -192,4 +221,33 @@ public function undoChangingParameters() {
 			$this->setAppsPaths($this->oldAppsPaths);
 		}
 	}
+
+	/**
+	 * @AfterScenario
+	 *
+	 * delete created apps including files and values in DB after each scenario
+	 *
+	 * @return void
+	 * @throws Exception
+	 */
+	public function deleteCreatedApps() {
+		$configJson = SetupHelper::runOcc(['config:list'])['stdOut'];
+		$configList = \json_decode($configJson, true);
+		foreach ($this->createdApps as $app => $paths) {
+			//disable the app
+			$this->featureContext->appHasBeenDisabled($app, 'disables');
+
+			//delete config values out of the database
+			if (\array_key_exists($app, $configList['apps'])) {
+				foreach ($configList['apps'][$app] as $key => $value) {
+					SetupHelper::runOcc(['config:app:delete', $app, $key]);
+				}
+			}
+
+			//delete the app from the drive
+			foreach ($paths as $path) {
+				SetupHelper::rmDirOnServer(\dirname($path));
+			}
+		}
+	}
 }

From b71b326796d175bb9d618c6fd63a443efaecaa40 Mon Sep 17 00:00:00 2001
From: Phil Davis <phil@jankaritech.com>
Date: Tue, 18 Jun 2019 15:44:13 +0545
Subject: [PATCH 131/131] Revert "[stable10] Backport of Accessing sharetab
 directly for a long list of files"

This reverts commit 86066adb1e879c2670f674bba3b10c91f05032e6.
---
 apps/files/js/filelist.js                     | 12 ---
 .../browseDirectlyToDetailsTab.feature        | 73 +++++++++++++------
 2 files changed, 52 insertions(+), 33 deletions(-)

diff --git a/apps/files/js/filelist.js b/apps/files/js/filelist.js
index e76008dc344b..f8312fcb569e 100644
--- a/apps/files/js/filelist.js
+++ b/apps/files/js/filelist.js
@@ -2533,18 +2533,6 @@
 			}
 			if (!_.isUndefined(detailTabId)) {
 				var filename = file[file.length - 1];
-				//Double check if the area that you are scrolling is beyond the page limit?
-				var pageSize = this.pageSize();
-				var index = _.findIndex(this.files, function (obj) {
-					return obj.name === filename;
-				});
-				if (index >= pageSize) {
-					var numberOfMorePagesToScroll = Math.floor(index / pageSize);
-					while (numberOfMorePagesToScroll > 0) {
-						this._nextPage();
-						numberOfMorePagesToScroll--;
-					}
-				}
 				this.showDetailsView(filename, detailTabId);
 			}
 			this.highlightFiles(file, function($tr) {
diff --git a/tests/acceptance/features/webUIFiles/browseDirectlyToDetailsTab.feature b/tests/acceptance/features/webUIFiles/browseDirectlyToDetailsTab.feature
index c77cdedc172e..62594dd2d8a8 100644
--- a/tests/acceptance/features/webUIFiles/browseDirectlyToDetailsTab.feature
+++ b/tests/acceptance/features/webUIFiles/browseDirectlyToDetailsTab.feature
@@ -22,13 +22,24 @@ Feature: browse directly to details tab
     And the "sharing" details panel should be visible
     And the share-with field should be visible in the details panel
     Examples:
-      | file                                 | folder        | comment                     |
-      | block-aligned.txt                    | /             | one of the first files      |
-      | block-aligned.txt                    | simple-folder | one of the first files      |
-      | lorem.txt                            | /             | a file somewhere in between |
-      | lorem.txt                            | simple-folder | a file somewhere in between |
-      | zzzz-must-be-last-file-in-folder.txt | /             | last file                   |
-      | zzzz-must-be-last-file-in-folder.txt | simple-folder | last file                   |
+      | file              | folder        | comment                     |
+      | block-aligned.txt | /             | one of the first files      |
+      | block-aligned.txt | simple-folder | one of the first files      |
+      | lorem.txt         | /             | a file somewhere in between |
+      | lorem.txt         | simple-folder | a file somewhere in between |
+
+  #merge this tests into previous scenario when bug is fixed
+  @smokeTest
+  @issue-35200
+  Scenario Outline: Browse directly to the sharing details of a file
+    When the user tries to browse directly to display the "sharing" details of file "<file>" in folder "<folder>"
+    #Then the thumbnail should be visible in the details panel
+    Then the "sharing" details panel should be visible
+    #And the share-with field should be visible in the details panel
+    Examples:
+      | file                                 | folder        | comment   |
+      | zzzz-must-be-last-file-in-folder.txt | /             | last file |
+      | zzzz-must-be-last-file-in-folder.txt | simple-folder | last file |
 
   @comments-app-required
   Scenario Outline: Browse directly to the comments details of a file
@@ -36,13 +47,23 @@ Feature: browse directly to details tab
     Then the thumbnail should be visible in the details panel
     And the "comments" details panel should be visible
     Examples:
-      | file                                 | folder        | comment                     |
-      | block-aligned.txt                    | /             | one of the first files      |
-      | block-aligned.txt                    | simple-folder | one of the first files      |
-      | lorem.txt                            | /             | a file somewhere in between |
-      | lorem.txt                            | simple-folder | a file somewhere in between |
-      | zzzz-must-be-last-file-in-folder.txt | /             | last file                   |
-      | zzzz-must-be-last-file-in-folder.txt | simple-folder | last file                   |
+      | file              | folder        | comment                     |
+      | block-aligned.txt | /             | one of the first files      |
+      | block-aligned.txt | simple-folder | one of the first files      |
+      | lorem.txt         | /             | a file somewhere in between |
+      | lorem.txt         | simple-folder | a file somewhere in between |
+
+  #merge this tests into previous scenario when bug is fixed
+  @issue-35200
+  @comments-app-required
+  Scenario Outline: Browse directly to the comments details of a file
+    When the user tries to browse directly to display the "comments" details of file "<file>" in folder "<folder>"
+    #Then the thumbnail should be visible in the details panel
+    Then the "comments" details panel should be visible
+    Examples:
+      | file                                 | folder        | comment   |
+      | zzzz-must-be-last-file-in-folder.txt | /             | last file |
+      | zzzz-must-be-last-file-in-folder.txt | simple-folder | last file |
 
   @files_versions-app-required
   Scenario Outline: Browse directly to the versions details of a file
@@ -50,10 +71,20 @@ Feature: browse directly to details tab
     Then the thumbnail should be visible in the details panel
     And the "versions" details panel should be visible
     Examples:
-      | file                                 | folder        | comment                     |
-      | block-aligned.txt                    | /             | one of the first files      |
-      | block-aligned.txt                    | simple-folder | one of the first files      |
-      | lorem.txt                            | /             | a file somewhere in between |
-      | lorem.txt                            | simple-folder | a file somewhere in between |
-      | zzzz-must-be-last-file-in-folder.txt | /             | last file                   |
-      | zzzz-must-be-last-file-in-folder.txt | simple-folder | last file                   |
+      | file              | folder        | comment                     |
+      | block-aligned.txt | /             | one of the first files      |
+      | block-aligned.txt | simple-folder | one of the first files      |
+      | lorem.txt         | /             | a file somewhere in between |
+      | lorem.txt         | simple-folder | a file somewhere in between |
+
+  #merge this tests into previous scenario when bug is fixed
+  @issue-35200
+  @files_versions-app-required
+  Scenario Outline: Browse directly to the versions details of a file
+    When the user tries to browse directly to display the "versions" details of file "<file>" in folder "<folder>"
+    #Then the thumbnail should be visible in the details panel
+    Then the "versions" details panel should be visible
+    Examples:
+      | file                                 | folder        | comment   |
+      | zzzz-must-be-last-file-in-folder.txt | /             | last file |
+      | zzzz-must-be-last-file-in-folder.txt | simple-folder | last file |