refactor scenario example table (#6694)

tests/acceptance/expected-failures-API-on-OCIS-storage.md

@@ -164,19 +164,19 @@ File and sync features in a shared scenario
 - [coreApiShareManagementToShares/acceptShares.feature:524](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature#L524)
 - [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:39](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L39)
 - [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:40](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L40)
-- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:130](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L130)
+- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:128](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L128)
-- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:131](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L131)
+- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:129](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L129)
-- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:165](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L165)
+- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:161](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L161)
-- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:166](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L166)
+- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:162](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L162)
 
 #### [sharing the shares folder to users exits with different status code than in oc10 backend](https://github.com/owncloud/ocis/issues/2215)
 
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:743](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L743)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:733](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L733)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:744](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L744)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:734](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L734)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:762](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L762)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:752](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L752)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:763](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L763)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:753](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L753)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:778](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L778)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:768](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L768)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:779](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L779)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:769](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L769)
 
 #### [file_target of an auto-renamed file is not correct directly after sharing](https://github.com/owncloud/core/issues/32322)
 
@@ -184,15 +184,15 @@ File and sync features in a shared scenario
 
 #### [File deletion using dav gives unique string in filename in the trashbin](https://github.com/owncloud/product/issues/178)
 
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:64](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L64)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:61](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L61)
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:78](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L78)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:75](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L75)
 
 cannot share a folder with create permission
 
 #### [Resource with share permission create is readable for sharee](https://github.com/owncloud/ocis/issues/4524)
 
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:131](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L131)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:125](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L125)
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:144](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L144)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:138](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L138)
 
 
 #### [OCS error message for attempting to access share via share id as an unauthorized user is not informative](https://github.com/owncloud/ocis/issues/1233)
@@ -267,7 +267,7 @@ cannot share a folder with create permission
 - [coreApiShareOperationsToShares1/changingFilesShare.feature:71](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareOperationsToShares1/changingFilesShare.feature#L71)
 - [coreApiShareOperationsToShares1/changingFilesShare.feature:92](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareOperationsToShares1/changingFilesShare.feature#L92)
 - [coreApiShareOperationsToShares1/changingFilesShare.feature:93](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareOperationsToShares1/changingFilesShare.feature#L93)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:534](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L534)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:533](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L533)
 - [coreApiWebdavMove2/moveShareOnOcis.feature:30](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavMove2/moveShareOnOcis.feature#L30)
 - [coreApiWebdavMove2/moveShareOnOcis.feature:32](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavMove2/moveShareOnOcis.feature#L32)
 - [coreApiWebdavMove2/moveShareOnOcis.feature:98](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavMove2/moveShareOnOcis.feature#L98)
@@ -289,37 +289,37 @@ cannot share a folder with create permission
 
 #### [Cannot move folder/file from one received share to another](https://github.com/owncloud/ocis/issues/2442)
 
-- [coreApiShareUpdateToShares/updateShare.feature:197](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L197)
 - [coreApiShareUpdateToShares/updateShare.feature:161](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L161)
+- [coreApiShareUpdateToShares/updateShare.feature:129](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L129)
 - [coreApiShareManagementToShares/mergeShare.feature:131](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementToShares/mergeShare.feature#L131)
 
 #### [Sharing folder and sub-folder with same user but different permission,the permission of sub-folder is not obeyed ](https://github.com/owncloud/ocis/issues/2440)
 
-- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:262](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L262)
+- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:222](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L222)
-- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:297](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L297)
+- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:253](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L253)
-- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:406](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L406)
+- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:352](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L352)
-- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:441](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L441)
+- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:383](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L383)
 
 #### [Empty OCS response for a share create request using a disabled user](https://github.com/owncloud/ocis/issues/2212)
 
 - [coreApiShareCreateSpecialToShares2/createShareWithDisabledUser.feature:21](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWithDisabledUser.feature#L21)
-- [coreApiShareCreateSpecialToShares2/createShareWithDisabledUser.feature:24](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWithDisabledUser.feature#L24)
+- [coreApiShareCreateSpecialToShares2/createShareWithDisabledUser.feature:12](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWithDisabledUser.feature#L12)
 
 
 #### [Edit user share response has a "name" field](https://github.com/owncloud/ocis/issues/1225)
 
-- [coreApiShareUpdateToShares/updateShare.feature:243](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L243)
+- [coreApiShareUpdateToShares/updateShare.feature:236](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L236)
-- [coreApiShareUpdateToShares/updateShare.feature:244](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L244)
+- [coreApiShareUpdateToShares/updateShare.feature:237](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L237)
 
 #### [Share lists deleted user as 'user'](https://github.com/owncloud/ocis/issues/903)
 
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:678](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L678)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:668](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L668)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:679](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L679)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:669](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L669)
 
 #### [deleting a share with wrong authentication returns OCS status 996 / HTTP 500](https://github.com/owncloud/ocis/issues/1229)
 
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:227](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L227)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:221](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L221)
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:228](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L228)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:222](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L222)
 
 ### User Management
 
@@ -451,8 +451,8 @@ And other missing implementation of favorites
 
 #### [Sharing a same file twice to the same group](https://github.com/owncloud/ocis/issues/1710)
 
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:726](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L726)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:716](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L716)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:727](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L727)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:717](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L717)
 
 #### [PATCH request for TUS upload with wrong checksum gives incorrect response](https://github.com/owncloud/ocis/issues/1755)
 
@@ -521,7 +521,7 @@ And other missing implementation of favorites
 #### [Shares to deleted group listed in the response](https://github.com/owncloud/ocis/issues/2441)
 
 - [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:530](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L530)
-- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:531](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L531)
+- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:529](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L529)
 
 #### [copying the file inside Shares folder returns 404](https://github.com/owncloud/ocis/issues/3874)
 
@@ -577,14 +577,14 @@ Not everything needs to be implemented for ocis. While the oc10 testsuite covers
 - [coreApiShareManagementToShares/acceptShares.feature:438](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature#L438)
 - [coreApiShareOperationsToShares2/shareAccessByID.feature:122](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareOperationsToShares2/shareAccessByID.feature#L122)
 - [coreApiShareOperationsToShares2/shareAccessByID.feature:123](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareOperationsToShares2/shareAccessByID.feature#L123)
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:178](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L178)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:172](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L172)
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:179](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L179)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:173](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L173)
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:180](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L180)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:174](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L174)
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:181](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L181)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:175](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L175)
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:197](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L197)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:191](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L191)
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:198](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L198)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:192](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L192)
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:199](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L199)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:193](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L193)
-- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:200](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L200)
+- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:194](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L194)
 
 #### [Content-type is not multipart/byteranges when downloading file with Range Header](https://github.com/owncloud/ocis/issues/2677)
 

tests/acceptance/features/apiGraph/editUser.feature

@@ -186,7 +186,7 @@ Feature: edit user
       | User        | Admin       |
       | User Light  | Space Admin |
       | User Light  | User        |
-      | User Light  | User Light       |
+      | User Light  | User Light  |
       | User Light  | Admin       |
 
 
@@ -209,11 +209,11 @@ Feature: edit user
     }
     """
     Examples:
-      | action description                | newDisplayName | code | displayNameAsResult |
+      | action description                | newDisplayName | displayNameAsResult |
-      | change to a display name          | Olaf Scholz    | 200  | Olaf Scholz         |
+      | change to a display name          | Olaf Scholz    | Olaf Scholz         |
-      | override to existing display name | Carol King     | 200  | Carol King          |
+      | override to existing display name | Carol King     | Carol King          |
-      | change to an empty display name   |                | 400  | Brian Murphy        |
+      | change to an empty display name   |                | Brian Murphy        |
-      | displayName with characters       | *:!;_+-&#(?)   | 200  | *:!;_+-&#(?)        |
+      | displayName with characters       | *:!;_+-&#(?)   | *:!;_+-&#(?)        |
 
 
   Scenario Outline: normal user should not be able to change his/her own display name
@@ -239,7 +239,7 @@ Feature: edit user
       | role        |
       | Space Admin |
       | User        |
-      | User Light       |
+      | User Light  |
 
 
   Scenario Outline: normal user should not be able to edit another user's display name
@@ -500,4 +500,4 @@ Feature: edit user
       | role        |
       | Space Admin |
       | User        |
-      | User Light       |
+      | User Light  |

tests/acceptance/features/apiGraph/getUser.feature

@@ -90,7 +90,7 @@ Feature: get users
       | User        | Admin       |
       | User Light  | Space Admin |
       | User Light  | User        |
-      | User Light  | User Light       |
+      | User Light  | User Light  |
       | User Light  | Admin       |
 
   @skipOnStable2.0

tests/acceptance/features/apiSpaces/quota.feature

@@ -21,7 +21,7 @@ Feature: State of the quota
 
 
   Scenario Outline: quota information is returned in the list of spaces returned via the Graph API
-    Given user "Alice" has created a space "<spaceName>" of type "project" with quota "<total>"
+    Given user "Alice" has created a space "<spaceName>" of type "project" with quota "100"
     When user "Alice" uploads a file inside space "<spaceName>" with content "<fileContent>" to "test.txt" using the WebDAV API
     And user "Alice" lists all available spaces via the GraphApi
     Then the JSON response should contain space called "<spaceName>" and match
@@ -52,7 +52,7 @@ Feature: State of the quota
             },
             "total" : {
               "type": "number",
-              "enum": [<total>]
+              "enum": [100]
             },
             "remaining" : {
               "type": "number",
@@ -68,14 +68,14 @@ Feature: State of the quota
     }
     """
     Examples:
-      | spaceName | fileContent                                                                                           | state    | total | remaining | used |
+      | spaceName | fileContent                                                                                          | state    | remaining | used |
-      | Quota1%   | 1                                                                                                    | normal   | 100   | 99        | 1    |
+      | Quota1%   | 1                                                                                                    | normal   | 99        | 1    |
-      | Quota75%  | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12345                          | normal   | 100   | 25        | 75   |
+      | Quota75%  | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12345                          | normal   | 25        | 75   |
-      | Quota76%  | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456                         | nearing  | 100   | 24        | 76   |
+      | Quota76%  | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456                         | nearing  | 24        | 76   |
-      | Quota90%  | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1234567890           | nearing  | 100   | 10        | 90   |
+      | Quota90%  | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1234567890           | nearing  | 10        | 90   |
-      | Quota91%  | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1          | critical | 100   | 9         | 91   |
+      | Quota91%  | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1          | critical | 9         | 91   |
-      | Quota99%  | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789  | critical | 100   | 1         | 99   |
+      | Quota99%  | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789  | critical | 1         | 99   |
-      | Quota100% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1234567890 | exceeded | 100   | 0         | 100  |
+      | Quota100% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1234567890 | exceeded | 0         | 100  |
 
 
   Scenario: file cannot be uploaded if there is insufficient quota

tests/acceptance/features/apiSpaces/removeSpaceObjects.feature

@@ -1,4 +1,4 @@
-@api 
+@api
 Feature: Remove files, folder
   As a user
   I want to be able to remove files, folders
@@ -65,11 +65,11 @@ Feature: Remove files, folder
       | text.txt |
     And as "<user>" file "text.txt" <shouldOrNotBeInTrash> exist in the trashbin of the space "delete objects"
     Examples:
-      | user  | role    | code | shouldOrNotBeInSpace | shouldOrNotBeInTrash | quotaValue |
+      | user  | role    | code | shouldOrNotBeInSpace | shouldOrNotBeInTrash |
-      | Alice | manager | 204  | should not           | should               | 0          |
+      | Alice | manager | 204  | should not           | should               |
-      | Brian | manager | 204  | should not           | should               | 0          |
+      | Brian | manager | 204  | should not           | should               |
-      | Brian | editor  | 204  | should not           | should               | 0          |
+      | Brian | editor  | 204  | should not           | should               |
-      | Brian | viewer  | 403  | should               | should not           | 12         |
+      | Brian | viewer  | 403  | should               | should not           |
 
 
   Scenario: try to delete an empty string folder from a space

tests/acceptance/features/apiSpaces/restoreSpaceObjects.feature

@@ -1,4 +1,4 @@
-@api 
+@api
 Feature: Restore files, folder
   As a user with manager and editor role
   I want to be able to restore files, folders
@@ -27,15 +27,15 @@ Feature: Restore files, folder
       | role      | <role> |
     And user "Alice" has removed the file "newFolder/file.txt" from space "restore objects"
     And user "Alice" has removed the folder "newFolder" from space "restore objects"
-    When user "<user>" lists all deleted files in the trash bin of the space "restore objects"
+    When user "Brian" lists all deleted files in the trash bin of the space "restore objects"
     Then the HTTP status code should be "207"
-    And as "<user>" folder "newFolder" should exist in the trashbin of the space "restore objects"
+    And as "Brian" folder "newFolder" should exist in the trashbin of the space "restore objects"
-    And as "<user>" file "file.txt" should exist in the trashbin of the space "restore objects"
+    And as "Brian" file "file.txt" should exist in the trashbin of the space "restore objects"
     Examples:
-      | user  | role    |
+      | role    |
-      | Brian | manager |
+      | manager |
-      | Brian | editor  |
+      | editor  |
-      | Brian | viewer  |
+      | viewer  |
 
 
   Scenario Outline: user can restore a folder with some objects from the trash via the webDav API

tests/acceptance/features/apiSpacesShares/shareSubItemOfSpace.feature

@@ -74,15 +74,15 @@ Feature: Share a file or folder that is inside a space
       | path      | <entity> |
       | shareWith | Bob      |
       | role      | editor   |
-    Then the HTTP status code should be "<statusCode>"
+    Then the HTTP status code should be "404"
-    And the OCS status code should be "<statusCode>"
+    And the OCS status code should be "404"
-    And the OCS status message should be "<statusMessage>"
+    And the OCS status message should be "No share permission"
     Examples:
-      | entity   | spaceRole | statusCode | statusMessage       |
+      | entity   | spaceRole |
-      | folder   | editor    | 404        | No share permission |
+      | folder   | editor    |
-      | file.txt | editor    | 404        | No share permission |
+      | file.txt | editor    |
-      | file.txt | viewer    | 404        | No share permission |
+      | file.txt | viewer    |
-      | folder   | viewer    | 404        | No share permission |
+      | folder   | viewer    |
 
 
   Scenario Outline: user participant of the project space can see the created resources share

tests/acceptance/features/coreApiAuthWebDav/webDavCOPYAuth.feature

@@ -51,14 +51,14 @@ Feature: COPY file/folder
       | /remote.php/dav/files/%username%/PARENT/parent.txt |
     Then the HTTP status code of responses on all endpoints should be "403"
 
- @skipOnRevaMaster
+  @skipOnRevaMaster
- Scenario: send COPY requests to another user's webDav endpoints as normal user using the spaces WebDAV API
+  Scenario: send COPY requests to another user's webDav endpoints as normal user using the spaces WebDAV API
-   When user "Brian" requests these endpoints with "COPY" about user "Alice"
+    When user "Brian" requests these endpoints with "COPY" about user "Alice"
-     | endpoint                                           |
+      | endpoint                                           |
-     | /remote.php/dav/spaces/%spaceid%/textfile0.txt     |
+      | /remote.php/dav/spaces/%spaceid%/textfile0.txt     |
-     | /remote.php/dav/spaces/%spaceid%/PARENT            |
+      | /remote.php/dav/spaces/%spaceid%/PARENT            |
-     | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt |
+      | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt |
-   Then the HTTP status code of responses on all endpoints should be "403"
+    Then the HTTP status code of responses on all endpoints should be "403"
 
 
   Scenario: send COPY requests to webDav endpoints using invalid username but correct password
@@ -114,7 +114,7 @@ Feature: COPY file/folder
       | /remote.php/dav/files/%username%/PARENT/parent.txt |
     Then the HTTP status code of responses on all endpoints should be "415"
 
- @skipOnRevaMaster
+  @skipOnRevaMaster
   Scenario: send COPY requests to webDav endpoints with body as normal user using the spaces WebDAV API
     When user "Alice" requests these endpoints with "COPY" including body "doesnotmatter" about user "Alice"
       | endpoint                                           |

tests/acceptance/features/coreApiCapabilities/capabilities.feature

@@ -93,7 +93,7 @@ Feature: capabilities
     }
     """
 
- @skipOnReva
+  @skipOnReva
   Scenario: getting versions app capability with admin user
     When the administrator retrieves the capabilities using the capabilities API
     Then the OCS status code should be "100"

tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature

@@ -25,7 +25,7 @@ Feature: share resources where the sharee receives the share in multiple ways
     And the fields of the last response to user "Alice" sharing with user "Brian" should include
       | share_with             | %username%                |
       | share_with_displayname | %displayname%             |
-      | file_target            | <file_target>             |
+      | file_target            | /textfile0 (2).txt        |
       | path                   | /Shares/textfile0 (2).txt |
       | permissions            | share,read,update         |
       | uid_owner              | %username%                |
@@ -35,9 +35,9 @@ Feature: share resources where the sharee receives the share in multiple ways
       | storage_id             | ANY_VALUE                 |
       | share_type             | user                      |
     Examples:
-      | ocs_api_version | ocs_status_code | file_target        |
+      | ocs_api_version | ocs_status_code |
-      | 1               | 100             | /textfile0 (2).txt |
+      | 1               | 100             |
-      | 2               | 200             | /textfile0 (2).txt |
+      | 2               | 200             |
 
   @issue-1289
   Scenario Outline: share of folder and sub-folder to same user
@@ -53,16 +53,16 @@ Feature: share resources where the sharee receives the share in multiple ways
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
     And user "Brian" should be able to accept pending share "/PARENT" offered by user "Alice"
-    And user "Brian" should be able to accept pending share "<pending_sub_share_path>" offered by user "Alice"
+    And user "Brian" should be able to accept pending share "/CHILD" offered by user "Alice"
     And user "Brian" should see the following elements
       | /Shares/PARENT/           |
       | /Shares/PARENT/parent.txt |
       | /Shares/CHILD/            |
       | /Shares/CHILD/child.txt   |
     Examples:
-      | ocs_api_version | ocs_status_code | pending_sub_share_path |
+      | ocs_api_version | ocs_status_code |
-      | 1               | 100             | /CHILD                 |
+      | 1               | 100             |
-      | 2               | 200             | /CHILD                 |
+      | 2               | 200             |
 
   @issue-2021
   Scenario Outline: sharing subfolder when parent already shared
@@ -74,12 +74,12 @@ Feature: share resources where the sharee receives the share in multiple ways
     When user "Alice" shares folder "/test/sub" with user "Brian" using the sharing API
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
-    And user "Brian" should be able to accept pending share "<pending_share_path>" offered by user "Alice"
+    And user "Brian" should be able to accept pending share "/sub" offered by user "Alice"
     And as "Brian" folder "/Shares/sub" should exist
     Examples:
-      | ocs_api_version | ocs_status_code | pending_share_path |
+      | ocs_api_version | ocs_status_code |
-      | 1               | 100             | /sub               |
+      | 1               | 100             |
-      | 2               | 200             | /sub               |
+      | 2               | 200             |
 
   @issue-2021
   Scenario Outline: sharing subfolder when parent already shared with group of sharer
@@ -92,14 +92,14 @@ Feature: share resources where the sharee receives the share in multiple ways
     When user "Alice" shares folder "/test/sub" with user "Brian" using the sharing API
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
-    And user "Brian" should be able to accept pending share "<pending_share_path>" offered by user "Alice"
+    And user "Brian" should be able to accept pending share "/sub" offered by user "Alice"
     And as "Brian" folder "/Shares/sub" should exist
     Examples:
-      | ocs_api_version | ocs_status_code | pending_share_path |
+      | ocs_api_version | ocs_status_code |
-      | 1               | 100             | /sub               |
+      | 1               | 100             |
-      | 2               | 200             | /sub               |
+      | 2               | 200             |
-
 
+  @issue-2131
   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 user "Carol" has been created with default attributes and without skeleton files
@@ -110,27 +110,25 @@ Feature: share resources where the sharee receives the share in multiple ways
     Then as "Alice" the info about the last share by user "Brian" with user "Alice" should include
       | uid_owner   | %username%      |
       | share_with  | %username%      |
-      | file_target | <file_target_1> |
+      | file_target | /randomfile.txt |
       | item_type   | file            |
       | permissions | read            |
     When user "Carol" shares file "randomfile.txt" with user "Alice" with permissions "read,update" using the sharing API
     And user "Alice" accepts share "/randomfile.txt" offered by user "Carol" using the sharing API
     Then as "Alice" the info about the last share by user "Carol" with user "Alice" should include
-      | uid_owner   | %username%      |
+      | uid_owner   | %username%          |
-      | share_with  | %username%      |
+      | share_with  | %username%          |
-      | file_target | <file_target_2> |
+      | file_target | /randomfile (2).txt |
-      | item_type   | file            |
+      | item_type   | file                |
-      | permissions | read,update     |
+      | permissions | read,update         |
     And the content of file "/Shares/randomfile.txt" for user "Alice" should be "First data"
     And the content of file "/Shares/randomfile (2).txt" for user "Alice" should be "Second data"
-
-    @issue-2131
     Examples:
-      | ocs_api_version | file_target_1   | file_target_2       |
+      | ocs_api_version |
-      | 1               | /randomfile.txt | /randomfile (2).txt |
+      | 1               |
-      | 2               | /randomfile.txt | /randomfile (2).txt |
+      | 2               |
-
 
+  @issue-2131
   Scenario Outline: multiple users share a folder with the same name to a user
     Given using OCS API version "<ocs_api_version>"
     And user "Carol" has been created with default attributes and without skeleton files
@@ -141,31 +139,29 @@ Feature: share resources where the sharee receives the share in multiple ways
     When user "Brian" shares folder "zzzfolder" with user "Alice" with permissions "read,delete" using the sharing API
     And user "Alice" accepts share "/zzzfolder" offered by user "Brian" using the sharing API
     Then as "Alice" the info about the last share by user "Brian" with user "Alice" should include
-      | uid_owner   | %username%      |
+      | uid_owner   | %username%  |
-      | share_with  | %username%      |
+      | share_with  | %username%  |
-      | file_target | <file_target_1> |
+      | file_target | /zzzfolder  |
-      | item_type   | folder          |
+      | item_type   | folder      |
-      | permissions | read,delete     |
+      | permissions | read,delete |
     When user "Carol" shares folder "zzzfolder" with user "Alice" with permissions "read,share" using the sharing API
     Then the HTTP status code should be "200"
     And the OCS status code should be "<ocs_status_code>"
     And user "Alice" should be able to accept pending share "/zzzfolder" offered by user "Carol"
     Then as "Alice" the info about the last share by user "Carol" with user "Alice" should include
-      | uid_owner   | %username%      |
+      | uid_owner   | %username%     |
-      | share_with  | %username%      |
+      | share_with  | %username%     |
-      | file_target | <file_target_2> |
+      | file_target | /zzzfolder (2) |
-      | item_type   | folder          |
+      | item_type   | folder         |
-      | permissions | read,share      |
+      | permissions | read,share     |
     And as "Alice" folder "/Shares/zzzfolder/Brian" should exist
     And as "Alice" folder "/Shares/zzzfolder (2)/Carol" should exist
-
-    @issue-2131
     Examples:
-      | ocs_api_version | file_target_1 | file_target_2  | ocs_status_code |
+      | ocs_api_version | ocs_status_code |
-      | 1               | /zzzfolder    | /zzzfolder (2) | 100             |
+      | 1               | 100             |
-      | 2               | /zzzfolder    | /zzzfolder (2) | 200             |
+      | 2               | 200             |
 
- @skipOnGraph
+  @skipOnGraph
   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 user "Carol" has been created with default attributes and without skeleton files
@@ -192,8 +188,8 @@ Feature: share resources where the sharee receives the share in multiple ways
       | 1               | 100             |
       | 2               | 200             |
 
-
+  @issue-2440
-  Scenario Outline: sharing parent folder to user with all permissions and its child folder to group with read permission then check create operation
+  Scenario: sharing parent folder to user with all permissions and its child folder to group with read permission then check create operation
     Given group "grp1" has been created
     And user "Carol" has been created with default attributes and without skeleton files
     And user "Carol" has created the following folders
@@ -214,20 +210,16 @@ Feature: share resources where the sharee receives the share in multiple ways
       | shareWith   | grp1           |
       | permissions | read           |
     When user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API
-    And user "Brian" accepts share "<path>" offered by user "Carol" using the sharing API
+    And user "Brian" accepts share "/child1" offered by user "Carol" using the sharing API
-    And user "Alice" accepts share "<path>" offered by user "Carol" using the sharing API
+    And user "Alice" accepts share "/child1" offered by user "Carol" using the sharing API
     Then the HTTP status code of responses on all endpoints should be "200"
     And the OCS status code of responses on all endpoints should be "100"
     And user "Brian" should be able to create folder "/Shares/parent/fo1"
     And user "Brian" should be able to create folder "/Shares/parent/child1/fo2"
     And user "Alice" should not be able to create folder "/Shares/child1/fo3"
-    @issue-2440
-    Examples:
-      | path    |
-      | /child1 |
 
-
+  @issue-2440
-  Scenario Outline: sharing parent folder to user with all permissions and its child folder to group with read permission then check rename operation
+  Scenario: sharing parent folder to user with all permissions and its child folder to group with read permission then check rename operation
     Given group "grp1" has been created
     And user "Carol" has been created with default attributes and without skeleton files
     And user "Carol" has created the following folders
@@ -249,20 +241,16 @@ Feature: share resources where the sharee receives the share in multiple ways
       | shareWith   | grp1           |
       | permissions | read           |
     When user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API
-    And user "Brian" accepts share "<path>" offered by user "Carol" using the sharing API
+    And user "Brian" accepts share "/child1" offered by user "Carol" using the sharing API
-    And user "Alice" accepts share "<path>" offered by user "Carol" using the sharing API
+    And user "Alice" accepts share "/child1" offered by user "Carol" using the sharing API
     Then the HTTP status code of responses on all endpoints should be "200"
     And the OCS status code of responses on all endpoints should be "100"
     And user "Brian" should be able to rename file "/Shares/parent/child1/child2/textfile-2.txt" to "/Shares/parent/child1/child2/rename.txt"
     And user "Brian" should not be able to rename file "/Shares/child1/child2/rename.txt" to "/Shares/child1/child2/rename2.txt"
     And user "Alice" should not be able to rename file "/Shares/child1/child2/rename.txt" to "/Shares/child1/child2/rename2.txt"
-    @issue-2440
-    Examples:
-      | path    |
-      | /child1 |
 
-
+  @issue-2440
-  Scenario Outline: sharing parent folder to user with all permissions and its child folder to group with read permission then check delete operation
+  Scenario: sharing parent folder to user with all permissions and its child folder to group with read permission then check delete operation
     Given group "grp1" has been created
     And user "Carol" has been created with default attributes and without skeleton files
     And user "Carol" has created the following folders
@@ -284,20 +272,16 @@ Feature: share resources where the sharee receives the share in multiple ways
       | shareWith   | grp1           |
       | permissions | read           |
     When user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API
-    And user "Brian" accepts share "<path>" offered by user "Carol" using the sharing API
+    And user "Brian" accepts share "/child1" offered by user "Carol" using the sharing API
-    And user "Alice" accepts share "<path>" offered by user "Carol" using the sharing API
+    And user "Alice" accepts share "/child1" offered by user "Carol" using the sharing API
     Then the HTTP status code of responses on all endpoints should be "200"
     And the OCS status code of responses on all endpoints should be "100"
     And user "Brian" should be able to delete file "/Shares/parent/child1/child2/textfile-2.txt"
     And user "Brian" should not be able to delete folder "/Shares/child1/child2"
     And user "Alice" should not be able to delete folder "/Shares/child1/child2"
-    @issue-2440
-    Examples:
-      | path    |
-      | /child1 |
 
 
-  Scenario Outline: sharing parent folder to user with all permissions and its child folder to group with read permission then check reshare operation
+  Scenario: sharing parent folder to user with all permissions and its child folder to group with read permission then check reshare operation
     Given group "grp1" has been created
     And user "Carol" has been created with default attributes and without skeleton files
     And user "Carol" has created the following folders
@@ -318,8 +302,8 @@ Feature: share resources where the sharee receives the share in multiple ways
       | shareWith   | grp1           |
       | permissions | read           |
     And user "Brian" has accepted share "/parent" offered by user "Carol"
-    And user "Brian" has accepted share "<path>" offered by user "Carol"
+    And user "Brian" has accepted share "/child1" offered by user "Carol"
-    And user "Alice" has accepted share "<path>" offered by user "Carol"
+    And user "Alice" has accepted share "/child1" offered by user "Carol"
     When user "Brian" creates a share using the sharing API with settings
       | path        | /Shares/parent |
       | shareType   | user           |
@@ -331,12 +315,9 @@ Feature: share resources where the sharee receives the share in multiple ways
     And as "Brian" folder "/Shares/child1" should exist
     And as "Alice" folder "/Shares/child1" should exist
     And as "Alice" folder "/Shares/parent" should exist
-    Examples:
-      | path    |
-      | /child1 |
 
 
-  Scenario Outline: sharing parent folder to group with read permission and its child folder to user with all permissions then check create operation
+  Scenario: sharing parent folder to group with read permission and its child folder to user with all permissions then check create operation
     Given group "grp1" has been created
     And user "Carol" has been created with default attributes and without skeleton files
     And user "Carol" has created the following folders
@@ -356,7 +337,7 @@ Feature: share resources where the sharee receives the share in multiple ways
       | shareType   | user           |
       | shareWith   | Brian          |
       | permissions | all            |
-    When user "Brian" accepts share "<path>" offered by user "Carol" using the sharing API
+    When user "Brian" accepts share "/child1" offered by user "Carol" using the sharing API
     And user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API
     And user "Alice" accepts share "/parent" offered by user "Carol" using the sharing API
     Then the HTTP status code of responses on all endpoints should be "200"
@@ -366,12 +347,9 @@ Feature: share resources where the sharee receives the share in multiple ways
     But user "Brian" should not be able to create folder "/Shares/parent/fo3"
     And user "Brian" should not be able to create folder "/Shares/parent/fo3"
     And user "Alice" should not be able to create folder "/Shares/parent/fo3"
-    Examples:
-      | path    |
-      | /child1 |
 
-
+  @issue-2440
-  Scenario Outline: sharing parent folder to group with read permission and its child folder to user with all permissions then check rename operation
+  Scenario: sharing parent folder to group with read permission and its child folder to user with all permissions then check rename operation
     Given group "grp1" has been created
     And user "Carol" has been created with default attributes and without skeleton files
     And user "Carol" has created the following folders
@@ -392,7 +370,7 @@ Feature: share resources where the sharee receives the share in multiple ways
       | shareType   | user           |
       | shareWith   | Brian          |
       | permissions | all            |
-    When user "Brian" accepts share "<path>" offered by user "Carol" using the sharing API
+    When user "Brian" accepts share "/child1" offered by user "Carol" using the sharing API
     And user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API
     And user "Alice" accepts share "/parent" offered by user "Carol" using the sharing API
     Then the HTTP status code of responses on all endpoints should be "200"
@@ -400,13 +378,9 @@ Feature: share resources where the sharee receives the share in multiple ways
     And user "Brian" should be able to rename file "/Shares/child1/child2/textfile-2.txt" to "/Shares/child1/child2/rename.txt"
     And user "Brian" should not be able to rename file "/Shares/parent/child1/child2/rename.txt" to "/Shares/parent/child1/child2/rename2.txt"
     And user "Alice" should not be able to rename file "/Shares/parent/child1/child2/rename.txt" to "/Shares/parent/child1/child2/rename2.txt"
-    @issue-2440
-    Examples:
-      | path    |
-      | /child1 |
 
-
+  @issue-2440
-  Scenario Outline: sharing parent folder to group with read permission and its child folder to user with all permissions then check delete operation
+  Scenario: sharing parent folder to group with read permission and its child folder to user with all permissions then check delete operation
     Given group "grp1" has been created
     And user "Carol" has been created with default attributes and without skeleton files
     And user "Carol" has created the following folders
@@ -427,7 +401,7 @@ Feature: share resources where the sharee receives the share in multiple ways
       | shareType   | user           |
       | shareWith   | Brian          |
       | permissions | all            |
-    When user "Brian" accepts share "<path>" offered by user "Carol" using the sharing API
+    When user "Brian" accepts share "/child1" offered by user "Carol" using the sharing API
     And user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API
     And user "Alice" accepts share "/parent" offered by user "Carol" using the sharing API
     Then the HTTP status code of responses on all endpoints should be "200"
@@ -435,13 +409,9 @@ Feature: share resources where the sharee receives the share in multiple ways
     And user "Brian" should be able to delete file "/Shares/child1/child2/textfile-2.txt"
     And user "Brian" should not be able to delete folder "/Shares/parent/child1"
     And user "Alice" should not be able to delete folder "/Shares/parent/child1"
-    @issue-2440
-    Examples:
-      | path    |
-      | /child1 |
 
 
-  Scenario Outline: sharing parent folder to group with read permission and its child folder to user with all permissions then check reshare operation
+  Scenario: sharing parent folder to group with read permission and its child folder to user with all permissions then check reshare operation
     Given group "grp1" has been created
     And user "Carol" has been created with default attributes and without skeleton files
     And user "Carol" has created the following folders
@@ -461,22 +431,19 @@ Feature: share resources where the sharee receives the share in multiple ways
       | shareType   | user           |
       | shareWith   | Brian          |
       | permissions | all            |
-    When user "Brian" accepts share "<path>" offered by user "Carol" using the sharing API
+    When user "Brian" accepts share "/child1" offered by user "Carol" using the sharing API
     And user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API
     And user "Alice" accepts share "/parent" offered by user "Carol" using the sharing API
     Then the HTTP status code of responses on all endpoints should be "200"
     And the OCS status code of responses on all endpoints should be "100"
     And user "Brian" should be able to share folder "/Shares/child1" with user "Alice" with permissions "read" using the sharing API
-    And user "Alice" should be able to accept pending share "<path>" offered by user "Brian"
+    And user "Alice" should be able to accept pending share "/child1" offered by user "Brian"
     And as "Brian" folder "/Shares/parent" should exist
     And as "Alice" folder "/Shares/parent" should exist
     And as "Alice" folder "/Shares/child1" should exist
-    Examples:
-      | path    |
-      | /child1 |
 
 
-  Scenario Outline: sharing parent folder to one group with all permissions and its child folder to another group with read permission
+  Scenario: sharing parent folder to one group with all permissions and its child folder to another group with read permission
     Given these groups have been created:
       | groupname |
       | grp1      |
@@ -502,7 +469,7 @@ Feature: share resources where the sharee receives the share in multiple ways
       | shareWith   | grp2           |
       | permissions | read           |
     When user "Alice" accepts share "/parent" offered by user "Carol" using the sharing API
-    And user "Brian" accepts share "<path>" offered by user "Carol" using the sharing API
+    And user "Brian" accepts share "/child1" offered by user "Carol" using the sharing API
     Then the HTTP status code of responses on all endpoints should be "200"
     And the OCS status code of responses on all endpoints should be "100"
     And user "Alice" should be able to create folder "/Shares/parent/child1/fo1"
@@ -516,9 +483,6 @@ Feature: share resources where the sharee receives the share in multiple ways
     And user "Brian" should not be able to create folder "/Shares/child1/child2/fo2"
     And user "Brian" should not be able to rename file "/Shares/child1/child2/rename.txt" to "/Shares/child1/child2/rename2.txt"
     And user "Brian" should not be able to share folder "/Shares/child1" with group "grp3" with permissions "read" using the sharing API
-    Examples:
-      | path    |
-      | /child1 |
 
 
   Scenario Outline: share receiver renames the received group share and shares same folder through user share again

tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWithDisabledUser.feature

@@ -9,16 +9,13 @@ Feature: share resources with a disabled user
     And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
 
   @issue-2212
-  Scenario Outline: creating a new share with a disabled user
+  Scenario: creating a new share with a disabled user
-    Given using OCS API version "<ocs_api_version>"
+    Given using OCS API version "1"
     And user "Brian" has been created with default attributes and without skeleton files
     And user "Alice" has been disabled
     When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API
-    Then the OCS status code should be "<ocs_status_code>"
+    Then the OCS status code should be "997"
     And the HTTP status code should be "401"
-    Examples:
-      | ocs_api_version | ocs_status_code |
-      | 1               | 997             |
 
 
   Scenario: creating a new share with a disabled user

tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature

@@ -467,7 +467,7 @@ Feature: sharing
       | 1               | 100             |
       | 2               | 200             |
 
- @skipOnGraph
+  @skipOnGraph
   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:
@@ -492,8 +492,8 @@ Feature: sharing
       | 1               | 100             |
       | 2               | 200             |
 
-
   # deleting an LDAP group is not relevant or possible using the provisioning API
+  @issue-2441
   Scenario Outline: shares shared to deleted group should not be available
     Given using OCS API version "<ocs_api_version>"
     And these users have been created with default attributes and without skeleton files:
@@ -510,7 +510,7 @@ Feature: sharing
     And the HTTP status code should be "200"
     And the fields of the last response to user "Alice" sharing with group "grp1" should include
       | share_with  | grp1           |
-      | file_target | <path>         |
+      | file_target | /textfile0.txt |
       | path        | /textfile0.txt |
       | uid_owner   | %username%     |
     When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API
@@ -524,11 +524,10 @@ Feature: sharing
     And file "/textfile0.txt" should not be included as path in the response
     And as "Brian" file "/Shares/textfile0.txt" should not exist
     And as "Carol" file "/Shares/textfile0.txt" should not exist
-    @issue-2441
     Examples:
-      | ocs_api_version | ocs_status_code | path           |
+      | ocs_api_version | ocs_status_code |
-      | 1               | 100             | /textfile0.txt |
+      | 1               | 100             |
-      | 2               | 200             | /textfile0.txt |
+      | 2               | 200             |
 
   @issue-2146
   Scenario: share a file by multiple channels and download from sub-folder and direct file share
@@ -560,7 +559,7 @@ Feature: sharing
     And the content of file "/common/sub/textfile0.txt" for user "Alice" should be "BLABLABLA" plus end-of-line
 
   @issue-enterprise-3896 @issue-2201
-  Scenario Outline: sharing back to resharer is allowed
+  Scenario: sharing back to resharer is allowed
     Given these users have been created with default attributes and without skeleton files:
       | username |
       | Brian    |
@@ -570,18 +569,15 @@ Feature: sharing
     And user "Brian" has accepted share "/userZeroFolder" offered by user "Alice"
     And user "Brian" has created folder "/Shares/userZeroFolder/userOneFolder"
     And user "Brian" has shared folder "/Shares/userZeroFolder/userOneFolder" with user "Carol" with permissions "read, share"
-    And user "Carol" has accepted share "<pending_share_path>" offered by user "Brian"
+    And user "Carol" has accepted share "/userOneFolder" offered by user "Brian"
     When user "Carol" shares folder "/Shares/userOneFolder" with user "Brian" using the sharing API
     Then the HTTP status code should be "200"
 #    Then the HTTP status code should be "405"
     And the sharing API should report to user "Brian" that no shares are in the pending state
     And as "Brian" folder "/Shares/userOneFolder" should not exist
-    Examples:
-      | pending_share_path |
-      | /userOneFolder     |
 
   @issue-enterprise-3896 @issue-2201
-  Scenario Outline: sharing back to original sharer is allowed
+  Scenario: sharing back to original sharer is allowed
     Given these users have been created with default attributes and without skeleton files:
       | username |
       | Brian    |
@@ -591,18 +587,15 @@ Feature: sharing
     And user "Brian" has accepted share "/userZeroFolder" offered by user "Alice"
     And user "Brian" has created folder "/Shares/userZeroFolder/userOneFolder"
     And user "Brian" has shared folder "/Shares/userZeroFolder/userOneFolder" with user "Carol" with permissions "read, share"
-    And user "Carol" has accepted share "<pending_share_path>" offered by user "Brian"
+    And user "Carol" has accepted share "/userOneFolder" offered by user "Brian"
     When user "Carol" shares folder "/Shares/userOneFolder" with user "Alice" using the sharing API
     Then the HTTP status code should be "200"
 #    Then the HTTP status code should be "405"
     And the sharing API should report to user "Alice" that no shares are in the pending state
     And as "Alice" folder "/Shares/userOneFolder" should not exist
-    Examples:
-      | pending_share_path |
-      | /userOneFolder     |
 
   @issue-enterprise-3896 @issue-2201
-  Scenario Outline: sharing a subfolder to a user that already received parent folder share
+  Scenario: sharing a subfolder to a user that already received parent folder share
     Given these users have been created with default attributes and without skeleton files:
       | username |
       | Brian    |
@@ -615,15 +608,12 @@ Feature: sharing
     And user "Carol" has accepted share "/userZeroFolder" offered by user "Alice"
     And user "Brian" has created folder "/Shares/userZeroFolder/userOneFolder"
     And user "Brian" has shared folder "/Shares/userZeroFolder/userOneFolder" with user "David" with permissions "read, share"
-    And user "David" has accepted share "<pending_share_path>" offered by user "Brian"
+    And user "David" has accepted share "/userOneFolder" offered by user "Brian"
     When user "David" shares folder "/Shares/userOneFolder" with user "Carol" using the sharing API
     Then the HTTP status code should be "200"
 #    Then the HTTP status code should be "405"
     And the sharing API should report to user "Carol" that no shares are in the pending state
     And as "Carol" folder "/Shares/userOneFolder" should not exist
-    Examples:
-      | pending_share_path |
-      | /userOneFolder     |
 
   @smokeTest
   Scenario Outline: creating a share of a renamed file

tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature

@@ -46,19 +46,16 @@ Feature: sharing
       | 2               | 200             |
 
 
-  Scenario Outline: orphaned shares
+  Scenario: orphaned shares
     Given using OCS API version "1"
     And user "Alice" has created folder "/common"
     And user "Alice" has created folder "/common/sub"
     And user "Alice" has shared folder "/common/sub" with user "Brian"
-    And user "Brian" has accepted share "<pending_share_path>" offered by user "Alice"
+    And user "Brian" has accepted share "/sub" offered by user "Alice"
     When user "Alice" deletes folder "/common" using the WebDAV API
     Then the HTTP status code should be "204"
     And as "Brian" folder "/Shares/sub" should not exist
     And as "Brian" folder "/sub" should not exist
-    Examples:
-      | pending_share_path |
-      | /sub               |
 
   @smokeTest
   Scenario: deleting a file out of a share as recipient creates a backup for the owner
@@ -92,7 +89,7 @@ Feature: sharing
     And as "Brian" file "/sub/shared_file.txt" should exist in the trashbin
 
   @smokeTest
-  Scenario Outline: unshare from self
+  Scenario: unshare from self
     And group "grp1" has been created
     And these users have been created with default attributes and without skeleton files:
       | username |
@@ -102,7 +99,7 @@ Feature: sharing
     And user "Carol" has created folder "PARENT"
     And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt"
     And user "Carol" has shared file "/PARENT/parent.txt" with group "grp1"
-    And user "Brian" has accepted share "<pending_share_path>" offered by user "Carol"
+    And user "Brian" has accepted share "/parent.txt" offered by user "Carol"
     And user "Carol" has stored etag of element "/PARENT"
     And user "Brian" has stored etag of element "/"
     And user "Brian" has stored etag of element "/Shares"
@@ -111,9 +108,6 @@ Feature: sharing
     And the etag of element "/" of user "Brian" should have changed
     And the etag of element "/Shares" of user "Brian" should have changed
     And the etag of element "/PARENT" of user "Carol" should not have changed
-    Examples:
-      | pending_share_path |
-      | /parent.txt        |
 
 
   Scenario: sharee of a read-only share folder tries to delete the shared folder
@@ -220,12 +214,12 @@ Feature: sharing
     And user "Alice" has shared file "textfile0.txt" with user "Brian"
     And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
     When user "Brian" tries to delete the last share of user "Alice" using the sharing API
-    Then the OCS status code should be "<ocs_status_code>"
+    Then the OCS status code should be "404"
     And the HTTP status code should be "<http_status_code>"
     Examples:
-      | ocs_api_version | ocs_status_code | http_status_code |
+      | ocs_api_version | http_status_code |
-      | 1               | 404             | 200              |
+      | 1               | 200              |
-      | 2               | 404             | 404              |
+      | 2               | 404              |
 
 
   Scenario Outline: unshare a shared resources
@@ -234,9 +228,9 @@ Feature: sharing
     And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
     When user "Alice" unshares file "textfile0.txt" shared to "Brian"
     Then the OCS status code should be "<ocs_status_code>"
-    And the HTTP status code should be "<http_status_code>"
+    And the HTTP status code should be "200"
     And as "Brian" file "/Shares/textfile0.txt" should not exist
     Examples:
-      | ocs_api_version | ocs_status_code | http_status_code |
+      | ocs_api_version | ocs_status_code |
-      | 1               | 100             | 200              |
+      | 1               | 100             |
-      | 2               | 200             | 200              |
+      | 2               | 200             |

tests/acceptance/features/coreApiShareOperationsToShares1/gettingShares.feature

@@ -179,12 +179,12 @@ Feature: sharing
     And user "Alice" has created folder "/PARENT"
     And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt"
     And user "Alice" has shared file "PARENT/parent.txt" with user "Brian"
-    And user "Brian" has accepted share "<pending_share_path>" offered by user "Alice"
+    And user "Brian" has accepted share "/parent.txt" offered by user "Alice"
     When user "Alice" gets all the shares inside the folder "PARENT" using the sharing API
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
     And file "/Shares/parent.txt" should be included in the response
     Examples:
-      | ocs_api_version | ocs_status_code | pending_share_path |
+      | ocs_api_version | ocs_status_code |
-      | 1               | 100             | /parent.txt        |
+      | 1               | 100             |
-      | 2               | 200             | /parent.txt        |
+      | 2               | 200             |

tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShare.feature

@@ -273,12 +273,12 @@ Feature: create a public link share
     Given using OCS API version "<ocs_api_version>"
     When user "Alice" creates a public link share using the sharing API with settings
       | path | / |
-    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 |
+      | ocs_api_version | http_status_code |
-      | 1               | 400             | 200              |
+      | 1               | 200              |
-      | 2               | 400             | 400              |
+      | 2               | 400              |
 
 
   Scenario Outline: user creates a public link share of a file with file name longer than 64 chars using the public WebDAV API

tests/acceptance/features/coreApiSharePublicLink3/updatePublicLinkShare.feature

@@ -330,7 +330,7 @@ Feature: update a public link share
       | 1               | 100             |
       | 2               | 200             |
 
-
+  @issue-1269
   Scenario Outline: updating share permissions from change to read restricts public from deleting files using the public API
     Given using OCS API version "<ocs_api_version>"
     And user "Alice" has created folder "PARENT"
@@ -345,8 +345,6 @@ Feature: update a public link share
     And the public deletes file "CHILD/child.txt" from the last public link share using the new public WebDAV API
     And the HTTP status code of responses on all endpoints should be "403"
     And as "Alice" file "PARENT/CHILD/child.txt" should exist
-
-    @issue-1269
     Examples:
       | ocs_api_version |
       | 1               |

tests/acceptance/features/coreApiShareReshareToShares1/reShare.feature

@@ -113,7 +113,7 @@ Feature: sharing
   Scenario Outline: user is not allowed to reshare file and set more permissions bits
     Given using OCS API version "<ocs_api_version>"
     And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
-    And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions <received_permissions>
+    And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions 17
     And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
     When user "Brian" shares file "/Shares/textfile0.txt" with user "Carol" with permissions <reshare_permissions> using the sharing API
     Then the OCS status code should be "404"
@@ -122,21 +122,21 @@ Feature: sharing
     And the sharing API should report to user "Carol" that no shares are in the pending state
     But as "Brian" file "/Shares/textfile0.txt" should exist
     Examples:
-      | ocs_api_version | http_status_code | received_permissions | reshare_permissions |
+      | ocs_api_version | http_status_code | reshare_permissions |
       # passing on more bits including reshare
-      | 1               | 200              | 17                   | 19                  |
+      | 1               | 200              | 19                  |
-      | 2               | 404              | 17                   | 19                  |
+      | 2               | 404              | 19                  |
-      | 1               | 200              | 17                   | 23                  |
+      | 1               | 200              | 23                  |
-      | 2               | 404              | 17                   | 23                  |
+      | 2               | 404              | 23                  |
-      | 1               | 200              | 17                   | 31                  |
+      | 1               | 200              | 31                  |
-      | 2               | 404              | 17                   | 31                  |
+      | 2               | 404              | 31                  |
       # passing on more bits but not reshare
-      | 1               | 200              | 17                   | 3                   |
+      | 1               | 200              | 3                   |
-      | 2               | 404              | 17                   | 3                   |
+      | 2               | 404              | 3                   |
-      | 1               | 200              | 17                   | 7                   |
+      | 1               | 200              | 7                   |
-      | 2               | 404              | 17                   | 7                   |
+      | 2               | 404              | 7                   |
-      | 1               | 200              | 17                   | 15                  |
+      | 1               | 200              | 15                  |
-      | 2               | 404              | 17                   | 15                  |
+      | 2               | 404              | 15                  |
 
 
   Scenario Outline: user is allowed to reshare file and set create (4) or delete (8) permissions bits, which get ignored

tests/acceptance/features/coreApiShareReshareToShares2/reShareSubfolder.feature

@@ -21,13 +21,13 @@ Feature: a subfolder of a received share can be reshared
     When user "Brian" shares folder "/Shares/TMP/SUB" with user "Carol" with permissions "share,read" using the sharing API
     Then the OCS status code should be "<ocs_status_code>"
     And the HTTP status code should be "200"
-    And user "Carol" should be able to accept pending share "<pending_sub_share_path>" offered by user "Brian"
+    And user "Carol" should be able to accept pending share "/SUB" offered by user "Brian"
     And as "Carol" folder "/Shares/SUB" should exist
     And as "Brian" folder "/Shares/TMP/SUB" should exist
     Examples:
-      | ocs_api_version | ocs_status_code | pending_sub_share_path |
+      | ocs_api_version | ocs_status_code |
-      | 1               | 100             | /SUB                   |
+      | 1               | 100             |
-      | 2               | 200             | /SUB                   |
+      | 2               | 200             |
 
 
   Scenario Outline: user is not allowed to reshare a sub-folder with more permissions
@@ -89,7 +89,7 @@ Feature: a subfolder of a received share can be reshared
     And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
     And user "Brian" has accepted share "/TMP" offered by user "Alice"
     And user "Brian" has shared folder "/Shares/TMP/SUB" with user "Carol" with permissions "share,create,update,read"
-    And user "Carol" has accepted share "<pending_sub_share_path>" offered by user "Brian"
+    And user "Carol" has accepted share "/SUB" offered by user "Brian"
     When user "Brian" updates the last share using the sharing API with
       | permissions | share,read |
     Then the OCS status code should be "<ocs_status_code>"
@@ -99,9 +99,9 @@ Feature: a subfolder of a received share can be reshared
     And as "Brian" folder "/Shares/TMP/SUB" should exist
     And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "/Shares/TMP/SUB/textfile.txt"
     Examples:
-      | ocs_api_version | ocs_status_code | pending_sub_share_path |
+      | ocs_api_version | ocs_status_code |
-      | 1               | 100             | /SUB                   |
+      | 1               | 100             |
-      | 2               | 200             | /SUB                   |
+      | 2               | 200             |
 
   @issue-2214
   Scenario Outline: user is allowed to update reshare of a sub-folder to the maximum allowed permissions
@@ -109,7 +109,7 @@ Feature: a subfolder of a received share can be reshared
     And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
     And user "Brian" has accepted share "/TMP" offered by user "Alice"
     And user "Brian" has shared folder "/Shares/TMP/SUB" with user "Carol" with permissions "share,read"
-    And user "Carol" has accepted share "<pending_sub_share_path>" offered by user "Brian"
+    And user "Carol" has accepted share "/SUB" offered by user "Brian"
     When user "Brian" updates the last share using the sharing API with
       | permissions | share,create,update,read |
     Then the OCS status code should be "<ocs_status_code>"
@@ -119,9 +119,9 @@ Feature: a subfolder of a received share can be reshared
     And as "Brian" folder "/Shares/TMP/SUB" should exist
     And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "/Shares/TMP/SUB/textfile.txt"
     Examples:
-      | ocs_api_version | ocs_status_code | pending_sub_share_path |
+      | ocs_api_version | ocs_status_code |
-      | 1               | 100             | /SUB                   |
+      | 1               | 100             |
-      | 2               | 200             | /SUB                   |
+      | 2               | 200             |
 
   @issue-2214
   Scenario Outline: user is not allowed to update reshare of a sub-folder with more permissions
@@ -129,7 +129,7 @@ Feature: a subfolder of a received share can be reshared
     And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,read"
     And user "Brian" has accepted share "/TMP" offered by user "Alice"
     And user "Brian" has shared folder "/Shares/TMP/SUB" with user "Carol" with permissions "share,read"
-    And user "Carol" has accepted share "<pending_sub_share_path>" offered by user "Brian"
+    And user "Carol" has accepted share "/SUB" offered by user "Brian"
     When user "Brian" updates the last share using the sharing API with
       | permissions | all |
     Then the OCS status code should be "404"
@@ -139,6 +139,6 @@ Feature: a subfolder of a received share can be reshared
     And as "Brian" folder "/Shares/TMP/SUB" should exist
     But user "Brian" should not be able to upload file "filesForUpload/textfile.txt" to "/Shares/TMP/SUB/textfile.txt"
     Examples:
-      | ocs_api_version | http_status_code | pending_sub_share_path |
+      | ocs_api_version | http_status_code |
-      | 1               | 200              | /SUB                   |
+      | 1               | 200              |
-      | 2               | 404              | /SUB                   |
+      | 2               | 404              |

tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature

@@ -126,7 +126,7 @@ Feature: sharing
       | 2               | 400              | create,delete |
 
   @issue-2201
-  Scenario Outline: share ownership change after moving a shared file outside of an outer share
+  Scenario: share ownership change after moving a shared file outside of an outer share
     Given these users have been created with default attributes and without skeleton files:
       | username |
       | Brian    |
@@ -137,7 +137,7 @@ Feature: sharing
     And user "Alice" has shared folder "/folder1" with user "Brian" with permissions "all"
     And user "Brian" has accepted share "/folder1" offered by user "Alice"
     And user "Brian" has shared folder "/Shares/folder1/folder2" with user "Carol" with permissions "all"
-    And user "Carol" has accepted share "<folder2_share_path>" offered by user "Brian"
+    And user "Carol" has accepted share "/folder2" offered by user "Brian"
     When user "Brian" moves folder "/Shares/folder1/folder2" to "/moved-out/folder2" using the WebDAV API
     Then the HTTP status code should be "201"
     And the response when user "Brian" gets the info of the last share should include
@@ -156,12 +156,9 @@ Feature: sharing
       | mimetype          | httpd/unix-directory |
     And as "Alice" folder "/Shares/folder1/folder2" should not exist
     And as "Carol" folder "/Shares/folder2" should exist
-    Examples:
-      | folder2_share_path |
-      | /folder2           |
 
-
+  @issue-2442
-  Scenario Outline: share ownership change after moving a shared file to another share
+  Scenario: share ownership change after moving a shared file to another share
     Given these users have been created with default attributes and without skeleton files:
       | username |
       | Brian    |
@@ -181,7 +178,7 @@ Feature: sharing
       | item_source       | A_STRING             |
       | share_type        | user                 |
       | file_source       | A_STRING             |
-      | file_target       | <path>               |
+      | file_target       | /Carol-folder        |
       | permissions       | all                  |
       | stime             | A_NUMBER             |
       | storage           | A_STRING             |
@@ -191,10 +188,6 @@ Feature: sharing
       | mimetype          | httpd/unix-directory |
     And as "Alice" folder "/Alice-folder/folder2" should not exist
     And as "Carol" folder "/Carol-folder/folder2" should exist
-    @issue-2442
-    Examples:
-      | path          |
-      | /Carol-folder |
 
   @issue-1253 @issue-1224 @issue-1225
   #after fixing all the issues merge this scenario with the one below

tests/acceptance/features/coreApiSharees/sharees.feature

@@ -20,7 +20,7 @@ Feature: search sharees
       | search   | sharee |
       | itemType | file   |
     Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "<http-status>"
+    And the HTTP status code should be "200"
     And the "exact users" sharees returned should be empty
     And the "users" sharees returned should be
       | Sharee One | 0 | sharee1 |
@@ -31,9 +31,9 @@ Feature: search sharees
     And the "exact remotes" sharees returned should be empty
     And the "remotes" sharees returned should be empty
     Examples:
-      | ocs-api-version | ocs-status | http-status |
+      | ocs-api-version | ocs-status |
-      | 1               | 100        | 200         |
+      | 1               | 100        |
-      | 2               | 200        | 200         |
+      | 2               | 200        |
 
 
   Scenario Outline: search without exact match not-exact casing
@@ -42,7 +42,7 @@ Feature: search sharees
       | search   | sHaRee |
       | itemType | file   |
     Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "<http-status>"
+    And the HTTP status code should be "200"
     And the "exact users" sharees returned should be empty
     And the "users" sharees returned should be
       | Sharee One | 0 | sharee1 |
@@ -53,9 +53,9 @@ Feature: search sharees
     And the "exact remotes" sharees returned should be empty
     And the "remotes" sharees returned should be empty
     Examples:
-      | ocs-api-version | ocs-status | http-status |
+      | ocs-api-version | ocs-status |
-      | 1               | 100        | 200         |
+      | 1               | 100        |
-      | 2               | 200        | 200         |
+      | 2               | 200        |
 
 
   Scenario Outline: search only with group members - allowed
@@ -87,7 +87,7 @@ Feature: search sharees
       | search   | Sharee1 |
       | itemType | file    |
     Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "<http-status>"
+    And the HTTP status code should be "200"
     And the "exact users" sharees returned should be
       | Sharee One | 0 | sharee1 |
     And the "users" sharees returned should be empty
@@ -96,9 +96,9 @@ Feature: search sharees
     And the "exact remotes" sharees returned should be empty
     And the "remotes" sharees returned should be empty
     Examples:
-      | ocs-api-version | ocs-status | http-status |
+      | ocs-api-version | ocs-status |
-      | 1               | 100        | 200         |
+      | 1               | 100        |
-      | 2               | 200        | 200         |
+      | 2               | 200        |
 
 
   Scenario Outline: search with exact match not-exact casing
@@ -107,7 +107,7 @@ Feature: search sharees
       | search   | sharee1 |
       | itemType | file    |
     Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "<http-status>"
+    And the HTTP status code should be "200"
     And the "exact users" sharees returned should be
       | Sharee One | 0 | sharee1 |
     And the "users" sharees returned should be empty
@@ -116,9 +116,9 @@ Feature: search sharees
     And the "exact remotes" sharees returned should be empty
     And the "remotes" sharees returned should be empty
     Examples:
-      | ocs-api-version | ocs-status | http-status |
+      | ocs-api-version | ocs-status |
-      | 1               | 100        | 200         |
+      | 1               | 100        |
-      | 2               | 200        | 200         |
+      | 2               | 200        |
 
 
   Scenario Outline: search with exact match not-exact casing group
@@ -127,7 +127,7 @@ Feature: search sharees
       | search   | shareegroup2 |
       | itemType | file         |
     Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "<http-status>"
+    And the HTTP status code should be "200"
     And the "exact users" sharees returned should be empty
     And the "users" sharees returned should be empty
     And the "exact groups" sharees returned should be
@@ -136,9 +136,9 @@ Feature: search sharees
     And the "exact remotes" sharees returned should be empty
     And the "remotes" sharees returned should be empty
     Examples:
-      | ocs-api-version | ocs-status | http-status |
+      | ocs-api-version | ocs-status |
-      | 1               | 100        | 200         |
+      | 1               | 100        |
-      | 2               | 200        | 200         |
+      | 2               | 200        |
 
 
   Scenario Outline: search with "self"
@@ -147,7 +147,7 @@ Feature: search sharees
       | search   | Sharee1 |
       | itemType | file    |
     Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "<http-status>"
+    And the HTTP status code should be "200"
     And the "exact users" sharees returned should be
       | Sharee One | 0 | sharee1 |
     And the "users" sharees returned should be empty
@@ -156,9 +156,9 @@ Feature: search sharees
     And the "exact remotes" sharees returned should be empty
     And the "remotes" sharees returned should be empty
     Examples:
-      | ocs-api-version | ocs-status | http-status |
+      | ocs-api-version | ocs-status |
-      | 1               | 100        | 200         |
+      | 1               | 100        |
-      | 2               | 200        | 200         |
+      | 2               | 200        |
 
 
   Scenario Outline: enumerate only group members - only show partial results from member of groups
@@ -171,7 +171,7 @@ Feature: search sharees
       | search   | anot |
       | itemType | file |
     Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "<http-status>"
+    And the HTTP status code should be "200"
     And the "exact users" sharees returned should be empty
     And the "users" sharees returned should be
       | Another | 0 | another |
@@ -180,9 +180,9 @@ Feature: search sharees
     And the "exact remotes" sharees returned should be empty
     And the "remotes" sharees returned should be empty
     Examples:
-      | ocs-api-version | ocs-status | http-status |
+      | ocs-api-version | ocs-status |
-      | 1               | 100        | 200         |
+      | 1               | 100        |
-      | 2               | 200        | 200         |
+      | 2               | 200        |
 
 
   Scenario Outline: search without exact match such that the search string matches the user getting the sharees
@@ -192,7 +192,7 @@ Feature: search sharees
       | search   | sharee |
       | itemType | file   |
     Then the OCS status code should be "<ocs-status>"
-    And the HTTP status code should be "<http-status>"
+    And the HTTP status code should be "200"
     And the "exact users" sharees returned should be empty
     And the "users" sharees returned should be
       | Sharee One | 0 | sharee1 |
@@ -204,6 +204,6 @@ Feature: search sharees
     And the "exact remotes" sharees returned should be empty
     And the "remotes" sharees returned should be empty
     Examples:
-      | ocs-api-version | ocs-status | http-status |
+      | ocs-api-version | ocs-status |
-      | 1               | 100        | 200         |
+      | 1               | 100        |
-      | 2               | 200        | 200         |
+      | 2               | 200        |

tests/acceptance/features/coreApiTrashbin/trashbinDelete.feature

@@ -93,16 +93,16 @@ Feature: files and folders can be deleted from the trashbin
     And user "Alice" has deleted file "/PARENT/parent.txt"
     And user "Alice" has deleted file "/PARENT/CHILD/child.txt"
     When user "Brian" tries to delete the file with original path "textfile1.txt" from the trashbin of user "Alice" using the trashbin API
-    Then the HTTP status code should be "<status-code>"
+    Then the HTTP status code should be "404"
     And as "Alice" the file with original path "/textfile1.txt" should exist in the trashbin
     And as "Alice" the file with original path "/textfile0.txt" should exist in the trashbin
     And as "Alice" the file with original path "/PARENT/parent.txt" should exist in the trashbin
     And as "Alice" the file with original path "/PARENT/CHILD/child.txt" should exist in the trashbin
     @skipOnRevaMaster
     Examples:
-      | dav-path | status-code |
+      | dav-path |
-      | new      | 404         |
+      | new      |
-      | spaces   | 404         |
+      | spaces   |
 
 
   Scenario Outline: user tries to delete trashbin file using invalid password

tests/acceptance/features/coreApiTrashbin/trashbinFilesFolders.feature

@@ -166,15 +166,15 @@ Feature: files and folders exist in the trashbin after being deleted
     And user "Brian" has been created with default attributes and without skeleton files
     And user "testtrashbin100" has deleted file "/textfile1.txt"
     When user "Brian" tries to list the trashbin content for user "testtrashbin100"
-    Then the HTTP status code should be "<status-code>"
+    Then the HTTP status code should be "404"
     And the last webdav response should not contain the following elements
       | path          | user            |
       | textfile1.txt | testtrashbin100 |
     @skipOnRevaMaster
     Examples:
-      | dav-path | status-code |
+      | dav-path |
-      | new      | 404         |
+      | new      |
-      | spaces   | 404         |
+      | spaces   |
 
   @issue-3561 @smokeTest
   Scenario Outline: listing other user's trashbin is prohibited with multiple files on trashbin
@@ -186,16 +186,16 @@ Feature: files and folders exist in the trashbin after being deleted
     And user "testtrashbin101" has deleted file "/textfile0.txt"
     And user "testtrashbin101" has deleted file "/textfile2.txt"
     When user "Brian" tries to list the trashbin content for user "testtrashbin101"
-    Then the HTTP status code should be "<status-code>"
+    Then the HTTP status code should be "404"
     And the last webdav response should not contain the following elements
       | path          | user            |
       | textfile0.txt | testtrashbin101 |
       | textfile2.txt | testtrashbin101 |
     @skipOnRevaMaster
     Examples:
-      | dav-path | status-code |
+      | dav-path |
-      | new      | 404         |
+      | new      |
-      | spaces   | 404         |
+      | spaces   |
 
   @issue-3561  @provisioning_api-app-required
   Scenario Outline: listing other user's trashbin is prohibited for newly recreated user with same name
@@ -211,7 +211,7 @@ Feature: files and folders exist in the trashbin after being deleted
     And user "testtrashbin102" has uploaded file "filesForUpload/textfile.txt" to "/textfile3.txt"
     And user "testtrashbin102" has deleted file "/textfile3.txt"
     When user "Brian" tries to list the trashbin content for user "testtrashbin102"
-    Then the HTTP status code should be "<status-code>"
+    Then the HTTP status code should be "404"
     And the last webdav response should not contain the following elements
       | path          | user            |
       | textfile0.txt | testtrashbin102 |
@@ -219,9 +219,9 @@ Feature: files and folders exist in the trashbin after being deleted
       | textfile3.txt | testtrashbin102 |
     @skipOnRevaMaster
     Examples:
-      | dav-path | status-code |
+      | dav-path |
-      | new      | 404         |
+      | new      |
-      | spaces   | 404         |
+      | spaces   |
 
   @issue-3561
   Scenario Outline: listing other user's empty unused trashbin is prohibited

tests/acceptance/features/coreApiTrashbinRestore/trashbinRestore.feature

@@ -136,14 +136,14 @@ Feature: restore deleted files/folders
     And user "Brian" has been created with default attributes and without skeleton files
     And user "Alice" has deleted file "/textfile0.txt"
     When user "Brian" tries to restore the file with original path "/textfile0.txt" from the trashbin of user "Alice" using the trashbin API
-    Then the HTTP status code should be "<status-code>"
+    Then the HTTP status code should be "404"
     And as "Alice" the folder with original path "/textfile0.txt" should exist in the trashbin
     And user "Alice" should not see the following elements
       | /textfile0.txt |
     Examples:
-      | dav-path | status-code |
+      | dav-path |
-      | old      | 404         |
+      | old      |
-      | new      | 404         |
+      | new      |
 
   @smokeTest
   Scenario Outline: deleted file cannot be restored with invalid password

tests/acceptance/features/coreApiVersions/fileVersions.feature

@@ -69,20 +69,17 @@ Feature: dav-versions
     And the content of file "/davtest.txt" for user "Alice" should be "Back To The Future."
 
   @smokeTest @skipOnStorage:ceph
-  Scenario Outline: uploading a chunked file does create the correct version that can be restored
+  Scenario: uploading a chunked file does create the correct version that can be restored
-    Given using <dav-path> DAV path
+    Given using old DAV path
     And user "Alice" has uploaded file with content "textfile0" to "textfile0.txt"
     When user "Alice" uploads file "filesForUpload/davtest.txt" to "/textfile0.txt" in 2 chunks using the WebDAV API
     And user "Alice" uploads file "filesForUpload/lorem.txt" to "/textfile0.txt" in 3 chunks using the WebDAV API
 #    HTTP status code is different for old (201) and new (204) WebDav API when uploading in chunks
-    Then the HTTP status code of responses on all endpoints should be "<status-code>"
+    Then the HTTP status code of responses on all endpoints should be "201"
     And the version folder of file "/textfile0.txt" for user "Alice" should contain "2" elements
     When user "Alice" restores version index "1" of file "/textfile0.txt" using the WebDAV API
     Then the HTTP status code should be "204"
     And the content of file "/textfile0.txt" for user "Alice" should be "Dav-Test"
-    Examples:
-      | dav-path | status-code |
-      | old      | 201         |
 
   @skipOnStorage:ceph @skipOnStorage:scality
   Scenario: restore a file and check the content and checksum
@@ -381,19 +378,19 @@ Feature: dav-versions
       | permissions | change    |
       | shareWith   | Alice     |
     And user "Alice" has accepted share "/testshare" offered by user "Brian"
-    And user "<mover>" has uploaded file with content "test data 1" to "/testfile.txt"
+    And user "Brian" has uploaded file with content "test data 1" to "/testfile.txt"
-    And user "<mover>" has uploaded file with content "test data 2" to "/testfile.txt"
+    And user "Brian" has uploaded file with content "test data 2" to "/testfile.txt"
-    And user "<mover>" has uploaded file with content "test data 3" to "/testfile.txt"
+    And user "Brian" has uploaded file with content "test data 3" to "/testfile.txt"
-    When user "<mover>" moves file "/testfile.txt" to "<dst-folder>/testfile.txt" using the WebDAV API
+    When user "Brian" moves file "/testfile.txt" to "/testshare/testfile.txt" using the WebDAV API
     Then the HTTP status code should be "201"
     And the content of file "/Shares/testshare/testfile.txt" for user "Alice" should be "test data 3"
     And the content of file "/testshare/testfile.txt" for user "Brian" should be "test data 3"
-    And as "<mover>" file "/testfile.txt" should not exist
+    And as "Brian" file "/testfile.txt" should not exist
     And the version folder of file "/Shares/testshare/testfile.txt" for user "Alice" should contain "2" elements
     Examples:
-      | dav_version | mover | dst-folder        |
+      | dav_version |
-      | old         | Brian | /testshare        |
+      | old         |
-      | new         | Brian | /testshare        |
+      | new         |
 
 
   Scenario Outline: moving a file (with versions) out of a shared folder as the sharee and as the sharer
@@ -409,16 +406,16 @@ Feature: dav-versions
       | permissions | change    |
       | shareWith   | Alice     |
     And user "Alice" has accepted share "/testshare" offered by user "Brian"
-    When user "<mover>" moves file "<src-folder>/testfile.txt" to "/testfile.txt" using the WebDAV API
+    When user "Brian" moves file "/testshare/testfile.txt" to "/testfile.txt" using the WebDAV API
     Then the HTTP status code should be "201"
-    And the content of file "/testfile.txt" for user "<mover>" should be "test data 3"
+    And the content of file "/testfile.txt" for user "Brian" should be "test data 3"
     And as "Alice" file "/Shares/testshare/testfile.txt" should not exist
     And as "Brian" file "/testshare/testfile.txt" should not exist
-    And the version folder of file "/testfile.txt" for user "<mover>" should contain "2" elements
+    And the version folder of file "/testfile.txt" for user "Brian" should contain "2" elements
     Examples:
-      | dav_version | mover | src-folder |
+      | dav_version |
-      | old         | Brian | /testshare |
+      | old         |
-      | new         | Brian | /testshare |
+      | new         |
 
 
   Scenario: sharee tries to get file versions of file not shared by the sharer

tests/acceptance/features/coreApiWebdavLocks2/independentLocks.feature

@@ -37,32 +37,32 @@ Feature: independent locks - make sure all locks are independent and don't inter
   Scenario Outline: locking a file/folder with git specific names does not lock other items with the same name in other parts of the file system
     Given using <dav-path> DAV path
     And user "Alice" has created folder "locked/"
-    And user "Alice" has created folder "locked/<foldername>"
+    And user "Alice" has created folder "locked/.git"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/locked/<foldername>/<filename>"
+    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/locked/.git/config"
     And user "Alice" has created folder "notlocked/"
-    And user "Alice" has created folder "notlocked/<foldername>"
+    And user "Alice" has created folder "notlocked/"
-    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "notlocked/<foldername>/<filename>"
+    And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "notlocked/.git/config"
     When user "Alice" locks file "locked/<to-lock>" using the WebDAV API setting the following properties
       | lockscope | <lock-scope> |
     Then the HTTP status code should be "200"
-    And user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/notlocked/<foldername>/file.txt"
+    And user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/notlocked/.git/file.txt"
-    And user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/notlocked/<foldername>/<filename>"
+    And user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/notlocked/.git/config"
-    But user "Alice" should not be able to upload file "filesForUpload/lorem.txt" to "/locked/<foldername>/<filename>"
+    But user "Alice" should not be able to upload file "filesForUpload/lorem.txt" to "/locked/.git/config"
     Examples:
-      | dav-path | lock-scope | foldername | filename | to-lock     |
+      | dav-path | lock-scope | to-lock     |
-      | old      | shared     | .git       | config   | .git        |
+      | old      | shared     | .git        |
-      | old      | shared     | .git       | config   | .git/config |
+      | old      | shared     | .git/config |
-      | old      | exclusive  | .git       | config   | .git        |
+      | old      | exclusive  | .git        |
-      | old      | exclusive  | .git       | config   | .git/config |
+      | old      | exclusive  | .git/config |
-      | new      | shared     | .git       | config   | .git        |
+      | new      | shared     | .git        |
-      | new      | shared     | .git       | config   | .git/config |
+      | new      | shared     | .git/config |
-      | new      | exclusive  | .git       | config   | .git        |
+      | new      | exclusive  | .git        |
-      | new      | exclusive  | .git       | config   | .git/config |
+      | new      | exclusive  | .git/config |
 
     @skipOnRevaMaster
     Examples:
-      | dav-path | lock-scope | foldername | filename | to-lock     |
+      | dav-path | lock-scope | to-lock     |
-      | spaces   | shared     | .git       | config   | .git        |
+      | spaces   | shared     | .git        |
-      | spaces   | shared     | .git       | config   | .git/config |
+      | spaces   | shared     | .git/config |
-      | spaces   | exclusive  | .git       | config   | .git        |
+      | spaces   | exclusive  | .git        |
-      | spaces   | exclusive  | .git       | config   | .git/config |
+      | spaces   | exclusive  | .git/config |

tests/acceptance/features/coreApiWebdavLocksUnlock/unlockSharingToShares.feature

@@ -18,23 +18,23 @@ Feature: UNLOCK locked items (sharing)
     And user "Alice" has locked file "PARENT/parent.txt" setting the following properties
       | lockscope | <lock-scope> |
     And user "Alice" has shared file "PARENT/parent.txt" with user "Brian"
-    And user "Brian" has accepted share "<pending_share_path>" offered by user "Alice"
+    And user "Brian" has accepted share "/parent.txt" offered by user "Alice"
     When user "Brian" unlocks file "Shares/parent.txt" with the last created lock of file "PARENT/parent.txt" of user "Alice" using the WebDAV API
     Then the HTTP status code should be "403"
     And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API
     And 1 locks should be reported for file "Shares/parent.txt" of user "Brian" by the WebDAV API
     Examples:
-      | dav-path | lock-scope | pending_share_path |
+      | dav-path | lock-scope |
-      | old      | shared     | /parent.txt        |
+      | old      | shared     |
-      | old      | exclusive  | /parent.txt        |
+      | old      | exclusive  |
-      | new      | shared     | /parent.txt        |
+      | new      | shared     |
-      | new      | exclusive  | /parent.txt        |
+      | new      | exclusive  |
 
     @skipOnRevaMaster
     Examples:
-      | dav-path | lock-scope | pending_share_path |
+      | dav-path | lock-scope |
-      | spaces   | shared     | /parent.txt        |
+      | spaces   | shared     |
-      | spaces   | exclusive  | /parent.txt        |
+      | spaces   | exclusive  |
 
 
   Scenario Outline: sharee cannot unlock a file within a shared folder when it is locked by the file owner unless the owner lock token is used
@@ -64,7 +64,7 @@ Feature: UNLOCK locked items (sharing)
   Scenario Outline: sharee unlock a shared file
     Given using <dav-path> DAV path
     And user "Alice" has shared file "PARENT/parent.txt" with user "Brian"
-    And user "Brian" has accepted share "<pending_share_path>" offered by user "Alice"
+    And user "Brian" has accepted share "/parent.txt" offered by user "Alice"
     And user "Brian" has locked file "Shares/parent.txt" setting the following properties
       | lockscope | <lock-scope> |
     When user "Brian" unlocks the last created lock of file "Shares/parent.txt" using the WebDAV API
@@ -72,23 +72,23 @@ Feature: UNLOCK locked items (sharing)
     And 0 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API
     And 0 locks should be reported for file "Shares/parent.txt" of user "Brian" by the WebDAV API
     Examples:
-      | dav-path | lock-scope | pending_share_path |
+      | dav-path | lock-scope |
-      | old      | shared     | /parent.txt        |
+      | old      | shared     |
-      | old      | exclusive  | /parent.txt        |
+      | old      | exclusive  |
-      | new      | shared     | /parent.txt        |
+      | new      | shared     |
-      | new      | exclusive  | /parent.txt        |
+      | new      | exclusive  |
 
     @skipOnRevaMaster
     Examples:
-      | dav-path | lock-scope | pending_share_path |
+      | dav-path | lock-scope |
-      | spaces   | shared     | /parent.txt        |
+      | spaces   | shared     |
-      | spaces   | exclusive  | /parent.txt        |
+      | spaces   | exclusive  |
 
 
   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 "Alice" has shared file "PARENT/parent.txt" with user "Brian"
-    And user "Brian" has accepted share "<pending_share_path>" offered by user "Alice"
+    And user "Brian" has accepted share "/parent.txt" offered by user "Alice"
     And user "Brian" has locked file "Shares/parent.txt" setting the following properties
       | lockscope | <lock-scope> |
     When user "Alice" unlocks file "PARENT/parent.txt" with the last created lock of file "Shares/parent.txt" of user "Brian" using the WebDAV API
@@ -96,17 +96,17 @@ Feature: UNLOCK locked items (sharing)
     And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API
     And 1 locks should be reported for file "Shares/parent.txt" of user "Brian" by the WebDAV API
     Examples:
-      | dav-path | lock-scope | pending_share_path |
+      | dav-path | lock-scope |
-      | old      | shared     | /parent.txt        |
+      | old      | shared     |
-      | old      | exclusive  | /parent.txt        |
+      | old      | exclusive  |
-      | new      | shared     | /parent.txt        |
+      | new      | shared     |
-      | new      | exclusive  | /parent.txt        |
+      | new      | exclusive  |
 
     @skipOnRevaMaster
     Examples:
-      | dav-path | lock-scope | pending_share_path |
+      | dav-path | lock-scope |
-      | spaces   | shared     | /parent.txt        |
+      | spaces   | shared     |
-      | spaces   | exclusive  | /parent.txt        |
+      | spaces   | exclusive  |
 
 
   Scenario Outline: unlocking a file in a shared folder, which was locked by the sharee is not possible for the owner unless the receiver's locktoken is used

tests/acceptance/features/coreApiWebdavOperations/propfind.feature

@@ -24,16 +24,16 @@ Feature: PROPFIND
     When user "Alice" requests "<dav_path>" with "PROPFIND" using basic auth and with headers
       | header | value   |
       | depth  | <depth> |
-    Then the HTTP status code should be "<http_status>"
+    Then the HTTP status code should be "207"
     Examples:
-      | dav_path                    | depth    | http_status |
+      | dav_path                    | depth    |
-      | /remote.php/dav/files/alice | 0        | 207         |
+      | /remote.php/dav/files/alice | 0        |
-      | /remote.php/dav/files/alice | infinity | 207         |
+      | /remote.php/dav/files/alice | infinity |
     @skipOnRevaMaster
     Examples:
-      | dav_path                         | depth    | http_status |
+      | dav_path                         | depth    |
-      | /remote.php/dav/spaces/%spaceid% | 0        | 207         |
+      | /remote.php/dav/spaces/%spaceid% | 0        |
-      | /remote.php/dav/spaces/%spaceid% | infinity | 207         |
+      | /remote.php/dav/spaces/%spaceid% | infinity |
 
 
   Scenario: send PROPFIND request to a public link