[full-ci] [tests-only] Use sharing-ng in given steps for sharing (#9221)

* resharing.feature: Used sharingNG for sharing in given step

* unlockFiles.feature: Used sharingNG for sharing in given step

* apiSpacesShares suite: Used sharingNG for sharing in given step

* acceptShares.feature: Used sharingNG for sharing in given step

* uploadFile.feature: Used sharingNG for sharing in given step

* coreApiWebdavUploadTUS suite: Used sharingNG for sharing in given step

* tag.feature: Used sharingNG for sharing in given step

* coreApiShareOperationsToShares2 suite: Used sharingNG for sharing in given step

* updateShare.feature: Used sharingNG for sharing in given step

* Fixed line numbers in expected failure
This commit is contained in:
Prarup Gurung
2024-05-22 13:01:54 +05:45
committed by GitHub
parent bac37771e2
commit 23800a6b09
19 changed files with 373 additions and 303 deletions

View File

@@ -290,6 +290,7 @@ default:
- FeatureContext: *common_feature_context_params
- PublicWebDavContext:
- WebDavPropertiesContext:
- SharingNgContext:
coreApiWebdavUploadTUS:
paths:
@@ -301,6 +302,7 @@ default:
- TUSContext:
- FilesVersionsContext:
- ChecksumContext:
- SharingNgContext:
coreApiWebdavEtagPropagation1:
paths:

View File

@@ -302,6 +302,7 @@ default:
contexts:
- FeatureContext: *common_feature_context_params
- OcisConfigContext:
- SharingNgContext:
apiSpacesDavOperation:
paths:

View File

@@ -60,10 +60,10 @@ File and sync features in a shared scenario
#### [accepting matching name shared resources from different users/groups sets no serial identifiers on the resource name for the receiver](https://github.com/owncloud/ocis/issues/4289)
- [coreApiShareManagementToShares/acceptShares.feature:309](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature#L309)
- [coreApiShareManagementToShares/acceptShares.feature:334](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature#L334)
- [coreApiShareManagementToShares/acceptShares.feature:565](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature#L565)
- [coreApiShareManagementToShares/acceptShares.feature:631](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature#L631)
- [coreApiShareManagementToShares/acceptShares.feature:314](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature#L314)
- [coreApiShareManagementToShares/acceptShares.feature:339](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature#L339)
- [coreApiShareManagementToShares/acceptShares.feature:570](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature#L570)
- [coreApiShareManagementToShares/acceptShares.feature:636](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature#L636)
- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:44](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L44)
- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:45](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L45)
- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:141](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L141)
@@ -275,16 +275,16 @@ And other missing implementation of favorites
- [coreApiWebdavUploadTUS/checksums.feature:293](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature#L293)
- [coreApiWebdavUploadTUS/optionsRequest.feature:10](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/optionsRequest.feature#L10)
- [coreApiWebdavUploadTUS/optionsRequest.feature:25](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/optionsRequest.feature#L25)
- [coreApiWebdavUploadTUS/uploadToShare.feature:166](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L166)
- [coreApiWebdavUploadTUS/uploadToShare.feature:167](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L167)
- [coreApiWebdavUploadTUS/uploadToShare.feature:184](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L184)
- [coreApiWebdavUploadTUS/uploadToShare.feature:185](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L185)
- [coreApiWebdavUploadTUS/uploadToShare.feature:202](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L202)
- [coreApiWebdavUploadTUS/uploadToShare.feature:203](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L203)
- [coreApiWebdavUploadTUS/uploadToShare.feature:216](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L216)
- [coreApiWebdavUploadTUS/uploadToShare.feature:217](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L217)
- [coreApiWebdavUploadTUS/uploadToShare.feature:239](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L239)
- [coreApiWebdavUploadTUS/uploadToShare.feature:240](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L240)
- [coreApiWebdavUploadTUS/uploadToShare.feature:279](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L279)
- [coreApiWebdavUploadTUS/uploadToShare.feature:280](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L280)
- [coreApiWebdavUploadTUS/uploadToShare.feature:262](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L262)
- [coreApiWebdavUploadTUS/uploadToShare.feature:263](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L263)
- [coreApiWebdavUploadTUS/uploadToShare.feature:304](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L304)
- [coreApiWebdavUploadTUS/uploadToShare.feature:305](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L305)
- [coreApiWebdavUploadTUS/uploadToShare.feature:354](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L354)
- [coreApiWebdavUploadTUS/uploadToShare.feature:355](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUploadTUS/uploadToShare.feature#L355)
#### [TUS OPTIONS requests do not reply with TUS headers when invalid password](https://github.com/owncloud/ocis/issues/1012)
@@ -366,9 +366,9 @@ Not everything needs to be implemented for ocis. While the oc10 testsuite covers
- [coreApiShareManagementToShares/acceptShares.feature:64](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature#L64)
- [coreApiShareManagementToShares/acceptShares.feature:154](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature#L154)
- [coreApiShareManagementToShares/acceptShares.feature:186](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature#L186)
- [coreApiShareManagementToShares/acceptShares.feature:230](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature#L230)
- [coreApiShareManagementToShares/acceptShares.feature:298](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature#L298)
- [coreApiShareManagementToShares/acceptShares.feature:532](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature#L532)
- [coreApiShareManagementToShares/acceptShares.feature:235](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature#L235)
- [coreApiShareManagementToShares/acceptShares.feature:303](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature#L303)
- [coreApiShareManagementToShares/acceptShares.feature:537](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature#L537)
- [coreApiShareOperationsToShares2/shareAccessByID.feature:125](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareOperationsToShares2/shareAccessByID.feature#L125)
- [coreApiShareOperationsToShares2/shareAccessByID.feature:126](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareOperationsToShares2/shareAccessByID.feature#L126)
- [coreApiShareManagementBasicToShares/deleteShareFromShares.feature:213](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature#L213)

View File

@@ -20,8 +20,8 @@ The expected failures in this file are from features in the owncloud/ocis repo.
### [Shared mount folder gets deleted when overwritten by a file from personal space](https://github.com/owncloud/ocis/issues/7208)
- [apiSpacesShares/copySpaces.feature:629](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesShares/copySpaces.feature#L629)
- [apiSpacesShares/copySpaces.feature:647](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesShares/copySpaces.feature#L647)
- [apiSpacesShares/copySpaces.feature:634](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesShares/copySpaces.feature#L634)
- [apiSpacesShares/copySpaces.feature:652](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesShares/copySpaces.feature#L652)
#### [PATCH request for TUS upload with wrong checksum gives incorrect response](https://github.com/owncloud/ocis/issues/1755)
@@ -148,12 +148,12 @@ The expected failures in this file are from features in the owncloud/ocis repo.
- [apiLocks/unlockFiles.feature:198](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/unlockFiles.feature#L198)
- [apiLocks/unlockFiles.feature:199](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/unlockFiles.feature#L199)
- [apiLocks/unlockFiles.feature:200](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/unlockFiles.feature#L200)
- [apiLocks/unlockFiles.feature:222](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/unlockFiles.feature#L222)
- [apiLocks/unlockFiles.feature:223](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/unlockFiles.feature#L223)
- [apiLocks/unlockFiles.feature:224](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/unlockFiles.feature#L224)
- [apiLocks/unlockFiles.feature:225](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/unlockFiles.feature#L225)
- [apiLocks/unlockFiles.feature:226](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/unlockFiles.feature#L226)
- [apiLocks/unlockFiles.feature:227](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/unlockFiles.feature#L227)
- [apiLocks/unlockFiles.feature:228](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiLocks/unlockFiles.feature#L228)
#### [Trying to upload to a locked file gives 500](https://github.com/owncloud/ocis/issues/7638)

View File

@@ -211,7 +211,6 @@ Feature: unlock locked items
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
And user "Alice" has shared folder "PARENT" with user "Brian"
And user "Brian" has locked file "Shares/PARENT/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/parent.txt" of user "Brian" using the WebDAV API

View File

@@ -34,10 +34,12 @@ Feature: re-share resources
Scenario Outline: try to re-share folder
Given using <dav-path-version> DAV path
And user "Alice" has created a share inside of space "Personal" with settings:
| path | test |
| shareWith | Brian |
| role | <role> |
And user "Alice" has sent the following resource share invitation:
| resource | test |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | <permissions-role> |
When user "Brian" creates a share inside of space "Shares" with settings:
| path | test |
| shareWith | Carol |
@@ -46,22 +48,24 @@ Feature: re-share resources
And the OCS status code should be "403"
And the OCS status message should be "No share permission"
Examples:
| dav-path-version | role |
| old | editor |
| old | viewer |
| new | editor |
| new | viewer |
| spaces | editor |
| spaces | viewer |
| dav-path-version | role | permissions-role |
| old | editor | Editor |
| old | viewer | Viewer |
| new | editor | Editor |
| new | viewer | Viewer |
| spaces | editor | Editor |
| spaces | viewer | Viewer |
Scenario Outline: try to re-share file
Given user "Alice" has uploaded file with content "other data" to "/textfile1.txt"
Given using <dav-path-version> DAV path
And user "Alice" has created a share inside of space "Personal" with settings:
| path | textfile1.txt |
| shareWith | Brian |
| role | <role> |
And user "Alice" has sent the following resource share invitation:
| resource | textfile1.txt |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | <permissions-role> |
When user "Brian" creates a share inside of space "Shares" with settings:
| path | textfile1.txt |
| shareWith | Carol |
@@ -70,18 +74,23 @@ Feature: re-share resources
And the OCS status code should be "403"
And the OCS status message should be "No share permission"
Examples:
| dav-path-version | role |
| old | editor |
| old | viewer |
| new | editor |
| new | viewer |
| spaces | editor |
| spaces | viewer |
| dav-path-version | role | permissions-role |
| old | editor | File Editor |
| old | viewer | Viewer |
| new | editor | File Editor |
| new | viewer | Viewer |
| spaces | editor | File Editor |
| spaces | viewer | Viewer |
Scenario Outline: try to create a link to the shared folder
Given using OCS API version "<ocs_api_version>"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "all"
And user "Alice" has sent the following resource share invitation:
| resource | test |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
When user "Brian" creates a public link share using the sharing API with settings
| path | /Shares/test |
| permissions | 1 |
@@ -99,9 +108,11 @@ Feature: re-share resources
And using spaces DAV path
And user "Alice" has created a space "project1" with the default quota using the Graph API
And user "Alice" has created a folder "folder" in space "project1"
And user "Alice" has shared a space "project1" with settings:
| shareWith | Brian |
| role | viewer |
And user "Alice" has sent the following space share invitation:
| space | project1 |
| sharee | Brian |
| shareType | user |
| permissionsRole | Space Viewer |
When user "Alice" creates a share inside of space "project1" with settings:
| path | folder |
| shareWith | Brian |
@@ -140,4 +151,4 @@ Feature: re-share resources
| 27 | share + view + edit + delete |
| 29 | share + view + create + delete |
| 31 | share + view + create + edit + delete |

View File

@@ -111,10 +111,12 @@ Feature: Tag
Given user "Alice" has created the following tags for folder "folderMain" of the space "use-tag":
| folderTag |
| marketing |
And user "Alice" has created a share inside of space "use-tag" with settings:
| path | folderMain |
| shareWith | Brian |
| role | viewer |
And user "Alice" has sent the following resource share invitation:
| resource | folderMain |
| space | use-tag |
| sharee | Brian |
| shareType | user |
| permissionsRole | Viewer |
When user "Brian" lists all available tags via the Graph API
Then the HTTP status code should be "200"
And the response should contain following tags:
@@ -123,10 +125,12 @@ Feature: Tag
Scenario Outline: recipient of the shared resource tries to create a tag
Given user "Alice" has created a share inside of space "use-tag" with settings:
| path | folderMain |
| shareWith | Brian |
| role | <space-role> |
Given user "Alice" has sent the following resource share invitation:
| resource | folderMain |
| space | use-tag |
| sharee | Brian |
| shareType | user |
| permissionsRole | <permissions-role> |
When user "Brian" creates the following tags for <resource-type> "<resource>" of space "Shares":
| tag in a shared resource |
| second tag |
@@ -137,18 +141,20 @@ Feature: Tag
| tag in a shared resource |
| second tag |
Examples:
| space-role | resource-type | resource | http-status-code | should-or-not |
| viewer | file | folderMain/insideTheFolder.txt | 403 | should not |
| editor | file | folderMain/insideTheFolder.txt | 200 | should |
| viewer | folder | folderMain | 403 | should not |
| editor | folder | folderMain | 200 | should |
| permissions-role | resource-type | resource | http-status-code | should-or-not |
| Viewer | file | folderMain/insideTheFolder.txt | 403 | should not |
| Editor | file | folderMain/insideTheFolder.txt | 200 | should |
| Viewer | folder | folderMain | 403 | should not |
| Editor | folder | folderMain | 200 | should |
Scenario Outline: recipient of the shared resource tries to remove a tag
Given user "Alice" has created a share inside of space "use-tag" with settings:
| path | folderMain |
| shareWith | Brian |
| role | <space-role> |
Given user "Alice" has sent the following resource share invitation:
| resource | folderMain |
| space | use-tag |
| sharee | Brian |
| shareType | user |
| permissionsRole | <permissions-role> |
And user "Alice" has created the following tags for <resource-type> "<resource>" of the space "use-tag":
| tag in a shared resource |
| second tag |
@@ -162,11 +168,11 @@ Feature: Tag
| tag in a shared resource |
| second tag |
Examples:
| space-role | resource-type | resource | http-status-code | should-or-not |
| viewer | file | folderMain/insideTheFolder.txt | 403 | should |
| editor | file | folderMain/insideTheFolder.txt | 200 | should not |
| viewer | folder | folderMain | 403 | should |
| editor | folder | folderMain | 200 | should not |
| permissions-role | resource-type | resource | http-status-code | should-or-not |
| Viewer | file | folderMain/insideTheFolder.txt | 403 | should |
| Editor | file | folderMain/insideTheFolder.txt | 200 | should not |
| Viewer | folder | folderMain | 403 | should |
| Editor | folder | folderMain | 200 | should not |
Scenario: user removes folder tags

View File

@@ -160,7 +160,12 @@ Feature: copy file
| sharee | Alice |
| shareType | user |
| permissionsRole | <space-role> |
And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "1"
And user "Brian" has sent the following resource share invitation:
| resource | testshare |
| space | Personal |
| sharee | Alice |
| shareType | user |
| permissionsRole | Viewer |
When user "Alice" copies file "/project.txt" from space "Project" to "/testshare/project.txt" inside space "Shares" using the WebDAV API
Then the HTTP status code should be "403"
And for user "Alice" folder "testshare" of the space "Shares" should not contain these files:

View File

@@ -9,7 +9,12 @@ Feature: create file or folder named similar to Shares folder
| Alice |
| Brian |
And user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "read,update"
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Viewer |
Scenario Outline: create a folder with a name similar to Shares

View File

@@ -62,18 +62,22 @@ Feature: Share spaces
Scenario: user unshares a space
Given user "Alice" has shared a space "share space" with settings:
| shareWith | Brian |
| role | viewer |
Given user "Alice" has sent the following space share invitation:
| space | share space |
| sharee | Brian |
| shareType | user |
| permissionsRole | Space Viewer |
When user "Alice" unshares a space "share space" to user "Brian"
Then the HTTP status code should be "200"
But the user "Brian" should not have a space called "share space"
Scenario Outline: owner of a space cannot see the space after removing his access to the space
Given user "Alice" has shared a space "share space" with settings:
| shareWith | Brian |
| role | manager |
Given user "Alice" has sent the following space share invitation:
| space | share space |
| sharee | Brian |
| shareType | user |
| permissionsRole | Manager |
When user "<user>" unshares a space "share space" to user "Alice"
Then the HTTP status code should be "200"
But the user "Alice" should not have a space called "share space"

View File

@@ -214,7 +214,12 @@ Feature: accept/decline shares coming from internal users
Scenario: deleting shares in pending state
Given user "Alice" has shared folder "/PARENT" with user "Brian"
Given user "Alice" has sent the following resource share invitation:
| resource | PARENT |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
And user "Alice" has sent the following resource share invitation:
| resource | textfile0.txt |
| space | Personal |

View File

@@ -56,52 +56,12 @@ Feature: sharing
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file with content "foo" to "/tmp.txt"
And user "Alice" has created a share with settings
| path | /tmp.txt |
| shareType | group |
| permissions | update,read |
| shareWith | grp1 |
When user "Brian" gets the following properties of file "/Shares/tmp.txt" using the WebDAV API
| propertyName |
| ocs:share-permissions |
Then the HTTP status code should be "207"
And the single response should contain a property "ocs:share-permissions" with value "3"
Examples:
| dav-path-version |
| old |
| new |
@skipOnReva @issue-2213
Scenario Outline: check webdav share-permissions for received file with edit permissions but no reshare permissions
Given using <dav-path-version> DAV path
And user "Alice" has uploaded file with content "foo" to "/tmp.txt"
And user "Alice" has sent the following resource share invitation:
| resource | tmp.txt |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Viewer |
And using SharingNG
When user "Alice" updates the last share using the sharing API with
| permissions | update,read |
Then the HTTP status code should be "200"
And as user "Brian" file "/Shares/tmp.txt" should contain a property "ocs:share-permissions" with value "3"
Examples:
| dav-path-version |
| old |
| new |
@issue-2213
Scenario Outline: check webdav share-permissions for received group shared file with edit permissions but no reshare permissions
Given using <dav-path-version> DAV path
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file with content "foo" to "/tmp.txt"
And user "Alice" has created a share with settings
| path | /tmp.txt |
| shareType | group |
| permissions | update,read |
| shareWith | grp1 |
| resource | tmp.txt |
| space | Personal |
| sharee | grp1 |
| shareType | group |
| permissionsRole | File Editor |
When user "Brian" gets the following properties of file "/Shares/tmp.txt" using the WebDAV API
| propertyName |
| ocs:share-permissions |
@@ -122,27 +82,6 @@ Feature: sharing
| sharee | Brian |
| shareType | user |
| permissionsRole | Viewer |
And using SharingNG
When user "Alice" updates the last share using the sharing API with
| permissions | read |
Then the HTTP status code should be "200"
And as user "Brian" file "/Shares/tmp.txt" should contain a property "ocs:share-permissions" with value "1"
Examples:
| dav-path-version |
| old |
| new |
Scenario Outline: check webdav share-permissions for received group shared file with reshare permissions but no edit permissions
Given using <dav-path-version> DAV path
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file with content "foo" to "/tmp.txt"
And user "Alice" has created a share with settings
| path | /tmp.txt |
| shareType | group |
| permissions | read |
| shareWith | grp1 |
When user "Brian" gets the following properties of file "/Shares/tmp.txt" using the WebDAV API
| propertyName |
| ocs:share-permissions |
@@ -198,10 +137,12 @@ Feature: sharing
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "/tmp"
And user "Alice" has created a share with settings
| path | tmp |
| shareType | group |
| shareWith | grp1 |
And user "Alice" has sent the following resource share invitation:
| resource | tmp |
| space | Personal |
| sharee | grp1 |
| shareType | group |
| permissionsRole | Editor |
When user "Brian" gets the following properties of folder "/Shares/tmp" using the WebDAV API
| propertyName |
| ocs:share-permissions |
@@ -238,16 +179,17 @@ Feature: sharing
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "/tmp"
And user "Alice" has created a share with settings
| path | tmp |
| shareType | group |
| shareWith | grp1 |
And using SharingNG
And user "Alice" has sent the following resource share invitation:
| resource | tmp |
| space | Personal |
| sharee | grp1 |
| shareType | group |
| permissionsRole | Viewer |
When user "Alice" updates the last share using the sharing API with
| permissions | delete,create,read |
When user "Brian" gets the following properties of folder "/Shares/tmp" using the WebDAV API
| propertyName |
| ocs:share-permissions |
Then the HTTP status code should be "207"
And the single response should contain a property "ocs:share-permissions" with value "13"
Then the HTTP status code should be "200"
And as user "Brian" folder "/Shares/tmp" should contain a property "ocs:share-permissions" with value "13"
Examples:
| dav-path-version |
| old |
@@ -279,16 +221,17 @@ Feature: sharing
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "/tmp"
And user "Alice" has created a share with settings
| path | tmp |
| shareType | group |
| shareWith | grp1 |
And using SharingNG
And user "Alice" has sent the following resource share invitation:
| resource | tmp |
| space | Personal |
| sharee | grp1 |
| shareType | group |
| permissionsRole | Viewer |
When user "Alice" updates the last share using the sharing API with
| permissions | delete,update,read |
When user "Brian" gets the following properties of folder "/Shares/tmp" using the WebDAV API
| propertyName |
| ocs:share-permissions |
Then the HTTP status code should be "207"
And the single response should contain a property "ocs:share-permissions" with value "11"
Then the HTTP status code should be "200"
And as user "Brian" folder "/Shares/tmp" should contain a property "ocs:share-permissions" with value "11"
Examples:
| dav-path-version |
| old |
@@ -320,57 +263,17 @@ Feature: sharing
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "/tmp"
And user "Alice" has created a share with settings
| path | tmp |
| shareType | group |
| shareWith | grp1 |
| permissions | create,update,read |
When user "Brian" gets the following properties of folder "/Shares/tmp" using the WebDAV API
| propertyName |
| ocs:share-permissions |
Then the HTTP status code should be "207"
And the single response should contain a property "ocs:share-permissions" with value "7"
Examples:
| dav-path-version |
| old |
| new |
@skipOnReva
Scenario Outline: check webdav share-permissions for received folder with all permissions but share
Given using <dav-path-version> DAV path
And user "Alice" has created folder "/tmp"
And using SharingNG
And user "Alice" has sent the following resource share invitation:
| resource | tmp |
| space | Personal |
| sharee | Brian |
| shareType | user |
| sharee | grp1 |
| shareType | group |
| permissionsRole | Viewer |
And using SharingNG
When user "Alice" updates the last share using the sharing API with
| permissions | change |
| permissions | create,update,read |
Then the HTTP status code should be "200"
And as user "Brian" folder "/Shares/tmp" should contain a property "ocs:share-permissions" with value "15"
Examples:
| dav-path-version |
| old |
| new |
Scenario Outline: check webdav share-permissions for received group shared folder with all permissions but share
Given using <dav-path-version> DAV path
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "/tmp"
And user "Alice" has created a share with settings
| path | tmp |
| shareType | group |
| shareWith | grp1 |
| permissions | change |
When user "Brian" gets the following properties of folder "/Shares/tmp" using the WebDAV API
| propertyName |
| ocs:share-permissions |
Then the HTTP status code should be "207"
And the single response should contain a property "ocs:share-permissions" with value "15"
And as user "Brian" folder "/Shares/tmp" should contain a property "ocs:share-permissions" with value "7"
Examples:
| dav-path-version |
| old |

View File

@@ -11,11 +11,12 @@ Feature: sharing
Scenario: uploading file to a user read-only share folder does not work
Given user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "FOLDER"
And user "Alice" has created a share with settings
| path | FOLDER |
| shareType | user |
| permissions | read |
| shareWith | Brian |
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Viewer |
When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/FOLDER/textfile.txt" using the WebDAV API
Then the HTTP status code should be "403"
And as "Alice" file "/FOLDER/textfile.txt" should not exist
@@ -27,11 +28,12 @@ Feature: sharing
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "FOLDER"
And user "Alice" has created a share with settings
| path | FOLDER |
| shareType | group |
| permissions | read |
| shareWith | grp1 |
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | grp1 |
| shareType | group |
| permissionsRole | Viewer |
When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/FOLDER/textfile.txt" using the WebDAV API
Then the HTTP status code should be "403"
And as "Alice" file "/FOLDER/textfile.txt" should not exist
@@ -45,11 +47,12 @@ Feature: sharing
Given using <dav-path-version> DAV path
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "FOLDER"
And user "Alice" has created a share with settings
| path | FOLDER |
| shareType | user |
| permissions | create |
| shareWith | Brian |
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Uploader |
When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/FOLDER/textfile.txt" using the WebDAV API
Then the HTTP status code should be "201"
And the following headers should match these regular expressions for user "Brian"
@@ -72,11 +75,12 @@ Feature: sharing
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "FOLDER"
And user "Alice" has created a share with settings
| path | FOLDER |
| shareType | group |
| permissions | create |
| shareWith | grp1 |
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | grp1 |
| shareType | group |
| permissionsRole | Uploader |
When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/FOLDER/textfile.txt" using the WebDAV API
Then the HTTP status code should be "201"
And the following headers should match these regular expressions for user "Brian"
@@ -97,11 +101,12 @@ Feature: sharing
Given using <dav-path-version> DAV path
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "FOLDER"
And user "Alice" has created a share with settings
| path | FOLDER |
| shareType | user |
| permissions | change |
| shareWith | Brian |
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/FOLDER/textfile.txt" using the WebDAV API
Then the HTTP status code should be "201"
And the content of file "/FOLDER/textfile.txt" for user "Alice" should be:
@@ -122,11 +127,12 @@ Feature: sharing
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "FOLDER"
And user "Alice" has created a share with settings
| path | FOLDER |
| shareType | group |
| permissions | change |
| shareWith | grp1 |
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | grp1 |
| shareType | group |
| permissionsRole | Editor |
When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/FOLDER/textfile.txt" using the WebDAV API
Then the HTTP status code should be "201"
And the content of file "/FOLDER/textfile.txt" for user "Alice" should be:
@@ -172,11 +178,12 @@ Feature: sharing
Given using <dav-path-version> DAV path
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "FOLDER"
And user "Alice" has created a share with settings
| path | FOLDER |
| shareType | user |
| permissions | change |
| shareWith | Brian |
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
And user "Admin" has changed the quota of the personal space of "Alice Hansen" space to "1"
When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/FOLDER/myfile.txt" using the WebDAV API
Then the HTTP status code should be "507"
@@ -193,11 +200,12 @@ Feature: sharing
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "FOLDER"
And user "Alice" has created a share with settings
| path | FOLDER |
| shareType | group |
| permissions | change |
| shareWith | grp1 |
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | grp1 |
| shareType | group |
| permissionsRole | Editor |
And user "Admin" has changed the quota of the personal space of "Alice Hansen" space to "1"
When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/FOLDER/myfile.txt" using the WebDAV API
Then the HTTP status code should be "507"
@@ -212,11 +220,12 @@ Feature: sharing
Given using <dav-path-version> DAV path
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "FOLDER"
And user "Alice" has created a share with settings
| path | FOLDER |
| shareType | user |
| permissions | create |
| shareWith | Brian |
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Uploader |
And user "Admin" has changed the quota of the personal space of "Alice Hansen" space to "1"
When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/FOLDER/myfile.txt" using the WebDAV API
Then the HTTP status code should be "507"
@@ -233,11 +242,12 @@ Feature: sharing
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "FOLDER"
And user "Alice" has created a share with settings
| path | FOLDER |
| shareType | group |
| permissions | create |
| shareWith | grp1 |
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | grp1 |
| shareType | group |
| permissionsRole | Uploader |
And user "Admin" has changed the quota of the personal space of "Alice Hansen" space to "1"
When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/FOLDER/myfile.txt" using the WebDAV API
Then the HTTP status code should be "507"
@@ -252,19 +262,20 @@ Feature: sharing
Given using <dav-path-version> DAV path
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "FOLDER"
And user "Alice" has created a share with settings
| path | FOLDER |
| shareType | user |
| permissions | <permissions> |
| shareWith | Brian |
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | <permissions-role> |
When user "Brian" uploads file with content "some content" to "/Shares/FOLDER/textFile.txt" using the WebDAV API
And user "Alice" downloads file "/FOLDER/textFile.txt" using the WebDAV API
Then the HTTP status code should be "200"
And the downloaded content should be "some content"
Examples:
| dav-path-version | permissions |
| old | change |
| new | create |
| dav-path-version | permissions-role |
| old | Editor |
| new | Uploader |
Scenario Outline: upload an empty file (size zero byte) to a shared folder
@@ -273,10 +284,10 @@ Feature: sharing
And user "Brian" has created folder "/folder-to-share"
And user "Brian" has sent the following resource share invitation:
| resource | folder-to-share |
| space | Personal |
| sharee | Alice |
| shareType | user |
| permissionsRole | Editor |
| space | Personal |
| sharee | Alice |
| shareType | user |
| permissionsRole | Editor |
When user "Alice" uploads file "filesForUpload/zerobyte.txt" to "/Shares/folder-to-share/zerobyte.txt" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "/Shares/folder-to-share/zerobyte.txt" should exist

View File

@@ -234,11 +234,12 @@ Feature: sharing
Given using <dav-path-version> DAV path
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "/FOLDER"
And user "Alice" has created a share with settings
| path | FOLDER |
| shareType | user |
| permissions | create |
| shareWith | Brian |
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Uploader |
And user "Brian" has uploaded file with content "some content" to "/Shares/FOLDER/textFile.txt"
When user "Alice" deletes file "/FOLDER/textFile.txt" using the WebDAV API
Then the HTTP status code should be "204"

View File

@@ -399,7 +399,12 @@ Feature: upload file
Given using <dav-path-version> DAV path
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "file with content" to "/textfile.txt"
And user "Alice" has shared file "/textfile.txt" with user "Brian" with permissions "read,update"
And user "Alice" has sent the following resource share invitation:
| resource | textfile.txt |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | File Editor |
When user "Brian" uploads file with content "" to shared resource "Shares/textfile.txt" using the WebDAV API
Then the HTTP status code should be "204"
And for user "Brian" the content of the file "/test.txt" of the space "Shares" should be ""
@@ -427,9 +432,11 @@ Feature: upload file
And the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
And user "Alice" has created a space "new-space" with the default quota using the Graph API
And user "Alice" has uploaded a file inside space "new-space" with content "file with content" to "textfile.txt"
And user "Alice" has shared a space "new-space" with settings:
| shareWith | Brian |
| role | editor |
And user "Alice" has sent the following space share invitation:
| space | new-space |
| sharee | Brian |
| shareType | user |
| permissionsRole | Space Editor |
When user "Brian" uploads a file inside space "new-space" with content "" to "textfile.txt" using the WebDAV API
Then the HTTP status code should be "204"
And for user "Brian" the content of the file "/textfile.txt" of the space "new-space" should be ""

View File

@@ -14,7 +14,12 @@ Feature: upload file
Scenario Outline: upload file with mtime to a received share
Given using <dav-path-version> DAV path
And user "Alice" has created folder "/toShare"
And user "Alice" has shared folder "/toShare" with user "Brian"
And user "Alice" has sent the following resource share invitation:
| resource | toShare |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/toShare/file.txt" with mtime "Thu, 08 Aug 2012 04:18:13 GMT" using the TUS protocol on the WebDAV API
Then as "Alice" the mtime of the file "/toShare/file.txt" should be "Thu, 08 Aug 2012 04:18:13 GMT"
And as "Brian" the mtime of the file "/Shares/toShare/file.txt" should be "Thu, 08 Aug 2012 04:18:13 GMT"
@@ -27,7 +32,12 @@ Feature: upload file
Scenario Outline: upload file with mtime to a send share
Given using <dav-path-version> DAV path
And user "Alice" has created folder "/toShare"
And user "Alice" has shared folder "/toShare" with user "Brian"
And user "Alice" has sent the following resource share invitation:
| resource | toShare |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
When user "Alice" uploads file "filesForUpload/textfile.txt" to "/toShare/file.txt" with mtime "Thu, 08 Aug 2012 04:18:13 GMT" using the TUS protocol on the WebDAV API
Then as "Alice" the mtime of the file "/toShare/file.txt" should be "Thu, 08 Aug 2012 04:18:13 GMT"
And as "Brian" the mtime of the file "/Shares/toShare/file.txt" should be "Thu, 08 Aug 2012 04:18:13 GMT"
@@ -40,7 +50,12 @@ Feature: upload file
Scenario Outline: overwriting a file with mtime in a received share
Given using <dav-path-version> DAV path
And user "Alice" has created folder "/toShare"
And user "Alice" has shared folder "/toShare" with user "Brian"
And user "Alice" has sent the following resource share invitation:
| resource | toShare |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
And user "Alice" has uploaded file with content "uploaded content" to "/toShare/file.txt"
When user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/toShare/file.txt" with mtime "Thu, 08 Aug 2012 04:18:13 GMT" using the TUS protocol on the WebDAV API
Then as "Alice" the mtime of the file "/toShare/file.txt" should be "Thu, 08 Aug 2012 04:18:13 GMT"
@@ -54,7 +69,12 @@ Feature: upload file
Scenario Outline: overwriting a file with mtime in a send share
Given using <dav-path-version> DAV path
And user "Alice" has created folder "/toShare"
And user "Alice" has shared folder "/toShare" with user "Brian"
And user "Alice" has sent the following resource share invitation:
| resource | toShare |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
And user "Brian" has uploaded file with content "uploaded content" to "/Shares/toShare/file.txt"
When user "Alice" uploads file "filesForUpload/textfile.txt" to "/toShare/file.txt" with mtime "Thu, 08 Aug 2012 04:18:13 GMT" using the TUS protocol on the WebDAV API
Then as "Alice" the mtime of the file "/toShare/file.txt" should be "Thu, 08 Aug 2012 04:18:13 GMT"

View File

@@ -39,7 +39,12 @@ Feature: upload file
Given using <dav-path-version> DAV path
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian"
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
When user "Brian" uploads file with content "uploaded content" to "/Shares/FOLDER/nonExistentFolder/textfile.txt" using the TUS protocol on the WebDAV API
Then as "Brian" folder "/Shares/FOLDER/nonExistentFolder" should not exist
And as "Brian" file "/Shares/FOLDER/nonExistentFolder/textfile.txt" should not exist
@@ -53,7 +58,12 @@ Feature: upload file
Given using <dav-path-version> DAV path
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "read"
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Viewer |
When user "Brian" uploads file with content "uploaded content" to "/Shares/FOLDER/nonExistentFolder/textfile.txt" using the TUS protocol on the WebDAV API
Then as "Brian" folder "/Shares/FOLDER/nonExistentFolder" should not exist
And as "Brian" file "/Shares/FOLDER/nonExistentFolder/textfile.txt" should not exist

View File

@@ -14,7 +14,12 @@ Feature: upload file to shared folder
Scenario Outline: uploading file to a received share folder
Given using <dav-path-version> DAV path
And user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian"
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
When user "Brian" uploads file with content "uploaded content" to "/Shares/FOLDER/textfile.txt" using the TUS protocol on the WebDAV API
Then as "Alice" file "/FOLDER/textfile.txt" should exist
And the content of file "/FOLDER/textfile.txt" for user "Alice" should be "uploaded content"
@@ -27,7 +32,12 @@ Feature: upload file to shared folder
Scenario Outline: uploading file to a user read/write share folder works
Given using <dav-path-version> DAV path
And user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "change"
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Uploader |
When user "Brian" uploads file with content "uploaded content" to "/Shares/FOLDER/textfile.txt" using the TUS protocol on the WebDAV API
Then as "Alice" file "/FOLDER/textfile.txt" should exist
And the content of file "/FOLDER/textfile.txt" for user "Alice" should be "uploaded content"
@@ -42,7 +52,12 @@ Feature: upload file to shared folder
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "FOLDER" with group "grp1" with permissions "change"
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | grp1 |
| shareType | group |
| permissionsRole | Uploader |
When user "Brian" uploads file with content "uploaded content" to "/Shares/FOLDER/textfile.txt" using the TUS protocol on the WebDAV API
Then as "Alice" file "/FOLDER/textfile.txt" should exist
And the content of file "/FOLDER/textfile.txt" for user "Alice" should be "uploaded content"
@@ -56,7 +71,12 @@ Feature: upload file to shared folder
Given using <dav-path-version> DAV path
And user "Alice" has created folder "/FOLDER"
And user "Alice" has uploaded file with content "original content" to "/FOLDER/textfile.txt"
And user "Alice" has shared folder "/FOLDER" with user "Brian"
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
When user "Brian" uploads file with content "overwritten content" to "/Shares/FOLDER/textfile.txt" using the TUS protocol on the WebDAV API
Then as "Alice" file "/FOLDER/textfile.txt" should exist
And the content of file "/FOLDER/textfile.txt" for user "Alice" should be "overwritten content"
@@ -69,7 +89,12 @@ Feature: upload file to shared folder
Scenario Outline: attempt to upload a file into a folder within correctly received read only share
Given using <dav-path-version> DAV path
And user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "read"
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Viewer |
When user "Brian" uploads file with content "uploaded content" to "/Shares/FOLDER/textfile.txt" using the TUS protocol on the WebDAV API
Then as "Brian" file "/Shares/FOLDER/textfile.txt" should not exist
Examples:
@@ -81,7 +106,12 @@ Feature: upload file to shared folder
Scenario Outline: upload a file to shared folder with checksum should return the checksum in the propfind for sharee
Given using <dav-path-version> DAV path
And user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian"
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
| Upload-Length | 5 |
# L0ZPTERFUi90ZXh0RmlsZS50eHQ= is the base64 encode of /FOLDER/textFile.txt
@@ -99,7 +129,12 @@ Feature: upload file to shared folder
Scenario Outline: upload a file to shared folder with checksum should return the checksum in the download header for sharee
Given using <dav-path-version> DAV path
And user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian"
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
| Upload-Length | 5 |
# L0ZPTERFUi90ZXh0RmlsZS50eHQ= is the base64 encode of /FOLDER/textFile.txt
@@ -121,7 +156,12 @@ Feature: upload file to shared folder
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
And user "Alice" has uploaded file with checksum "SHA1 8cb2237d0679ca88db6464eac60da96345513964" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API
And user "Alice" has shared file "/textFile.txt" with user "Brian"
And user "Alice" has sent the following resource share invitation:
| resource | textFile.txt |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | File Editor |
When user "Brian" requests the checksum of "/Shares/textFile.txt" via propfind
Then the HTTP status code should be "207"
And the webdav checksum should match "SHA1:8cb2237d0679ca88db6464eac60da96345513964 MD5:827ccb0eea8a706c4c34a16891f84e7b ADLER32:02f80100"
@@ -138,7 +178,12 @@ Feature: upload file to shared folder
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
And user "Alice" has uploaded file with checksum "SHA1 8cb2237d0679ca88db6464eac60da96345513964" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API
And user "Alice" has shared file "/textFile.txt" with user "Brian"
And user "Alice" has sent the following resource share invitation:
| resource | textFile.txt |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | File Editor |
When user "Brian" downloads file "/Shares/textFile.txt" using the WebDAV API
Then the HTTP status code should be "200"
And the header checksum should match "SHA1:8cb2237d0679ca88db6464eac60da96345513964"
@@ -151,7 +196,12 @@ Feature: upload file to shared folder
Scenario Outline: sharee uploads a file to a received share folder with correct checksum
Given using <dav-path-version> DAV path
And user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian"
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
When user "Brian" creates a new TUS resource on the WebDAV API with these headers:
| Tus-Resumable | 1.0.0 |
| Upload-Length | 16 |
@@ -170,7 +220,12 @@ Feature: upload file to shared folder
Scenario Outline: sharee uploads a file to a received share folder with wrong checksum should not work
Given using <dav-path-version> DAV path
And user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian"
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
When user "Brian" creates a new TUS resource on the WebDAV API with these headers:
| Tus-Resumable | 1.0.0 |
| Upload-Length | 16 |
@@ -188,7 +243,12 @@ Feature: upload file to shared folder
Scenario Outline: sharer uploads a file to shared folder with wrong correct checksum should not work
Given using <dav-path-version> DAV path
And user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian"
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
| Upload-Length | 5 |
# L0ZPTERFUi90ZXh0RmlsZS50eHQ= is the base64 encode of /FOLDER/textFile.txt
@@ -223,7 +283,12 @@ Feature: upload file to shared folder
Scenario Outline: sharee uploads a chunked file with correct checksum to a received share folder should work
Given using <dav-path-version> DAV path
And user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian"
And user "Alice" has sent the following resource share invitation:
| resource | FOLDER |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
And user "Brian" creates a new TUS resource on the WebDAV API with these headers:
| Tus-Resumable | 1.0.0 |
| Upload-Length | 10 |
@@ -247,7 +312,12 @@ Feature: upload file to shared folder
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
And user "Alice" has uploaded file with checksum "SHA1 c1dab0c0864b6ac9bdd3743a1408d679f1acd823" to the last created TUS Location with offset "0" and content "original content" using the TUS protocol on the WebDAV API
And user "Alice" has shared file "/textFile.txt" with user "Brian"
And user "Alice" has sent the following resource share invitation:
| resource | textFile.txt |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | File Editor |
When user "Brian" overwrites recently shared file with offset "0" and data "overwritten content" with checksum "SHA1 fe990d2686a0fc86004efc31f5bf2475a45d4905" using the TUS protocol on the WebDAV API with these headers:
| Upload-Length | 19 |
# dGV4dEZpbGUudHh0 is the base64 encode of /Shares/textFile.txt
@@ -267,7 +337,12 @@ Feature: upload file to shared folder
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
And user "Alice" has uploaded file with checksum "SHA1 c1dab0c0864b6ac9bdd3743a1408d679f1acd823" to the last created TUS Location with offset "0" and content "original content" using the TUS protocol on the WebDAV API
And user "Alice" has shared file "/textFile.txt" with user "Brian"
And user "Alice" has sent the following resource share invitation:
| resource | textFile.txt |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | File Editor |
When user "Brian" overwrites recently shared file with offset "0" and data "overwritten content" with checksum "SHA1 fe990d2686a0fc86004efc31f5bf2475a45d4906" using the TUS protocol on the WebDAV API with these headers:
| Upload-Length | 19 |
# dGV4dEZpbGUudHh0 is the base64 encode of /Shares/textFile.txt

View File

@@ -14,7 +14,12 @@ Feature: sharing files and folders
Scenario: accept a pending share
Given user "Alice" has shared folder "/textfile.txt" with user "Brian"
Given user "Alice" has sent the following resource share invitation:
| resource | textfile.txt |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
And using "ocis" as owncloud selector
And the sharing API should report to user "Brian" that these shares are in the accepted state
| path |