mirror/opencloud
1
0
Fork 0
mirror of https://github.com/opencloud-eu/opencloud.git synced 2025-12-31 01:10:20 -06:00
Code Issues Packages Projects Releases Wiki Activity

refactor scenario example table (#6694)

Browse Source
This commit is contained in:
Prajwol Amatya
2023-07-04 15:54:16 +05:45
committed by GitHub
parent 6535e689a2
commit 941ef59cc9
27 changed files with 353 additions and 420 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -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:131](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L131)
- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:165](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L165)
- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:166](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L166)
- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:128](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L128)
- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:129](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L129)
- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:161](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L161)
- [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:744](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L744)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:762](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L762)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:763](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L763)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:778](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L778)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:779](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L779)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:733](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L733)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:734](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L734)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:752](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L752)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:753](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L753)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:768](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L768)
- [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:78](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L78)
- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:61](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L61)
- [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:144](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L144)
- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:125](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L125)
- [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:297](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L297)
- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:406](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L406)
- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:441](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L441)
- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:222](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L222)
- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:253](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L253)
- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:352](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L352)
- [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:244](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L244)
- [coreApiShareUpdateToShares/updateShare.feature:236](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L236)
- [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:679](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L679)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:668](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L668)
- [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:228](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L228)
- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:221](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L221)
- [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:727](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L727)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:716](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L716)
- [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:179](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L179)
- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:180](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L180)
- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:181](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L181)
- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:197](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L197)
- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:198](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L198)
- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:199](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L199)
- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:200](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L200)
- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:172](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L172)
- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:173](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L173)
- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:174](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L174)
- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:175](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L175)
- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:191](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L191)
- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:192](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L192)
- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:193](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L193)
- [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)

16
tests/acceptance/features/apiGraph/editUser.feature
View File

@@ -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 |
| change to a display name | Olaf Scholz | 200 | Olaf Scholz |
| override to existing display name | Carol King | 200 | Carol King |
| change to an empty display name | | 400 | Brian Murphy |
| displayName with characters | *:!;_+-&#(?) | 200 | *:!;_+-&#(?) |
| action description | newDisplayName | displayNameAsResult |
| change to a display name | Olaf Scholz | Olaf Scholz |
| override to existing display name | Carol King | Carol King |
| change to an empty display name | | Brian Murphy |
| 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 |

2
tests/acceptance/features/apiGraph/getUser.feature
View File

@@ -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

20
tests/acceptance/features/apiSpaces/quota.feature
View File

@@ -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 |
| Quota1% | 1 | normal | 100 | 99 | 1 |
| Quota75% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12345 | normal | 100 | 25 | 75 |
| Quota76% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456 | nearing | 100 | 24 | 76 |
| Quota90% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1234567890 | nearing | 100 | 10 | 90 |
| Quota91% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1 | critical | 100 | 9 | 91 |
| Quota99% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 | critical | 100 | 1 | 99 |
| Quota100% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1234567890 | exceeded | 100 | 0 | 100 |
| spaceName | fileContent | state | remaining | used |
| Quota1% | 1 | normal | 99 | 1 |
| Quota75% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12345 | normal | 25 | 75 |
| Quota76% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456 | nearing | 24 | 76 |
| 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 | 9 | 91 |
| 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 | 0 | 100 |
Scenario: file cannot be uploaded if there is insufficient quota

12
tests/acceptance/features/apiSpaces/removeSpaceObjects.feature
View File

@@ -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 |
| Alice | manager | 204 | should not | should | 0 |
| Brian | manager | 204 | should not | should | 0 |
| Brian | editor | 204 | should not | should | 0 |
| Brian | viewer | 403 | should | should not | 12 |
| user | role | code | shouldOrNotBeInSpace | shouldOrNotBeInTrash |
| Alice | manager | 204 | should not | should |
| Brian | manager | 204 | should not | should |
| Brian | editor | 204 | should not | should |
| Brian | viewer | 403 | should | should not |
Scenario: try to delete an empty string folder from a space

16
tests/acceptance/features/apiSpaces/restoreSpaceObjects.feature
View File

@@ -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 "<user>" file "file.txt" 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 "Brian" file "file.txt" should exist in the trashbin of the space "restore objects"
Examples:
| user | role |
| Brian | manager |
| Brian | editor |
| Brian | viewer |
| role |
| manager |
| editor |
| viewer |
Scenario Outline: user can restore a folder with some objects from the trash via the webDav API

16
tests/acceptance/features/apiSpacesShares/shareSubItemOfSpace.feature
View File

@@ -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>"
And the OCS status code should be "<statusCode>"
And the OCS status message should be "<statusMessage>"
Then the HTTP status code should be "404"
And the OCS status code should be "404"
And the OCS status message should be "No share permission"
Examples:
| entity | spaceRole | statusCode | statusMessage |
| folder | editor | 404 | No share permission |
| file.txt | editor | 404 | No share permission |
| file.txt | viewer | 404 | No share permission |
| folder | viewer | 404 | No share permission |
| entity | spaceRole |
| folder | editor |
| file.txt | editor |
| file.txt | viewer |
| folder | viewer |
Scenario Outline: user participant of the project space can see the created resources share

18
tests/acceptance/features/coreApiAuthWebDav/webDavCOPYAuth.feature
View File

@@ -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
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"
| endpoint |
| /remote.php/dav/spaces/%spaceid%/textfile0.txt |
| /remote.php/dav/spaces/%spaceid%/PARENT |
| /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt |
Then the HTTP status code of responses on all endpoints should be "403"
@skipOnRevaMaster
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"
| endpoint |
| /remote.php/dav/spaces/%spaceid%/textfile0.txt |
| /remote.php/dav/spaces/%spaceid%/PARENT |
| /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt |
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 |

2
tests/acceptance/features/coreApiCapabilities/capabilities.feature
View File

@@ -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"

174
tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature
View File

@@ -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 |
| 1 | 100 | /textfile0 (2).txt |
| 2 | 200 | /textfile0 (2).txt |
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 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 |
| 1 | 100 | /CHILD |
| 2 | 200 | /CHILD |
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 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 |
| 1 | 100 | /sub |
| 2 | 200 | /sub |
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 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 |
| 1 | 100 | /sub |
| 2 | 200 | /sub |
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 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% |
| share_with | %username% |
| file_target | <file_target_2> |
| item_type | file |
| permissions | read,update |
| uid_owner | %username% |
| share_with | %username% |
| file_target | /randomfile (2).txt |
| item_type | file |
| 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 |
| 1 | /randomfile.txt | /randomfile (2).txt |
| 2 | /randomfile.txt | /randomfile (2).txt |
| ocs_api_version |
| 1 |
| 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% |
| share_with | %username% |
| file_target | <file_target_1> |
| item_type | folder |
| permissions | read,delete |
| uid_owner | %username% |
| share_with | %username% |
| file_target | /zzzfolder |
| item_type | folder |
| permissions | read,delete |
When user "Carol" shares folder "zzzfolder" with user "Alice" with permissions "read,share" using the sharing API
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% |
| share_with | %username% |
| file_target | <file_target_2> |
| item_type | folder |
| permissions | read,share |
| uid_owner | %username% |
| share_with | %username% |
| file_target | /zzzfolder (2) |
| item_type | folder |
| 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 |
| 1 | /zzzfolder | /zzzfolder (2) | 100 |
| 2 | /zzzfolder | /zzzfolder (2) | 200 |
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 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 |
Scenario Outline: sharing parent folder to user with all permissions and its child folder to group with read permission then check create operation
@issue-2440
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 "Alice" 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 "/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 |
Scenario Outline: sharing parent folder to user with all permissions and its child folder to group with read permission then check rename operation
@issue-2440
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 "Alice" 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 "/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 |
Scenario Outline: sharing parent folder to user with all permissions and its child folder to group with read permission then check delete operation
@issue-2440
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 "Alice" 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 "/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 "Alice" 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 "/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 |
Scenario Outline: sharing parent folder to group with read permission and its child folder to user with all permissions then check rename operation
@issue-2440
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 |
Scenario Outline: sharing parent folder to group with read permission and its child folder to user with all permissions then check delete operation
@issue-2440
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

9
tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWithDisabledUser.feature
View File

@@ -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
Given using OCS API version "<ocs_api_version>"
Scenario: creating a new share with a disabled user
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

34
tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature
View File

@@ -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 |
| 1 | 100 | /textfile0.txt |
| 2 | 200 | /textfile0.txt |
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 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

30
tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature
View File

@@ -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 |
| 1 | 404 | 200 |
| 2 | 404 | 404 |
| ocs_api_version | http_status_code |
| 1 | 200 |
| 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 |
| 1 | 100 | 200 |
| 2 | 200 | 200 |
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |

8
tests/acceptance/features/coreApiShareOperationsToShares1/gettingShares.feature
View File

@@ -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 |
| 1 | 100 | /parent.txt |
| 2 | 200 | /parent.txt |
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |

8
tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShare.feature
View File

@@ -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 |
| 1 | 400 | 200 |
| 2 | 400 | 400 |
| ocs_api_version | http_status_code |
| 1 | 200 |
| 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

4
tests/acceptance/features/coreApiSharePublicLink3/updatePublicLinkShare.feature
View File

@@ -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 |

28
tests/acceptance/features/coreApiShareReshareToShares1/reShare.feature
View File

@@ -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 |
| 2 | 404 | 17 | 19 |
| 1 | 200 | 17 | 23 |
| 2 | 404 | 17 | 23 |
| 1 | 200 | 17 | 31 |
| 2 | 404 | 17 | 31 |
| 1 | 200 | 19 |
| 2 | 404 | 19 |
| 1 | 200 | 23 |
| 2 | 404 | 23 |
| 1 | 200 | 31 |
| 2 | 404 | 31 |
# passing on more bits but not reshare
| 1 | 200 | 17 | 3 |
| 2 | 404 | 17 | 3 |
| 1 | 200 | 17 | 7 |
| 2 | 404 | 17 | 7 |
| 1 | 200 | 17 | 15 |
| 2 | 404 | 17 | 15 |
| 1 | 200 | 3 |
| 2 | 404 | 3 |
| 1 | 200 | 7 |
| 2 | 404 | 7 |
| 1 | 200 | 15 |
| 2 | 404 | 15 |
Scenario Outline: user is allowed to reshare file and set create (4) or delete (8) permissions bits, which get ignored

32
tests/acceptance/features/coreApiShareReshareToShares2/reShareSubfolder.feature
View File

@@ -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 |
| 1 | 100 | /SUB |
| 2 | 200 | /SUB |
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 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 |
| 1 | 100 | /SUB |
| 2 | 200 | /SUB |
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 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 |
| 1 | 100 | /SUB |
| 2 | 200 | /SUB |
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 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 |
| 1 | 200 | /SUB |
| 2 | 404 | /SUB |
| ocs_api_version | http_status_code |
| 1 | 200 |
| 2 | 404 |

17
tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature
View File

@@ -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 |
Scenario Outline: share ownership change after moving a shared file to another share
@issue-2442
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

64
tests/acceptance/features/coreApiSharees/sharees.feature
View File

@@ -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 |
| 1 | 100 | 200 |
| 2 | 200 | 200 |
| ocs-api-version | ocs-status |
| 1 | 100 |
| 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 |
| 1 | 100 | 200 |
| 2 | 200 | 200 |
| ocs-api-version | ocs-status |
| 1 | 100 |
| 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 |
| 1 | 100 | 200 |
| 2 | 200 | 200 |
| ocs-api-version | ocs-status |
| 1 | 100 |
| 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 |
| 1 | 100 | 200 |
| 2 | 200 | 200 |
| ocs-api-version | ocs-status |
| 1 | 100 |
| 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 |
| 1 | 100 | 200 |
| 2 | 200 | 200 |
| ocs-api-version | ocs-status |
| 1 | 100 |
| 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 |
| 1 | 100 | 200 |
| 2 | 200 | 200 |
| ocs-api-version | ocs-status |
| 1 | 100 |
| 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 |
| 1 | 100 | 200 |
| 2 | 200 | 200 |
| ocs-api-version | ocs-status |
| 1 | 100 |
| 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 |
| 1 | 100 | 200 |
| 2 | 200 | 200 |
| ocs-api-version | ocs-status |
| 1 | 100 |
| 2 | 200 |

8
tests/acceptance/features/coreApiTrashbin/trashbinDelete.feature
View File

@@ -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 |
| new | 404 |
| spaces | 404 |
| dav-path |
| new |
| spaces |
Scenario Outline: user tries to delete trashbin file using invalid password

24
tests/acceptance/features/coreApiTrashbin/trashbinFilesFolders.feature
View File

@@ -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 |
| new | 404 |
| spaces | 404 |
| dav-path |
| new |
| 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 |
| new | 404 |
| spaces | 404 |
| dav-path |
| new |
| 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 |
| new | 404 |
| spaces | 404 |
| dav-path |
| new |
| spaces |
@issue-3561
Scenario Outline: listing other user's empty unused trashbin is prohibited

8
tests/acceptance/features/coreApiTrashbinRestore/trashbinRestore.feature
View File

@@ -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 |
| old | 404 |
| new | 404 |
| dav-path |
| old |
| new |
@smokeTest
Scenario Outline: deleted file cannot be restored with invalid password

37
tests/acceptance/features/coreApiVersions/fileVersions.feature
View File

@@ -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
Given using <dav-path> DAV path
Scenario: uploading a chunked file does create the correct version that can be restored
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 "<mover>" 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"
When user "<mover>" moves file "/testfile.txt" to "<dst-folder>/testfile.txt" using the WebDAV API
And user "Brian" has uploaded file with content "test data 1" to "/testfile.txt"
And user "Brian" has uploaded file with content "test data 2" to "/testfile.txt"
And user "Brian" has uploaded file with content "test data 3" to "/testfile.txt"
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 |
| old | Brian | /testshare |
| new | Brian | /testshare |
| dav_version |
| old |
| 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 |
| old | Brian | /testshare |
| new | Brian | /testshare |
| dav_version |
| old |
| new |
Scenario: sharee tries to get file versions of file not shared by the sharer

42
tests/acceptance/features/coreApiWebdavLocks2/independentLocks.feature
View File

@@ -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 uploaded file "filesForUpload/textfile.txt" to "/locked/<foldername>/<filename>"
And user "Alice" has created folder "locked/.git"
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 uploaded file "filesForUpload/textfile.txt" to "notlocked/<foldername>/<filename>"
And user "Alice" has created folder "notlocked/"
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/<foldername>/<filename>"
But user "Alice" should not be able to upload file "filesForUpload/lorem.txt" to "/locked/<foldername>/<filename>"
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/.git/config"
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 |
| old | shared | .git | config | .git |
| old | shared | .git | config | .git/config |
| old | exclusive | .git | config | .git |
| old | exclusive | .git | config | .git/config |
| new | shared | .git | config | .git |
| new | shared | .git | config | .git/config |
| new | exclusive | .git | config | .git |
| new | exclusive | .git | config | .git/config |
| dav-path | lock-scope | to-lock |
| old | shared | .git |
| old | shared | .git/config |
| old | exclusive | .git |
| old | exclusive | .git/config |
| new | shared | .git |
| new | shared | .git/config |
| new | exclusive | .git |
| new | exclusive | .git/config |
@skipOnRevaMaster
Examples:
| dav-path | lock-scope | foldername | filename | to-lock |
| spaces | shared | .git | config | .git |
| spaces | shared | .git | config | .git/config |
| spaces | exclusive | .git | config | .git |
| spaces | exclusive | .git | config | .git/config |
| dav-path | lock-scope | to-lock |
| spaces | shared | .git |
| spaces | shared | .git/config |
| spaces | exclusive | .git |
| spaces | exclusive | .git/config |

54
tests/acceptance/features/coreApiWebdavLocksUnlock/unlockSharingToShares.feature
View File

@@ -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 |
| old | shared | /parent.txt |
| old | exclusive | /parent.txt |
| new | shared | /parent.txt |
| new | exclusive | /parent.txt |
| dav-path | lock-scope |
| old | shared |
| old | exclusive |
| new | shared |
| new | exclusive |
@skipOnRevaMaster
Examples:
| dav-path | lock-scope | pending_share_path |
| spaces | shared | /parent.txt |
| spaces | exclusive | /parent.txt |
| dav-path | lock-scope |
| spaces | shared |
| 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 |
| old | shared | /parent.txt |
| old | exclusive | /parent.txt |
| new | shared | /parent.txt |
| new | exclusive | /parent.txt |
| dav-path | lock-scope |
| old | shared |
| old | exclusive |
| new | shared |
| new | exclusive |
@skipOnRevaMaster
Examples:
| dav-path | lock-scope | pending_share_path |
| spaces | shared | /parent.txt |
| spaces | exclusive | /parent.txt |
| dav-path | lock-scope |
| spaces | shared |
| 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 |
| old | shared | /parent.txt |
| old | exclusive | /parent.txt |
| new | shared | /parent.txt |
| new | exclusive | /parent.txt |
| dav-path | lock-scope |
| old | shared |
| old | exclusive |
| new | shared |
| new | exclusive |
@skipOnRevaMaster
Examples:
| dav-path | lock-scope | pending_share_path |
| spaces | shared | /parent.txt |
| spaces | exclusive | /parent.txt |
| dav-path | lock-scope |
| spaces | shared |
| 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

14
tests/acceptance/features/coreApiWebdavOperations/propfind.feature
View File

@@ -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 |
| /remote.php/dav/files/alice | 0 | 207 |
| /remote.php/dav/files/alice | infinity | 207 |
| dav_path | depth |
| /remote.php/dav/files/alice | 0 |
| /remote.php/dav/files/alice | infinity |
@skipOnRevaMaster
Examples:
| dav_path | depth | http_status |
| /remote.php/dav/spaces/%spaceid% | 0 | 207 |
| /remote.php/dav/spaces/%spaceid% | infinity | 207 |
| dav_path | depth |
| /remote.php/dav/spaces/%spaceid% | 0 |
| /remote.php/dav/spaces/%spaceid% | infinity |
Scenario: send PROPFIND request to a public link