mirror/opencloud
1
0
Fork 0
mirror of https://github.com/opencloud-eu/opencloud.git synced 2026-01-08 13:19:58 -06:00
Code Issues Packages Projects Releases Wiki Activity

Used kebab case for example table header name

Browse Source
This commit is contained in:
Prarup Gurung
2024-03-20 15:01:51 +05:45
parent 84a14c5953
commit ba7d91ebce
57 changed files with 900 additions and 898 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
tests/acceptance/features/coreApiAuth/ocsPUTAuth.feature
View File

@@ -21,8 +21,8 @@ Feature: auth
Scenario: request to edit nonexistent user by authorized admin gets unauthorized in http response
When user "admin" requests these endpoints with "PUT" including body "doesnotmatter" about user "nonexistent"
| endpoint |
| /ocs/v1.php/cloud/users/%username% |
| /ocs/v2.php/cloud/users/%username% |
| endpoint |
| /ocs/v1.php/cloud/users/%username% |
| /ocs/v2.php/cloud/users/%username% |
Then the HTTP status code of responses on all endpoints should be "200"
And the OCS status code of responses on all endpoints should be "101"

10
tests/acceptance/features/coreApiAuth/webDavAuth.feature
View File

@@ -8,22 +8,22 @@ Feature: auth
@smokeTest
Scenario Outline: using WebDAV anonymously
When a user requests "<dav_path>" with "PROPFIND" and no authentication
When a user requests "<dav-path>" with "PROPFIND" and no authentication
Then the HTTP status code should be "401"
Examples:
| dav_path |
| dav-path |
| /remote.php/webdav |
| /dav/spaces/%spaceid% |
@smokeTest
Scenario Outline: using WebDAV with basic auth
When user "Alice" requests "<dav_path>" with "PROPFIND" using basic auth
When user "Alice" requests "<dav-path>" with "PROPFIND" using basic auth
Then the HTTP status code should be "207"
Examples:
| dav_path |
| dav-path |
| /remote.php/webdav |
@skipOnRevaMaster
Examples:
| dav_path |
| dav-path |
| /dav/spaces/%spaceid% |

4
tests/acceptance/features/coreApiAuth/webDavSpecialURLs.feature
View File

@@ -148,7 +148,7 @@ Feature: make webdav request with special urls
| //remote.php//dav/files/%username%/textfile1.txt |
| /remote.php//dav/files/%username%/PARENT/parent.txt |
| /remote.php//webdav/PARENT |
| //remote.php/dav//files/%username%//FOLDER |
| //remote.php/dav//files/%username%//FOLDER |
Then the HTTP status code of responses on all endpoints should be "207"
@skipOnRevaMaster
@@ -169,7 +169,7 @@ Feature: make webdav request with special urls
| //remote.php//dav/files/%username%/textfile1.txt |
| /remote.php//dav/files/%username%/PARENT/parent.txt |
| /remote.php//webdav/PARENT |
| //remote.php/dav//files/%username%//FOLDER |
| //remote.php/dav//files/%username%//FOLDER |
Then the HTTP status code of responses on all endpoints should be "207"
@skipOnRevaMaster

8
tests/acceptance/features/coreApiMain/checksums.feature
View File

@@ -330,16 +330,16 @@ Feature: checksums
@issue-1296
Scenario Outline: uploading a file with checksum should work for file with special characters
Given using <dav-path-version> DAV path
When user "Alice" uploads file "filesForUpload/textfile.txt" to <renamed_file> with checksum "MD5:d70b40f177b14b470d1756a3c12b963a" using the WebDAV API
When user "Alice" uploads file "filesForUpload/textfile.txt" to <renamed-file> with checksum "MD5:d70b40f177b14b470d1756a3c12b963a" using the WebDAV API
Then the HTTP status code should be "201"
And the content of file <renamed_file> for user "Alice" should be:
And the content of file <renamed-file> for user "Alice" should be:
"""
This is a testfile.
Cheers.
"""
Examples:
| dav-path-version | renamed_file |
| dav-path-version | renamed-file |
| old | " oc?test=ab&cd " |
| old | "# %ab ab?=ed" |
| new | " oc?test=ab&cd " |
@@ -347,6 +347,6 @@ Feature: checksums
@skipOnRevaMaster
Examples:
| dav-path-version | renamed_file |
| dav-path-version | renamed-file |
| spaces | " oc?test=ab&cd " |
| spaces | "# %ab ab?=ed" |

2
tests/acceptance/features/coreApiShareCreateSpecialToShares1/createShareResourceCaseSensitiveName.feature
View File

@@ -9,7 +9,7 @@ Feature: Sharing resources with different case names with the sharee and checkin
| username |
| Alice |
| Brian |
And user "Brian" has disabled auto-accepting
And user "Brian" has disabled auto-accepting
Scenario: sharing files with different case names with an internal user

8
tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareDefaultFolderForReceivedShares.feature
View File

@@ -9,15 +9,15 @@ Feature: shares are received in the default folder for received shares
Scenario Outline: do not allow sharing of the entire share folder
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "FOLDER"
When user "Alice" shares folder "/FOLDER" with user "Brian" using the sharing API
And user "Brian" declines share "/Shares/FOLDER" offered by user "Alice" using the sharing API
And user "Brian" shares folder "/Shares" with user "Alice" using the sharing API
Then the OCS status code of responses on each endpoint should be "<ocs_status_code>" respectively
And the HTTP status code of responses on each endpoint should be "<http_status_code>" respectively
Then the OCS status code of responses on each endpoint should be "<ocs-status-code>" respectively
And the HTTP status code of responses on each endpoint should be "<http-status-code>" respectively
Examples:
| ocs_api_version | ocs_status_code | http_status_code |
| ocs-api-version | ocs-status-code | http-status-code |
| 1 | 100, 100, 100, 400 | 200, 200, 200, 200 |
| 2 | 200, 200, 200, 400 | 200, 200, 200, 400 |

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

@@ -12,14 +12,14 @@ Feature: share resources where the sharee receives the share in multiple ways
Scenario Outline: creating and accepting a new share with user who already received a share through their group
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has disabled auto-accepting
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with group "grp1"
When user "Alice" shares file "/textfile0.txt" with user "Brian" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
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 "/textfile0.txt" offered by user "Alice"
And the fields of the last response to user "Alice" sharing with user "Brian" should include
@@ -35,13 +35,13 @@ 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 |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@issue-1289
Scenario Outline: share of folder and sub-folder to same user
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And group "grp4" has been created
And user "Brian" has been added to group "grp4"
And user "Alice" has created folder "/PARENT"
@@ -50,7 +50,7 @@ Feature: share resources where the sharee receives the share in multiple ways
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/PARENT/CHILD/child.txt"
When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API
And user "Alice" shares folder "/PARENT/CHILD" with group "grp4" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And user "Brian" should see the following elements
| /Shares/PARENT/ |
@@ -58,52 +58,52 @@ Feature: share resources where the sharee receives the share in multiple ways
| /Shares/CHILD/ |
| /Shares/CHILD/child.txt |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@issue-2021
Scenario Outline: sharing subfolder when parent already shared
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And group "grp1" has been created
And user "Alice" has created folder "/test"
And user "Alice" has created folder "/test/sub"
And user "Alice" has shared folder "/test" with group "grp1"
When user "Alice" shares folder "/test/sub" with user "Brian" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as "Brian" folder "/Shares/sub" should exist
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@issue-2021
Scenario Outline: sharing subfolder when parent already shared with group of sharer
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And group "grp0" has been created
And user "Alice" has been added to group "grp0"
And user "Alice" has created folder "/test"
And user "Alice" has created folder "/test/sub"
And user "Alice" has shared folder "/test" with group "grp0"
When user "Alice" shares folder "/test/sub" with user "Brian" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as "Brian" folder "/Shares/sub" should exist
Examples:
| ocs_api_version | ocs_status_code |
| 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>"
Given using OCS API version "<ocs-api-version>"
And user "Carol" has been created with default attributes and without skeleton files
And user "Brian" has uploaded file with content "First data" to "/randomfile.txt"
And user "Carol" has uploaded file with content "Second data" to "/randomfile.txt"
When user "Brian" shares file "randomfile.txt" with user "Alice" with permissions "read" using the sharing API
Then the HTTP status code should be "200"
And the OCS status code should be "<ocs_status_code>"
And the OCS status code should be "<ocs-status-code>"
Then as "Alice" the info about the last share by user "Brian" with user "Alice" should include
| uid_owner | %username% |
| share_with | %username% |
@@ -112,7 +112,7 @@ Feature: share resources where the sharee receives the share in multiple ways
| permissions | read |
When user "Carol" shares file "randomfile.txt" with user "Alice" with permissions "read,update" using the sharing API
Then the HTTP status code should be "200"
And the OCS status code should be "<ocs_status_code>"
And the OCS status code should be "<ocs-status-code>"
And as "Alice" the info about the last share by user "Carol" with user "Alice" should include
| uid_owner | %username% |
| share_with | %username% |
@@ -122,13 +122,13 @@ Feature: share resources where the sharee receives the share in multiple ways
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"
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@issue-2131
Scenario Outline: multiple users share a folder with the same name to a user
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Carol" has been created with default attributes and without skeleton files
And user "Brian" has created folder "/zzzfolder"
And user "Brian" has created folder "zzzfolder/Brian"
@@ -145,7 +145,7 @@ Feature: share resources where the sharee receives the share in multiple ways
| 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 the OCS status code should be "<ocs-status-code>"
And as "Alice" the info about the last share by user "Carol" with user "Alice" should include
| uid_owner | %username% |
| share_with | %username% |
@@ -155,13 +155,13 @@ Feature: share resources where the sharee receives the share in multiple ways
And as "Alice" folder "/Shares/zzzfolder/Brian" should exist
And as "Alice" folder "/Shares/zzzfolder (2)/Carol" should exist
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@skipOnReva
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>"
Given using OCS API version "<ocs-api-version>"
And user "Carol" has been created with default attributes and without skeleton files
And these groups have been created:
| groupname |
@@ -180,7 +180,7 @@ Feature: share resources where the sharee receives the share in multiple ways
And the content of file "lorem.txt" for user "Carol" should be "My content"
And the content of file "Shares/lorem.txt" for user "Carol" should be "Shared content"
Examples:
| ocs_api_version |
| ocs-api-version |
| 1 |
| 2 |
@@ -461,7 +461,7 @@ Feature: share resources where the sharee receives the share in multiple ways
@issue-7555
Scenario Outline: share receiver renames a group share and receives same resource through user share with additional permissions
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And group "grp" has been created
And user "Brian" has been added to group "grp"
And user "Alice" has been added to group "grp"
@@ -483,7 +483,7 @@ Feature: share resources where the sharee receives the share in multiple ways
And as "Brian" folder "Shares/sharedParent" should exist
And as "Brian" file "Shares/sharedParent/child/lorem.txt" should exist
Examples:
| ocs_api_version |
| ocs-api-version |
| 1 |
| 2 |

38
tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWithInvalidPermissions.feature
View File

@@ -10,20 +10,20 @@ Feature: cannot share resources with invalid permissions
Scenario Outline: cannot create a share of a file or folder with invalid permissions
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
When user "Alice" creates a share using the sharing API with settings
| path | <item> |
| path | <resource> |
| shareWith | Brian |
| shareType | user |
| permissions | <permissions> |
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "<http_status_code>"
And as "Brian" entry "<item>" should not exist
And as "Brian" entry "/Shares/<item>" should not exist
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "<http-status-code>"
And as "Brian" entry "<resource>" should not exist
And as "Brian" entry "/Shares/<resource>" should not exist
And the sharing API should report to user "Brian" that no shares are in the pending state
Examples:
| ocs_api_version | ocs_status_code | http_status_code | item | permissions |
| ocs-api-version | ocs-status-code | http-status-code | resource | permissions |
| 1 | 400 | 200 | textfile0.txt | 0 |
| 2 | 400 | 400 | textfile0.txt | 0 |
| 1 | 400 | 200 | PARENT | 0 |
@@ -35,7 +35,7 @@ Feature: cannot share resources with invalid permissions
Scenario Outline: cannot create a share of a file with a user with only create permission
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
When user "Alice" creates a share using the sharing API with settings
| path | textfile0.txt |
@@ -43,18 +43,18 @@ Feature: cannot share resources with invalid permissions
| shareType | user |
| permissions | create |
Then the OCS status code should be "400"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
And as "Brian" entry "textfile0.txt" should not exist
And as "Brian" entry "/Shares/textfile0.txt" should not exist
And the sharing API should report to user "Brian" that no shares are in the pending state
Examples:
| ocs_api_version | http_status_code |
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 400 |
Scenario Outline: cannot create a share of a file with a user with only (create,delete) permission
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
When user "Alice" creates a share using the sharing API with settings
| path | textfile0.txt |
@@ -62,12 +62,12 @@ Feature: cannot share resources with invalid permissions
| shareType | user |
| permissions | <permissions> |
Then the OCS status code should be "400"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
And as "Brian" entry "textfile0.txt" should not exist
And as "Brian" entry "/Shares/textfile0.txt" should not exist
And the sharing API should report to user "Brian" that no shares are in the pending state
Examples:
| ocs_api_version | http_status_code | permissions |
| ocs-api-version | http-status-code | permissions |
| 1 | 200 | delete |
| 2 | 400 | delete |
| 1 | 200 | create,delete |
@@ -75,7 +75,7 @@ Feature: cannot share resources with invalid permissions
Scenario Outline: cannot create a share of a file with a group with only create permission
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
@@ -85,18 +85,18 @@ Feature: cannot share resources with invalid permissions
| shareType | group |
| permissions | create |
Then the OCS status code should be "400"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
And as "Brian" entry "textfile0.txt" should not exist
And as "Brian" entry "/Shares/textfile0.txt" should not exist
And the sharing API should report to user "Brian" that no shares are in the pending state
Examples:
| ocs_api_version | http_status_code |
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 400 |
Scenario Outline: cannot create a share of a file with a group with only (create,delete) permission
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
@@ -106,12 +106,12 @@ Feature: cannot share resources with invalid permissions
| shareType | group |
| permissions | <permissions> |
Then the OCS status code should be "400"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
And as "Brian" entry "textfile0.txt" should not exist
And as "Brian" entry "/Shares/textfile0.txt" should not exist
And the sharing API should report to user "Brian" that no shares are in the pending state
Examples:
| ocs_api_version | http_status_code | permissions |
| ocs-api-version | http-status-code | permissions |
| 1 | 200 | delete |
| 2 | 400 | delete |
| 1 | 200 | create,delete |

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

@@ -9,11 +9,11 @@ Feature: sharing
@smokeTest
Scenario Outline: creating a share of a file with a user, the default permissions are read(1)+update(2)+can-share(16)
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" sharing with user "Brian" should include
| share_with | %username% |
@@ -30,17 +30,17 @@ Feature: sharing
| share_type | user |
And the content of file "/Shares/textfile0.txt" for user "Brian" should be "ownCloud test text file 0"
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@smokeTest @issue-2133
Scenario Outline: creating a share of a file containing commas in the filename, with a user, the default permissions are read(1)+update(2)+can-share(16)
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "file with comma in filename" to "/sample,1.txt"
When user "Alice" shares file "sample,1.txt" with user "Brian" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" sharing with user "Brian" should include
| share_with | %username% |
@@ -56,24 +56,24 @@ Feature: sharing
| share_type | user |
And the content of file "/Shares/sample,1.txt" for user "Brian" should be "file with comma in filename"
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@issue-2133 @issue-1270 @issue-1271
Scenario Outline: creating a share of a file with a user and asking for various permission combinations
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
When user "Alice" shares file "textfile0.txt" with user "Brian" with permissions <requested_permissions> using the sharing API
Then the OCS status code should be "<ocs_status_code>"
When user "Alice" shares file "textfile0.txt" with user "Brian" with permissions <requested-permissions> using the sharing API
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" sharing with user "Brian" should include
| share_with | %username% |
| share_with_displayname | %displayname% |
| file_target | /Shares/textfile0.txt |
| path | /textfile0.txt |
| permissions | <granted_permissions> |
| permissions | <granted-permissions> |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| item_type | file |
@@ -81,7 +81,7 @@ Feature: sharing
| storage_id | ANY_VALUE |
| share_type | user |
Examples:
| ocs_api_version | requested_permissions | granted_permissions | ocs_status_code |
| ocs-api-version | requested-permissions | granted-permissions | ocs-status-code |
# Ask for full permissions. You get share plus read plus update. create and delete do not apply to shares of a file
| 1 | 31 | 19 | 100 |
| 2 | 31 | 19 | 200 |
@@ -97,7 +97,7 @@ Feature: sharing
Scenario Outline: creating a share of a file with no permissions should fail
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "Random data" to "randomfile.txt"
When user "Alice" shares file "randomfile.txt" with user "Brian" with permissions "0" using the sharing API
@@ -107,13 +107,13 @@ Feature: sharing
And as "Brian" file "/Shares/randomfile.txt" should not exist
And as "Brian" file "randomfile.txt" should not exist
Examples:
| ocs_api_version | http_status_code |
| ocs-api-version | http_status_code |
| 1 | 200 |
| 2 | 400 |
Scenario Outline: creating a share of a folder with no permissions should fail
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "/afolder"
When user "Alice" shares folder "afolder" with user "Brian" with permissions "0" using the sharing API
@@ -123,17 +123,17 @@ Feature: sharing
And as "Brian" folder "/Shares/afolder" should not exist
And as "Brian" folder "afolder" should not exist
Examples:
| ocs_api_version | http_status_code |
| ocs-api-version | http_status_code |
| 1 | 200 |
| 2 | 400 |
@issue-2133
Scenario Outline: creating a share of a folder with a user, the default permissions are all permissions(31)
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "/FOLDER"
When user "Alice" shares folder "/FOLDER" with user "Brian" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" sharing with user "Brian" should include
| share_with | %username% |
@@ -148,17 +148,17 @@ Feature: sharing
| storage_id | ANY_VALUE |
| share_type | user |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: creating a share of a file with a group, the default permissions are read(1)+update(2)+can-share(16)
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And group "grp1" has been created
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
When user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" sharing with group "grp1" should include
| share_with | grp1 |
@@ -173,17 +173,17 @@ Feature: sharing
| storage_id | ANY_VALUE |
| share_type | group |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: creating a share of a folder with a group, the default permissions are all permissions(31)
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And group "grp1" has been created
And user "Alice" has created folder "/FOLDER"
When user "Alice" shares folder "/FOLDER" with group "grp1" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" sharing with user "Brian" should include
| share_with | grp1 |
@@ -198,7 +198,7 @@ Feature: sharing
| storage_id | ANY_VALUE |
| share_type | group |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@@ -262,7 +262,7 @@ Feature: sharing
@issue-2201
Scenario Outline: sharing subfolder of already shared folder, GET result is correct
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And these users have been created with default attributes and without skeleton files:
| username |
| Brian |
@@ -276,38 +276,38 @@ Feature: sharing
And user "Alice" has shared folder "/folder1/folder2" with user "David"
And user "Alice" has shared folder "/folder1/folder2" with user "Emily"
When user "Alice" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/shares"
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the response should contain 4 entries
And folder "/folder1" should be included as path in the response
And folder "/folder1/folder2" should be included as path in the response
When user "Alice" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/shares?path=/folder1/folder2"
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the response should contain 2 entries
And folder "/folder1" should not be included as path in the response
And folder "/folder1/folder2" should be included as path in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: user shares a file with file name longer than 64 chars to another user
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
And user "Alice" has moved file "textfile0.txt" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt"
When user "Alice" shares file "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" with user "Brian" using the sharing API
Then as "Brian" file "/Shares/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" should exist
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
| ocs-api-version |
| 1 |
| 2 |
Scenario Outline: user shares a file with file name longer than 64 chars to a group
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And group "grp1" has been created
And user "Brian" has been created with default attributes and without skeleton files
And user "Brian" has been added to group "grp1"
@@ -316,13 +316,13 @@ Feature: sharing
When user "Alice" shares file "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" with group "grp1" using the sharing API
Then as "Brian" file "/Shares/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" should exist
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
| ocs-api-version |
| 1 |
| 2 |
Scenario Outline: user shares a folder with folder name longer than 64 chars to another user
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "ownCloud test" to "/textfile0.txt"
And user "Alice" has created folder "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog"
@@ -330,13 +330,13 @@ Feature: sharing
When user "Alice" shares folder "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" with user "Brian" using the sharing API
Then the content of file "/Shares/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog/textfile0.txt" for user "Brian" should be "ownCloud test"
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
| ocs-api-version |
| 1 |
| 2 |
Scenario Outline: user shares a folder with folder name longer than 64 chars to a group
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And group "grp1" has been created
And user "Brian" has been created with default attributes and without skeleton files
And user "Brian" has been added to group "grp1"
@@ -346,9 +346,9 @@ Feature: sharing
When user "Alice" shares folder "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" with group "grp1" using the sharing API
Then the content of file "/Shares/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog/textfile0.txt" for user "Brian" should be "ownCloud test"
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
| ocs-api-version |
| 1 |
| 2 |
Scenario: share with user when username contains capital letters
@@ -384,7 +384,7 @@ Feature: sharing
Scenario Outline: share of folder to a group with emoji in the name
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And these users have been created with default attributes and without skeleton files:
| username |
| Brian |
@@ -395,7 +395,7 @@ Feature: sharing
And user "Alice" has created folder "/PARENT"
And user "Alice" has uploaded file with content "file in parent folder" to "/PARENT/parent.txt"
When user "Alice" shares folder "/PARENT" with group "😀 😁" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
Then user "Brian" should see the following elements
| /Shares/PARENT/ |
@@ -404,13 +404,13 @@ Feature: sharing
| /Shares/PARENT/ |
| /Shares/PARENT/parent.txt |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@skipOnReva
Scenario Outline: share with a group and then add a user to that group
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And these users have been created with default attributes and without skeleton files:
| username |
| Brian |
@@ -421,7 +421,7 @@ Feature: sharing
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file with content "some content" to "lorem.txt"
When user "Alice" shares file "lorem.txt" with group "grp1" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the content of file "/Shares/lorem.txt" for user "Brian" should be "some content"
When the administrator adds user "Carol" to group "grp1" using the provisioning API
@@ -431,14 +431,14 @@ Feature: sharing
| path |
| /lorem.txt |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 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>"
Given using OCS API version "<ocs-api-version>"
And these users have been created with default attributes and without skeleton files:
| username |
| Brian |
@@ -449,7 +449,7 @@ Feature: sharing
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
And user "Alice" has shared file "/textfile0.txt" with group "grp1"
When user "Alice" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/shares"
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" sharing with group "grp1" should include
| share_with | grp1 |
@@ -460,13 +460,13 @@ Feature: sharing
And as "Carol" file "/Shares/textfile0.txt" should exist
When the administrator deletes group "grp1" using the Graph API
And user "Alice" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/shares"
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And file "/textfile0.txt" should not be included as path in the response
And as "Brian" file "/Shares/textfile0.txt" should not exist
And as "Carol" file "/Shares/textfile0.txt" should not exist
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@@ -548,12 +548,12 @@ Feature: sharing
@smokeTest
Scenario Outline: creating a share of a renamed file
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
And user "Alice" has moved file "/textfile0.txt" to "/renamed.txt"
When user "Alice" shares file "renamed.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 "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" sharing with user "Brian" should include
| share_with | %username% |
@@ -569,13 +569,13 @@ Feature: sharing
| share_type | user |
And the content of file "/Shares/renamed.txt" for user "Brian" should be "ownCloud test text file 0"
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@issue-903
Scenario Outline: shares to a deleted user should not be listed as shares for the sharer
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And these users have been created with default attributes and without skeleton files:
| username |
| Brian |
@@ -585,25 +585,25 @@ Feature: sharing
And user "Alice" has shared file "textfile0.txt" with user "Carol"
And the administrator has deleted user "Brian" using the provisioning API
When user "Alice" gets all the shares of the file "textfile0.txt" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And user "Carol" should be included in the response
But user "Brian" should not be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@issue-719
Scenario Outline: creating a share of a renamed file when another share exists
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "/Folder1"
And user "Alice" has created folder "/Folder2"
And user "Alice" has shared folder "/Folder1" with user "Brian"
And user "Alice" has moved file "/Folder2" to "/renamedFolder2"
When user "Alice" shares folder "/renamedFolder2" with user "Brian" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" sharing with user "Brian" should include
| share_with | %username% |
@@ -619,7 +619,7 @@ Feature: sharing
| share_type | user |
And as "Brian" folder "/Shares/renamedFolder2" should exist
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@@ -630,13 +630,13 @@ Feature: sharing
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with group "grp1"
When user "Alice" shares file "textfile0.txt" with group "grp1" using the sharing API
Then the HTTP status code should be "<http-status>"
Then the HTTP status code should be "<http-status-code>"
And the OCS status code should be "403"
And the OCS status message should be "Path already shared with this group"
Examples:
| ocs-api-version | http-status |
| 1 | 200 |
| 2 | 403 |
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
@issue-2215
Scenario Outline: sharing the shares folder to users is not possible
@@ -646,13 +646,13 @@ Feature: sharing
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
When user "Brian" shares folder "Shares" with user "Carol" using the sharing API
Then the HTTP status code should be "<http-status>"
Then the HTTP status code should be "<http-status-code>"
And the OCS status code should be "403"
And the OCS status message should be "Path contains files shared with you"
Examples:
| ocs-api-version | http-status |
| 1 | 200 |
| 2 | 403 |
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
@issue-2215
Scenario Outline: sharing the shares folder to groups is not possible
@@ -664,13 +664,13 @@ Feature: sharing
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
When user "Brian" shares folder "Shares" with group "share_group" using the sharing API
Then the HTTP status code should be "<http-status>"
Then the HTTP status code should be "<http-status-code>"
And the OCS status code should be "403"
And the OCS status message should be "Path contains files shared with you"
Examples:
| ocs-api-version | http-status |
| 1 | 200 |
| 2 | 403 |
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
@issue-2215
Scenario Outline: sharing the shares folder as public link is not possible
@@ -679,10 +679,10 @@ Feature: sharing
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
When user "Brian" creates a public link share of folder "Shares" using the sharing API
Then the HTTP status code should be "<http-status>"
Then the HTTP status code should be "<http-status-code>"
And the OCS status code should be "403"
And the OCS status message should be "Path contains files shared with you"
Examples:
| ocs-api-version | http-status |
| 1 | 200 |
| 2 | 403 |
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |

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

@@ -13,33 +13,33 @@ Feature: sharing
@issue-7555
Scenario Outline: delete all group shares
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has shared file "textfile0.txt" with group "grp1"
And user "Brian" has moved file "/Shares/textfile0.txt" to "/Shares/anotherName.txt"
When user "Alice" deletes the last share using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And user "Brian" should not see the share id of the last share
And as "Brian" file "/Shares/textfile0.txt" should not exist
And as "Brian" file "/Shares/anotherName.txt" should not exist
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@smokeTest
Scenario Outline: delete a share
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
When user "Alice" deletes the last share using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the last share id should not be included in the response
And as "Brian" file "/Shares/textfile0.txt" should not exist
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@@ -140,7 +140,7 @@ Feature: sharing
Scenario Outline: group share recipient tries to delete the share
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And group "grp1" has been created
And these users have been created with default attributes and without skeleton files:
| username |
@@ -149,73 +149,73 @@ Feature: sharing
And user "Carol" has been added to group "grp1"
And user "Alice" has created folder "/shared"
And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt"
And user "Alice" has shared entry "<entry_to_share>" with group "grp1"
And user "Alice" has shared entry "<entry-to-share>" with group "grp1"
When user "Brian" deletes the last share of user "Alice" using the sharing API
Then the OCS status code should be "404"
And the HTTP status code should be "<http_status_code>"
And as "Alice" entry "<entry_to_share>" should exist
And as "Brian" entry "<received_entry>" should exist
And as "Carol" entry "<received_entry>" should exist
And the HTTP status code should be "<http-status-code>"
And as "Alice" entry "<entry-to-share>" should exist
And as "Brian" entry "<received-entry>" should exist
And as "Carol" entry "<received-entry>" should exist
Examples:
| entry_to_share | ocs_api_version | http_status_code | received_entry | pending_entry |
| /shared/shared_file.txt | 1 | 200 | /Shares/shared_file.txt | /Shares/shared_file.txt |
| /shared/shared_file.txt | 2 | 404 | /Shares/shared_file.txt | /Shares/shared_file.txt |
| /shared | 1 | 200 | /Shares/shared | /Shares/shared |
| /shared | 2 | 404 | /Shares/shared | /Shares/shared |
| entry-to-share | ocs-api-version | http-status-code | received-entry |
| /shared/shared_file.txt | 1 | 200 | /Shares/shared_file.txt |
| /shared/shared_file.txt | 2 | 404 | /Shares/shared_file.txt |
| /shared | 1 | 200 | /Shares/shared |
| /shared | 2 | 404 | /Shares/shared |
Scenario Outline: individual share recipient tries to delete the share
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/shared"
And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt"
And user "Alice" has shared entry "<entry_to_share>" with user "Brian"
And user "Alice" has shared entry "<entry-to-share>" with user "Brian"
When user "Brian" deletes the last share of user "Alice" using the sharing API
Then the OCS status code should be "404"
And the HTTP status code should be "<http_status_code>"
And as "Alice" entry "<entry_to_share>" should exist
And as "Brian" entry "<received_entry>" should exist
And the HTTP status code should be "<http-status-code>"
And as "Alice" entry "<entry-to-share>" should exist
And as "Brian" entry "<received-entry>" should exist
Examples:
| entry_to_share | ocs_api_version | http_status_code | received_entry | pending_entry |
| /shared/shared_file.txt | 1 | 200 | /Shares/shared_file.txt | /Shares/shared_file.txt |
| /shared/shared_file.txt | 2 | 404 | /Shares/shared_file.txt | /Shares/shared_file.txt |
| /shared | 1 | 200 | /Shares/shared | /Shares/shared |
| /shared | 2 | 404 | /Shares/shared | /Shares/shared |
| entry-to-share | ocs-api-version | http-status-code | received-entry |
| /shared/shared_file.txt | 1 | 200 | /Shares/shared_file.txt |
| /shared/shared_file.txt | 2 | 404 | /Shares/shared_file.txt |
| /shared | 1 | 200 | /Shares/shared |
| /shared | 2 | 404 | /Shares/shared |
@issue-720
Scenario Outline: request PROPFIND after sharer deletes the collaborator
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
When user "Alice" deletes the last share using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
When user "Brian" requests "/remote.php/dav/files/%username%" with "PROPFIND" using basic auth
Then the HTTP status code should be "207"
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@issue-1229
Scenario Outline: delete a share with wrong authentication
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
When user "Brian" tries to delete the last share of user "Alice" using the sharing API
Then the OCS status code should be "404"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
Examples:
| ocs_api_version | http_status_code |
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 404 |
Scenario Outline: unshare a shared resources
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
When user "Alice" unshares file "textfile0.txt" shared to "Brian"
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-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 |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |

2
tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature
View File

@@ -241,7 +241,7 @@ Feature: accept/decline shares coming from internal users
Then the OCS status code should be "100"
And the HTTP status code should be "200"
And the sharing API should report to user "Brian" that these shares are in the pending state
| path |
| path |
| /Shares/PARENT/ |
And the sharing API should report that no shares are shared with user "Alice"

52
tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShare.feature
View File

@@ -62,7 +62,7 @@ Feature: sharing
And as user "Carol" the value of the item "//oc:name" of path "<dav-path>/sharefile.txt" in the response should be "sharefile.txt"
And as user "Carol" the value of the item "//d:displayname" of path "<dav-path>/sharefile.txt" in the response should be "sharefile.txt"
Examples:
| dav-path | dav-path-personal |
| dav-path | dav-path-personal |
| /remote.php/dav/spaces/%shares_drive_id% | /remote.php/dav/spaces/%spaceid% |
| /dav/spaces/%shares_drive_id% | /remote.php/dav/spaces/%spaceid% |
@@ -119,7 +119,7 @@ Feature: sharing
And as user "Brian" the value of the item "//oc:name" of path "<dav-path>/sharefile.txt" in the response should be "sharefile.txt"
And as user "Brian" the value of the item "//d:displayname" of path "<dav-path>/sharefile.txt" in the response should be "sharefile.txt"
Examples:
| dav-path | dav-path-personal |
| dav-path | dav-path-personal |
| /remote.php/dav/spaces/%shares_drive_id% | /remote.php/dav/spaces/%spaceid% |
| /dav/spaces/%shares_drive_id% | /remote.php/dav/spaces/%spaceid% |
@@ -252,20 +252,20 @@ Feature: sharing
Scenario Outline: receiver renames a received folder share to name with special characters in group sharing
Given group "grp1" has been created
And user "Carol" has been added to group "grp1"
And user "Alice" has created folder "<sharer_folder>"
And user "Alice" has created folder "<group_folder>"
And user "Alice" has shared folder "<sharer_folder>" with user "Brian"
When user "Brian" moves folder "/Shares/<sharer_folder>" to "/Shares/<receiver_folder>" using the WebDAV API
And user "Alice" has created folder "<sharer-folder>"
And user "Alice" has created folder "<group-folder>"
And user "Alice" has shared folder "<sharer-folder>" with user "Brian"
When user "Brian" moves folder "/Shares/<sharer-folder>" to "/Shares/<receiver-folder>" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" folder "<receiver_folder>" should not exist
And as "Brian" folder "/Shares/<receiver_folder>" should exist
When user "Alice" shares folder "<group_folder>" with group "grp1" using the sharing API
And user "Carol" moves folder "/Shares/<group_folder>" to "/Shares/<receiver_folder>" using the WebDAV API
And as "Alice" folder "<receiver-folder>" should not exist
And as "Brian" folder "/Shares/<receiver-folder>" should exist
When user "Alice" shares folder "<group-folder>" with group "grp1" using the sharing API
And user "Carol" moves folder "/Shares/<group-folder>" to "/Shares/<receiver-folder>" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" folder "<receiver_folder>" should not exist
But as "Carol" folder "/Shares/<receiver_folder>" should exist
And as "Alice" folder "<receiver-folder>" should not exist
But as "Carol" folder "/Shares/<receiver-folder>" should exist
Examples:
| sharer_folder | group_folder | receiver_folder |
| sharer-folder | group-folder | receiver-folder |
| ?abc=oc # | ?abc=oc g%rp# | # oc?test=oc&a |
| @a#8a=b?c=d | @a#8a=b?c=d grp | ?a#8 a=b?c=d |
@@ -273,21 +273,21 @@ Feature: sharing
Scenario Outline: receiver renames a received file share to name with special characters with share, read, change permissions in group sharing
Given group "grp1" has been created
And user "Carol" has been added to group "grp1"
And user "Alice" has created folder "<sharer_folder>"
And user "Alice" has created folder "<group_folder>"
And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "/<sharer_folder>/fileInside"
And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "/<group_folder>/fileInside"
And user "Alice" has shared folder "<sharer_folder>" with user "Brian" with permissions "share,read,change"
When user "Brian" moves folder "/Shares/<sharer_folder>/fileInside" to "/Shares/<sharer_folder>/<receiver_file>" using the WebDAV API
And user "Alice" has created folder "<sharer-folder>"
And user "Alice" has created folder "<group-folder>"
And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "/<sharer-folder>/fileInside"
And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "/<group-folder>/fileInside"
And user "Alice" has shared folder "<sharer-folder>" with user "Brian" with permissions "share,read,change"
When user "Brian" moves folder "/Shares/<sharer-folder>/fileInside" to "/Shares/<sharer-folder>/<receiver_file>" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "<sharer_folder>/<receiver_file>" should exist
And as "Brian" file "/Shares/<sharer_folder>/<receiver_file>" should exist
When user "Alice" shares folder "<group_folder>" with group "grp1" with permissions "share,read,change" using the sharing API
And user "Carol" moves folder "/Shares/<group_folder>/fileInside" to "/Shares/<group_folder>/<receiver_file>" using the WebDAV API
And as "Alice" file "<sharer-folder>/<receiver_file>" should exist
And as "Brian" file "/Shares/<sharer-folder>/<receiver_file>" should exist
When user "Alice" shares folder "<group-folder>" with group "grp1" with permissions "share,read,change" using the sharing API
And user "Carol" moves folder "/Shares/<group-folder>/fileInside" to "/Shares/<group-folder>/<receiver_file>" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "<group_folder>/<receiver_file>" should exist
And as "Carol" file "/Shares/<group_folder>/<receiver_file>" should exist
And as "Alice" file "<group-folder>/<receiver_file>" should exist
And as "Carol" file "/Shares/<group-folder>/<receiver_file>" should exist
Examples:
| sharer_folder | group_folder | receiver_file |
| sharer-folder | group-folder | receiver_file |
| ?abc=oc # | ?abc=oc g%rp# | # oc?test=oc&a |
| @a#8a=b?c=d | @a#8a=b?c=d grp | ?a#8 a=b?c=d |

24
tests/acceptance/features/coreApiShareOperationsToShares1/accessToShare.feature
View File

@@ -13,58 +13,58 @@ Feature: sharing
@smokeTest
Scenario Outline: sharee can see the share
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
When user "Brian" gets all the shares shared with him using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the last share_id should be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@smokeTest
Scenario Outline: sharee can see the filtered share
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file with content "some data" to "/textfile1.txt"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
And user "Alice" has shared file "textfile1.txt" with user "Brian"
When user "Brian" gets all the shares shared with him that are received as file "/Shares/textfile1.txt" using the provisioning API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the last share_id should be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@smokeTest @issue-1257
Scenario Outline: sharee can't see the share that is filtered out
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file with content "some data" to "/textfile1.txt"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
And user "Alice" has shared file "textfile1.txt" with user "Brian"
When user "Brian" gets all the shares shared with him that are received as file "/Shares/textfile0.txt" using the provisioning API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the last share id should not be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@smokeTest @issue-1289
Scenario Outline: sharee can see the group share
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has shared file "textfile0.txt" with group "grp1"
When user "Brian" gets all the shares shared with him using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the last share_id should be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |

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

@@ -12,35 +12,35 @@ Feature: sharing
@smokeTest @issue-1258
Scenario Outline: getting all shares from a user
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file with content "some data" to "/file_to_share.txt"
And user "Alice" has shared file "file_to_share.txt" with user "Brian"
When user "Alice" gets all shares shared by her using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And file "/Shares/file_to_share.txt" should be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@issue-1319
Scenario Outline: getting all shares of a user using another user
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file with content "some data" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
When the administrator gets all shares shared by him using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And file "/Shares/textfile0.txt" should not be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@smokeTest
Scenario Outline: getting all shares of a file
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And these users have been created with default attributes and without skeleton files:
| username |
| Carol |
@@ -49,19 +49,19 @@ Feature: sharing
And user "Alice" has shared file "textfile0.txt" with user "Brian"
And user "Alice" has shared file "textfile0.txt" with user "Carol"
When user "Alice" gets all the shares of the file "textfile0.txt" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And user "Brian" should be included in the response
And user "Carol" should be included in the response
And user "David" should not be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@smokeTest
Scenario Outline: getting all shares of a file with reshares
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And these users have been created with default attributes and without skeleton files:
| username |
| Carol |
@@ -70,19 +70,19 @@ Feature: sharing
And user "Alice" has shared file "textfile0.txt" with user "Brian"
And user "Brian" has shared file "/Shares/textfile0.txt" with user "Carol"
When user "Alice" gets all the shares with reshares of the file "textfile0.txt" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And user "Brian" should be included in the response
And user "Carol" should be included in the response
And user "David" should not be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@smokeTest
Scenario Outline: resource can be reshared to resource owner
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And group "grp1" has been created
And user "Carol" has been created with default attributes and without skeleton files
And user "Carol" has been added to group "grp1"
@@ -92,21 +92,21 @@ Feature: sharing
And user "Brian" has shared folder "/Shares/shared" with group "grp1"
# no need to accept this share as it is Carol's file
When user "Carol" gets all the shares shared with her using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And file "/Shares/shared" should be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@smokeTest @issue-1226 @issue-1270 @issue-1271
Scenario Outline: getting share info of a share
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file with content "some data" to "/file_to_share.txt"
And user "Alice" has shared file "file_to_share.txt" with user "Brian"
When user "Alice" gets the info of the last share using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" sharing with user "Brian" should include
| id | A_STRING |
@@ -126,13 +126,13 @@ Feature: sharing
| displayname_owner | %displayname% |
| mimetype | text/plain |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@issue-1233
Scenario Outline: get a share with a user that didn't receive the share
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Carol" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "some data" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
@@ -140,7 +140,7 @@ Feature: sharing
Then the OCS status code should be "404"
And the HTTP status code should be "<http_status_code>"
Examples:
| ocs_api_version | http_status_code |
| ocs-api-version | http_status_code |
| 1 | 200 |
| 2 | 404 |
@@ -165,12 +165,12 @@ Feature: sharing
@smokeTest @issue-1226 @issue-1270 @issue-1271 @issue-1231
Scenario Outline: getting share info of a share shared from inside folder
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/PARENT"
And user "Alice" has uploaded file with content "some data" to "/PARENT/file_to_share.txt"
And user "Alice" has shared file "/PARENT/file_to_share.txt" with user "Brian"
When user "Alice" gets all shares shared by her using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" sharing with user "Brian" should include
| id | A_STRING |
@@ -190,6 +190,6 @@ Feature: sharing
| displayname_owner | %displayname% |
| mimetype | text/plain |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |

12
tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesPendingFiltered.feature
View File

@@ -35,26 +35,26 @@ Feature: get the pending shares filtered by type (user, group etc)
Scenario Outline: getting pending shares received from users
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
When user "Brian" gets the pending user shares shared with him using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And exactly 1 file or folder should be included in the response
And folder "/Shares/folderToShareWithUser" should be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: getting pending shares received from groups
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
When user "Brian" gets the pending group shares shared with him using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And exactly 1 file or folder should be included in the response
And folder "/Shares/folderToShareWithGroup" should be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |

12
tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesReceivedFiltered.feature
View File

@@ -32,28 +32,28 @@ Feature: get the received shares filtered by type (user, group etc)
Scenario Outline: getting shares received from users
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
When user "Brian" gets the user shares shared with him using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And exactly 2 files or folders should be included in the response
And folder "/Shares/folderToShareWithUser" should be included in the response
And file "/Shares/fileToShareWithUser.txt" should be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: getting shares received from groups
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
When user "Brian" gets the group shares shared with him using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And exactly 2 files or folders should be included in the response
And folder "/Shares/folderToShareWithGroup" should be included in the response
And folder "/Shares/fileToShareWithGroup.txt" should be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |

18
tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesReceivedFilteredEmpty.feature
View File

@@ -20,7 +20,7 @@ Feature: get the received shares filtered by type (user, group etc)
Scenario Outline: getting shares received from users when there are none
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/folderToShareWithGroup" with group "grp1"
And user "Alice" has created a public link share with settings
| path | /folderToShareWithPublic |
@@ -32,17 +32,17 @@ Feature: get the received shares filtered by type (user, group etc)
| permissions | read |
| password | %public% |
When user "Brian" gets the user shares shared with him using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And no files or folders should be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: getting shares received from groups when there are none
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/folderToShareWithUser" with user "Brian"
And user "Alice" has created a public link share with settings
| path | /folderToShareWithPublic |
@@ -54,11 +54,11 @@ Feature: get the received shares filtered by type (user, group etc)
| permissions | read |
| password | %public% |
When user "Brian" gets the group shares shared with him using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And no files or folders should be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@@ -67,7 +67,7 @@ Feature: get the received shares filtered by type (user, group etc)
# Note: public links are purposely created in this scenario
# users do not receive public links, so asking for a list of public links
# that are "shared with me" should always return an empty list.
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/folderToShareWithUser" with user "Brian"
And user "Alice" has shared folder "/folderToShareWithGroup" with group "grp1"
And user "Alice" has created a public link share with settings
@@ -81,10 +81,10 @@ Feature: get the received shares filtered by type (user, group etc)
| permissions | read |
| password | %public% |
When user "Brian" gets the public link shares shared with him using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And no files or folders should be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |

24
tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesSharedFiltered.feature
View File

@@ -32,51 +32,51 @@ Feature: get shares filtered by type (user, group etc)
Scenario Outline: getting shares shared to users
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
When user "Alice" gets the user shares shared by her using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And exactly 2 files or folders should be included in the response
And folder "/Shares/folderToShareWithUser" should be included in the response
And file "/Shares/fileToShareWithUser.txt" should be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: getting shares shared to groups
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
When user "Alice" gets the group shares shared by her using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And exactly 2 files or folders should be included in the response
And folder "/Shares/folderToShareWithGroup" should be included in the response
And folder "/Shares/fileToShareWithGroup.txt" should be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: getting shares shared to public links
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
When user "Alice" gets the public link shares shared by her using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And exactly 2 files or folders should be included in the response
And folder "/folderToShareWithPublic" should be included in the response
And folder "/fileToShareWithPublic.txt" should be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: getting shares shared to users and groups
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
When user "Alice" gets the user and group shares shared by her using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And exactly 4 files or folders should be included in the response
And folder "/Shares/folderToShareWithUser" should be included in the response
@@ -84,6 +84,6 @@ Feature: get shares filtered by type (user, group etc)
And folder "/Shares/folderToShareWithGroup" should be included in the response
And folder "/Shares/fileToShareWithGroup.txt" should be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |

18
tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesSharedFilteredEmpty.feature
View File

@@ -20,7 +20,7 @@ Feature: get shares filtered by type (user, group etc)
Scenario Outline: getting shares shared to users when there are none
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/folderToShareWithGroup" with group "grp1"
And user "Alice" has created a public link share with settings
| path | /folderToShareWithPublic |
@@ -32,17 +32,17 @@ Feature: get shares filtered by type (user, group etc)
| permissions | read |
| password | %public% |
When user "Alice" gets the user shares shared by her using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And no files or folders should be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: getting shares shared to groups when there are none
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/folderToShareWithUser" with user "Brian"
And user "Alice" has created a public link share with settings
| path | /folderToShareWithPublic |
@@ -54,26 +54,26 @@ Feature: get shares filtered by type (user, group etc)
| permissions | read |
| password | %public% |
When user "Alice" gets the group shares shared by her using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And no files or folders should be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: getting shares shared to public links when there are none
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/folderToShareWithUser" with user "Brian"
And user "Alice" has shared folder "/folderToShareWithGroup" with group "grp1"
And user "Alice" has shared file "/fileToShareWithUser.txt" with user "Brian"
And user "Alice" has shared file "/fileToShareWithGroup.txt" with group "grp1"
When user "Alice" gets the public link shares shared by her using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And no files or folders should be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |

62
tests/acceptance/features/coreApiShareOperationsToShares2/shareAccessByID.feature
View File

@@ -12,11 +12,11 @@ Feature: share access by ID
Scenario Outline: get a share with a valid share ID
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API
And user "Alice" gets share with id "%last_share_id%" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
And user "Alice" gets share with id "%last_share-id%" using the sharing API
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" sharing with user "Brian" should include
| share_with | %username% |
@@ -32,19 +32,19 @@ Feature: share access by ID
| share_type | user |
And the content of file "/Shares/textfile0.txt" for user "Brian" should be "ownCloud test text file 0"
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: get a share with an invalid share id
Given using OCS API version "<ocs_api_version>"
When user "Alice" gets share with id "<share_id>" using the sharing API
Given using OCS API version "<ocs-api-version>"
When user "Alice" gets share with id "<share-id>" using the sharing API
Then the OCS status code should be "404"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
And the API should not return any data
Examples:
| ocs_api_version | share_id | http_status_code |
| ocs-api-version | share-id | http-status-code |
| 1 | 2333311 | 200 |
| 2 | 2333311 | 404 |
| 1 | helloshare | 200 |
@@ -56,10 +56,10 @@ Feature: share access by ID
Scenario Outline: accept a share using the share Id
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And user "Brian" should see the following elements
| /Shares/textfile0.txt |
@@ -67,18 +67,19 @@ Feature: share access by ID
| path |
| /Shares/textfile0.txt |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: accept a share using the invalid share Id
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
When user "Brian" accepts share with ID "<share-id>" using the sharing API
Then the OCS status code should be "404"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
And the API should not return any data
Examples:
| ocs_api_version | share_id | http_status_code |
| ocs-api-version | share-id | http-status-code |
| 1 | 2333311 | 200 |
| 2 | 2333311 | 404 |
| 1 | helloshare | 200 |
@@ -90,22 +91,23 @@ Feature: share access by ID
Scenario Outline: accept a share using empty share Id
Given using OCS API version "<ocs_api_version>"
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "<http_status_code>"
Given using OCS API version "<ocs-api-version>"
When user "Brian" accepts share with ID "" using the sharing API
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "<http-status-code>"
And the API should not return any data
Examples:
| ocs_api_version | http_status_code | ocs_status_code |
| ocs-api-version | http-status-code | ocs-status-code |
| 1 | 200 | 999 |
| 2 | 500 | 500 |
Scenario Outline: decline a share using the share Id
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
When user "Brian" declines share with ID "%last_share_id%" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
When user "Brian" declines share with ID "%last_share-id%" 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 not see the following elements
| /Shares/textfile0.txt |
@@ -113,19 +115,19 @@ Feature: share access by ID
| path |
| /Shares/textfile0.txt |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: decline a share using a invalid share Id
Given using OCS API version "<ocs_api_version>"
When user "Brian" declines share with ID "<share_id>" using the sharing API
Given using OCS API version "<ocs-api-version>"
When user "Brian" declines share with ID "<share-id>" using the sharing API
Then the OCS status code should be "404"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
And the API should not return any data
Examples:
| ocs_api_version | share_id | http_status_code |
| ocs-api-version | share-id | http-status-code |
| 1 | 2333311 | 200 |
| 2 | 2333311 | 404 |
| 1 | helloshare | 200 |
@@ -137,12 +139,12 @@ Feature: share access by ID
Scenario Outline: decline a share using empty share Id
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
When user "Brian" declines share with ID "" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "<http_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "<http-status-code>"
And the API should not return any data
Examples:
| ocs_api_version | http_status_code | ocs_status_code |
| ocs-api-version | http-status-code | ocs-status-code |
| 1 | 200 | 999 |
| 2 | 500 | 500 |

30
tests/acceptance/features/coreApiSharePublicLink1/changingPublicLinkShare.feature
View File

@@ -134,7 +134,7 @@ Feature: changing a public link share
@skipOnReva
Scenario Outline: normal user tries to remove password of a public link share (change/create permission)
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created a public link share with settings
| path | /PARENT |
| permissions | <permissions> |
@@ -143,11 +143,11 @@ Feature: changing a public link share
| path | /PARENT |
| permissions | <permissions> |
| password | |
Then the HTTP status code should be "<http_status_code>"
Then the HTTP status code should be "<http-status-code>"
And the OCS status code should be "400"
And the OCS status message should be "missing required password"
Examples:
| ocs_api_version | permissions | http_status_code |
| ocs-api-version | permissions | http-status-code |
| 1 | change | 200 |
| 2 | change | 400 |
| 1 | create | 200 |
@@ -155,7 +155,7 @@ Feature: changing a public link share
@issue-7821 @skipOnReva
Scenario Outline: normal user tries to remove password of a public link (update without sending permissions)
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created a public link share with settings
| path | /PARENT |
| permissions | change |
@@ -163,17 +163,17 @@ Feature: changing a public link share
When user "Alice" updates the last public link share using the sharing API with
| path | /PARENT |
| password | |
Then the HTTP status code should be "<http_status_code>"
Then the HTTP status code should be "<http-status-code>"
And the OCS status code should be "104"
And the OCS status message should be "user is not allowed to delete the password from the public link"
Examples:
| ocs_api_version | http_status_code |
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
Scenario Outline: normal user removes password of a public link (invite only public link)
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt"
And user "Alice" has created a public link share with settings
| path | /PARENT |
@@ -184,16 +184,16 @@ Feature: changing a public link share
| password | |
| permissions | invite |
Then the HTTP status code should be "200"
And the OCS status code should be "<ocs_status_code>"
And the OCS status code should be "<ocs-status-code>"
And the OCS status message should be "OK"
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@skipOnReva # reva doesn't have a pre-created admin user
Scenario Outline: administrator removes password of a read-only public link
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And admin has created folder "/PARENT"
And user "admin" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt"
And user "admin" has created a public link share with settings
@@ -205,16 +205,16 @@ Feature: changing a public link share
| permissions | read |
| password | |
Then the HTTP status code should be "200"
And the OCS status code should be "<ocs_status_code>"
And the OCS status code should be "<ocs-status-code>"
And the public should be able to download file "/parent.txt" from inside the last public link shared folder using the new public WebDAV API with password ""
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@skipOnReva # reva doesn't have a pre-created admin user
Scenario Outline: administrator tries to remove password of a public link share (change/create permission)
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And admin has created folder "/PARENT"
And user "admin" has created a public link share with settings
| path | /PARENT |
@@ -224,11 +224,11 @@ Feature: changing a public link share
| path | /PARENT |
| permissions | <permissions> |
| password | |
Then the HTTP status code should be "<http_status_code>"
Then the HTTP status code should be "<http-status-code>"
And the OCS status code should be "400"
And the OCS status message should be "missing required password"
Examples:
| ocs_api_version | permissions | http_status_code |
| ocs-api-version | permissions | http-status-code |
| 1 | change | 200 |
| 2 | change | 400 |
| 1 | create | 200 |

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

@@ -10,30 +10,30 @@ Feature: create a public link share
@smokeTest @skipOnReva
Scenario Outline: creating public link share of a file or a folder using the default permissions without password using the public WebDAV API
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt"
And user "Alice" has created folder "/PARENT"
When user "Alice" creates a public link share using the sharing API with settings
| path | randomfile.txt |
Then the OCS status code should be "400"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
When user "Alice" creates a public link share using the sharing API with settings
| path | PARENT |
Then the OCS status code should be "400"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
Examples:
| ocs_api_version | http_status_code |
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 400 |
@smokeTest
Scenario Outline: creating a new public link share of a file with password using the new public WebDAV API
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt"
When user "Alice" creates a public link share using the sharing API with settings
| path | randomfile.txt |
| password | %public% |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" should include
| item_type | file |
@@ -55,19 +55,19 @@ Feature: create a public link share
Then the HTTP status code should be "401"
And the value of the item "//s:message" in the response should match "/No 'Authorization: Basic' header found/"
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: create a new public link share of a file with edit permissions
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt"
When user "Alice" creates a public link share using the sharing API with settings
| path | randomfile.txt |
| permissions | read,update,create,delete |
| password | %public% |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" should include
| item_type | file |
@@ -84,20 +84,20 @@ Feature: create a public link share
And the public should be able to download the last publicly shared file using the new public WebDAV API with password "%public%" and the content should be "Random data"
And uploading content to a public link shared file with password "%public%" should work using the new public WebDAV API
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: creating a new public link share of a folder, with a password and accessing using the public WebDAV API
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/PARENT"
And user "Alice" has uploaded file with content "Random data" to "/PARENT/randomfile.txt"
When user "Alice" creates a public link share using the sharing API with settings
| path | PARENT |
| password | %public% |
| permissions | change |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" should include
| item_type | folder |
@@ -118,18 +118,18 @@ Feature: create a public link share
And the public should not be able to download file "/randomfile.txt" from inside the last public link shared folder using the new public WebDAV API without a password
And the public should not be able to download file "/randomfile.txt" from inside the last public link shared folder using the new public WebDAV API with password "%regular%"
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@smokeTest
Scenario Outline: getting the share information of public link share from the OCS API does not expose sensitive information
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt"
When user "Alice" creates a public link share using the sharing API with settings
| path | randomfile.txt |
| password | %public% |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" should include
| file_target | /randomfile.txt |
@@ -141,18 +141,18 @@ Feature: create a public link share
| share_with | ***redacted*** |
| share_with_displayname | ***redacted*** |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@env-config
Scenario Outline: getting the share information of password less public-links hides credential placeholders
Given the config "OCIS_SHARING_PUBLIC_SHARE_MUST_HAVE_PASSWORD" has been set to "false"
And using OCS API version "<ocs_api_version>"
And using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt"
When user "Alice" creates a public link share using the sharing API with settings
| path | randomfile.txt |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" should include
| file_target | /randomfile.txt |
@@ -165,18 +165,18 @@ Feature: create a public link share
| share_with | ANY_VALUE |
| share_with_displayname | ANY_VALUE |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: creating a link share with no specified permissions defaults to read permissions when public upload is disabled globally and accessing using the public WebDAV API
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/afolder"
When user "Alice" creates a public link share using the sharing API with settings
| path | /afolder |
| password | %public% |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" should include
| id | A_STRING |
@@ -185,19 +185,19 @@ Feature: create a public link share
And the public upload to the last publicly shared folder using the old public WebDAV API with password "%public%" should fail with HTTP status code "403"
And the public upload to the last publicly shared folder using the old public WebDAV API with password "%public%" should fail with HTTP status code "403"
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: creating a link share with edit permissions keeps it using the public WebDAV API
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/afolder"
When user "Alice" creates a public link share using the sharing API with settings
| path | /afolder |
| permissions | read,update,create,delete |
| password | %public% |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" should include
| id | A_STRING |
@@ -205,19 +205,19 @@ Feature: create a public link share
| permissions | read,update,create,delete |
And uploading a file with password "%public%" should work using the new public WebDAV API
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: creating a link share with upload permissions keeps it using the public WebDAV API
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/afolder"
When user "Alice" creates a public link share using the sharing API with settings
| path | /afolder |
| permissions | read,create |
| password | %public% |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" should include
| id | A_STRING |
@@ -225,51 +225,51 @@ Feature: create a public link share
| permissions | read,create |
And uploading a file with password "%public%" should work using the new public WebDAV API
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: Do not allow public sharing of the root on OCIS when the default permission is read and access using the public WebDAV API
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
When user "Alice" creates a public link share using the sharing API with settings
| path | / |
| password | %public% |
Then the OCS status code should be "400"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
Examples:
| ocs_api_version | http_status_code |
| 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
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file with content "long file" to "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt"
When user "Alice" creates a public link share using the sharing API with settings
| path | /aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt |
| password | %public% |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the public should be able to download the last publicly shared file using the new public WebDAV API with password "%public%" and the content should be "long file"
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: user creates a public link share of a folder with folder name longer than 64 chars and access using the public WebDAV API
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog"
And user "Alice" has uploaded file with content "Random data" to "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog/randomfile.txt"
When user "Alice" creates a public link share using the sharing API with settings
| path | /aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog |
| password | %public% |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the public should be able to download file "/randomfile.txt" from inside the last public link shared folder using the old public WebDAV API with password "%public%" and the content should be "Random data"
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@@ -394,9 +394,9 @@ Feature: create a public link share
When user "Alice" updates the last public link share using the sharing API with
| password | Test:123345 |
Then the OCS status code should be "998"
And the HTTP status code should be "<http-code>"
And the HTTP status code should be "<http-status-code>"
And the OCS status message should be "update public share: resource not found"
Examples:
| ocs-api-version | http-code |
| 1 | 200 |
| 2 | 404 |
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 404 |

6
tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShareToShares.feature
View File

@@ -8,12 +8,12 @@ Feature: create a public link share when share_folder is set to Shares
Scenario Outline: creating a new public link share of a file gives the correct response
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt"
When user "Alice" creates a public link share using the sharing API with settings
| path | randomfile.txt |
| password | %public% |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" should include
| item_type | file |
@@ -28,6 +28,6 @@ Feature: create a public link share when share_folder is set to Shares
| uid_owner | %username% |
| name | |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |

24
tests/acceptance/features/coreApiSharePublicLink1/deletePublicLinkShare.feature
View File

@@ -8,7 +8,7 @@ Feature: delete a public link share
@issue-1275
Scenario Outline: deleting a public link of a file
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file with content "This is a test file" to "test-file.txt"
And user "Alice" has created a public link share with settings
| path | test-file.txt |
@@ -16,16 +16,16 @@ Feature: delete a public link share
| password | %public% |
When user "Alice" deletes public link share named "sharedlink" in file "test-file.txt" using the sharing API
Then the HTTP status code should be "200"
And the OCS status code should be "<ocs_status_code>"
And the OCS status code should be "<ocs-status-code>"
And as user "Alice" the file "test-file.txt" should not have any shares
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@issue-1275
Scenario Outline: deleting a public link after renaming a file
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file with content "This is a test file" to "test-file.txt"
And user "Alice" has created a public link share with settings
| path | test-file.txt |
@@ -33,17 +33,17 @@ Feature: delete a public link share
| password | %public% |
When user "Alice" moves file "/test-file.txt" to "/renamed-test-file.txt" using the WebDAV API
And user "Alice" deletes public link share named "sharedlink" in file "renamed-test-file.txt" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as user "Alice" the file "renamed-test-file.txt" should not have any shares
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@issue-1275
Scenario Outline: deleting a public link of a folder
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "test-folder"
And user "Alice" has created a public link share with settings
| path | /test-folder |
@@ -51,16 +51,16 @@ Feature: delete a public link share
| password | %public% |
When user "Alice" deletes public link share named "sharedlink" in folder "test-folder" using the sharing API
Then the HTTP status code should be "200"
And the OCS status code should be "<ocs_status_code>"
And the OCS status code should be "<ocs-status-code>"
And as user "Alice" the folder "test-folder" should not have any shares
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@issue-1275
Scenario Outline: deleting a public link of a file in a folder
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "test-folder"
When user "Alice" uploads file "filesForUpload/textfile.txt" to "/test-folder/testfile.txt" using the WebDAV API
And user "Alice" has created a public link share with settings
@@ -69,10 +69,10 @@ Feature: delete a public link share
| password | %public% |
And user "Alice" deletes public link share named "sharedlink" in file "/test-folder/testfile.txt" using the sharing API
Then the HTTP status code should be "200"
And the OCS status code should be "<ocs_status_code>"
And the OCS status code should be "<ocs-status-code>"
And as user "Alice" the file "/test-folder/testfile.txt" should not have any shares
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |

24
tests/acceptance/features/coreApiSharePublicLink2/multilinkSharing.feature
View File

@@ -8,7 +8,7 @@ Feature: multi-link sharing
@smokeTest
Scenario Outline: creating three public shares of a folder
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "FOLDER"
And user "Alice" has created a public link share with settings
| path | FOLDER |
@@ -33,7 +33,7 @@ Feature: multi-link sharing
| name | sharedlink3 |
When user "Alice" updates the last public link share using the sharing API with
| permissions | read |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as user "Alice" the public shares of folder "/FOLDER" should be
| path | permissions | name |
@@ -41,13 +41,13 @@ Feature: multi-link sharing
| /FOLDER | 15 | sharedlink1 |
| /FOLDER | 1 | sharedlink3 |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: creating three public shares of a file
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And user "Alice" has created a public link share with settings
| path | textfile0.txt |
@@ -69,7 +69,7 @@ Feature: multi-link sharing
| name | sharedlink3 |
When user "Alice" updates the last public link share using the sharing API with
| permissions | read |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as user "Alice" the public shares of file "/textfile0.txt" should be
| path | permissions | name |
@@ -77,13 +77,13 @@ Feature: multi-link sharing
| /textfile0.txt | 1 | sharedlink1 |
| /textfile0.txt | 1 | sharedlink3 |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: check that updating password doesn't remove name of links
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "FOLDER"
And user "Alice" has created a public link share with settings
| path | FOLDER |
@@ -101,14 +101,14 @@ Feature: multi-link sharing
| name | sharedlink2 |
When user "Alice" updates the last public link share using the sharing API with
| password | New-StronPass1 |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as user "Alice" the public shares of folder "/FOLDER" should be
| path | permissions | name |
| /FOLDER | 15 | sharedlink2 |
| /FOLDER | 15 | sharedlink1 |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@@ -145,7 +145,7 @@ Feature: multi-link sharing
Scenario Outline: deleting one public link share of a file doesn't affect the rest
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And user "Alice" has created a public link share with settings
| path | textfile0.txt |
@@ -166,14 +166,14 @@ Feature: multi-link sharing
| permissions | read |
| name | sharedlink3 |
When user "Alice" deletes public link share named "sharedlink2" in file "/textfile0.txt" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as user "Alice" the public shares of file "/textfile0.txt" should be
| path | permissions | name |
| /textfile0.txt | 1 | sharedlink1 |
| /textfile0.txt | 1 | sharedlink3 |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |

54
tests/acceptance/features/coreApiSharePublicLink2/reShareAsPublicLinkToSharesNewDav.feature
View File

@@ -11,7 +11,7 @@ Feature: reshare as public link
@skipOnReva
Scenario Outline: creating a public link from a share with read permission only is not allowed
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/test"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "read"
When user "Brian" creates a public link share using the sharing API with settings
@@ -19,15 +19,15 @@ Feature: reshare as public link
| publicUpload | false |
| password | %public% |
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
Examples:
| ocs_api_version | http_status_code |
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
@skipOnReva
Scenario Outline: creating a public link from a share with share+read only permissions is allowed
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/test"
And user "Alice" has uploaded file with content "some content" to "/test/file.txt"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read"
@@ -35,20 +35,20 @@ Feature: reshare as public link
| path | /Shares/test |
| publicUpload | false |
| password | %public% |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
When the public downloads file "file.txt" from inside the last public link shared folder with password "%public%" using the new public WebDAV API
Then the HTTP status code should be "200"
And the downloaded content should be "some content"
But uploading a file should not work using the new public WebDAV API
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@skipOnReva
Scenario Outline: creating an upload public link from a share with share+read only permissions is not allowed
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/test"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read"
When user "Brian" creates a public link share using the sharing API with settings
@@ -57,15 +57,15 @@ Feature: reshare as public link
| publicUpload | true |
| password | %public% |
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
Examples:
| ocs_api_version | http_status_code |
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
@skipOnReva
Scenario Outline: creating a public link from a share with read+write permissions only is not allowed
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/test"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "change"
When user "Brian" creates a public link share using the sharing API with settings
@@ -73,15 +73,15 @@ Feature: reshare as public link
| publicUpload | true |
| password | %public% |
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
Examples:
| ocs_api_version | http_status_code |
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
@skipOnReva
Scenario Outline: creating a public link from a share with share+read+write permissions is allowed
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/test"
And user "Alice" has uploaded file with content "some content" to "/test/file.txt"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "all"
@@ -89,20 +89,20 @@ Feature: reshare as public link
| path | /Shares/test |
| publicUpload | false |
| password | %public% |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
When the public downloads file "file.txt" from inside the last public link shared folder with password "%public%" using the new public WebDAV API
Then the HTTP status code should be "200"
And the downloaded content should be "some content"
But uploading a file should not work using the new public WebDAV API
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@skipOnReva
Scenario Outline: creating an upload public link from a share with share+read+write permissions is allowed
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/test"
And user "Alice" has uploaded file with content "some content" to "/test/file.txt"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "all"
@@ -111,20 +111,20 @@ Feature: reshare as public link
| permissions | read,update,create,delete |
| publicUpload | true |
| password | %public% |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
When the public downloads file "file.txt" from inside the last public link shared folder with password "%public%" using the new public WebDAV API
Then the HTTP status code should be "200"
And the downloaded content should be "some content"
And uploading a file with password "%public%" should work using the new public WebDAV API
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@skipOnReva
Scenario Outline: creating an upload public link from a sub-folder of a share with share+read only permissions is not allowed
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/test"
And user "Alice" has created folder "/test/sub"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read"
@@ -134,15 +134,15 @@ Feature: reshare as public link
| publicUpload | true |
| password | %public% |
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
Examples:
| ocs_api_version | http_status_code |
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
@skipOnReva
Scenario Outline: increasing permissions of a public link of a share with share+read only permissions is not allowed
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/test"
And user "Alice" has created folder "/test/sub"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read"
@@ -154,16 +154,16 @@ Feature: reshare as public link
When user "Brian" updates the last public link share using the sharing API with
| permissions | read,update,create,delete |
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
And uploading a file should not work using the new public WebDAV API
Examples:
| ocs_api_version | http_status_code |
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
@skipOnReva
Scenario Outline: increasing permissions of a public link from a sub-folder of a share with share+read only permissions is not allowed
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/test"
And user "Alice" has created folder "/test/sub"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read"
@@ -176,9 +176,9 @@ Feature: reshare as public link
When user "Brian" updates the last public link share using the sharing API with
| permissions | read,update,create,delete |
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
And uploading a file should not work using the new public WebDAV API
Examples:
| ocs_api_version | http_status_code |
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |

98
tests/acceptance/features/coreApiSharePublicLink2/updatePublicLinkShare.feature
View File

@@ -9,14 +9,14 @@ Feature: update a public link share
Scenario Outline: change expiration date of a public link share and get its info
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "FOLDER"
And user "Alice" has created a public link share with settings
| path | FOLDER |
| password | %public% |
When user "Alice" updates the last public link share using the sharing API with
| expireDate | 2040-01-01T23:59:59+0100 |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the OCS status message should be "OK"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" should include
@@ -44,13 +44,13 @@ Feature: update a public link share
| mail_send | 0 |
| name | |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@smokeTest
Scenario Outline: change expiration date of a newly created public link share and get its info
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "FOLDER"
And user "Alice" has created a public link share with settings
| path | FOLDER |
@@ -58,7 +58,7 @@ Feature: update a public link share
And user "Alice" has updated the last public link share with
| expireDate | 2033-01-31T23:59:59+0100 |
When user "Alice" gets the info of the last public link share using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" should include
| id | A_STRING |
@@ -78,31 +78,31 @@ Feature: update a public link share
| url | AN_URL |
| mimetype | httpd/unix-directory |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: creating a new public link share with password and adding an expiration date using public API
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt"
And user "Alice" has created a public link share with settings
| path | randomfile.txt |
| password | %public% |
When user "Alice" updates the last public link share using the sharing API with
| expireDate | 2040-01-01T23:59:59+0100 |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the public should be able to download the last publicly shared file using the old public WebDAV API with password "%public%" and the content should be "Random data"
And the public should be able to download the last publicly shared file using the new public WebDAV API with password "%public%" and the content should be "Random data"
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: creating a new public link share, updating its password and getting its info
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "FOLDER"
And user "Alice" has created a public link share with settings
| path | FOLDER |
@@ -110,7 +110,7 @@ Feature: update a public link share
And user "Alice" has updated the last public link share with
| password | %public% |
When user "Alice" gets the info of the last public link share using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" should include
| id | A_STRING |
@@ -129,13 +129,13 @@ Feature: update a public link share
| url | AN_URL |
| mimetype | httpd/unix-directory |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: creating a new public link share, updating its permissions and getting its info
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "FOLDER"
And user "Alice" has created a public link share with settings
| path | FOLDER |
@@ -143,7 +143,7 @@ Feature: update a public link share
And user "Alice" has updated the last public link share with
| permissions | read,update,create,delete |
When user "Alice" gets the info of the last public link share using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" should include
| id | A_STRING |
@@ -162,13 +162,13 @@ Feature: update a public link share
| url | AN_URL |
| mimetype | httpd/unix-directory |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: creating a new public link share, updating its permissions to view download and upload and getting its info
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "FOLDER"
And user "Alice" has created a public link share with settings
| path | FOLDER |
@@ -176,7 +176,7 @@ Feature: update a public link share
And user "Alice" has updated the last public link share with
| permissions | read,update,create,delete |
When user "Alice" gets the info of the last public link share using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" should include
| id | A_STRING |
@@ -195,13 +195,13 @@ Feature: update a public link share
| url | AN_URL |
| mimetype | httpd/unix-directory |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: creating a new public link share, updating publicUpload option and getting its info
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "FOLDER"
And user "Alice" has created a public link share with settings
| path | FOLDER |
@@ -209,7 +209,7 @@ Feature: update a public link share
And user "Alice" has updated the last public link share with
| publicUpload | true |
When user "Alice" gets the info of the last public link share using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" should include
| id | A_STRING |
@@ -228,13 +228,13 @@ Feature: update a public link share
| url | AN_URL |
| mimetype | httpd/unix-directory |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@skipOnReva
Scenario Outline: adding public upload to a read only shared folder as recipient is not allowed using the public API
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "/test"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read"
@@ -245,17 +245,17 @@ Feature: update a public link share
When user "Brian" updates the last public link share using the sharing API with
| publicUpload | true |
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
And uploading a file should not work using the old public WebDAV API
And uploading a file should not work using the new public WebDAV API
Examples:
| ocs_api_version | http_status_code |
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
@skipOnReva
Scenario Outline:adding public upload to a shared folder as recipient is allowed with permissions using the public API
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "/test"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "all"
@@ -265,18 +265,18 @@ Feature: update a public link share
| password | %public% |
When user "Brian" updates the last public link share using the sharing API with
| publicUpload | true |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And uploading a file with password "%public%" should work using the old public WebDAV API
And uploading a file with password "%public%" should work using the new public WebDAV API
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@skipOnReva
Scenario Outline: adding public link with all permissions to a read only shared folder as recipient is not allowed using the public API
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "/test"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read"
@@ -287,17 +287,17 @@ Feature: update a public link share
When user "Brian" updates the last public link share using the sharing API with
| permissions | read,update,create,delete |
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
And uploading a file should not work using the old public WebDAV API
And uploading a file should not work using the new public WebDAV API
Examples:
| ocs_api_version | http_status_code |
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
@skipOnReva
Scenario Outline: adding public link with all permissions to a read only shared folder as recipient is allowed with permissions using the public API
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "/test"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "all"
@@ -307,17 +307,17 @@ Feature: update a public link share
| password | %public% |
When user "Brian" updates the last public link share using the sharing API with
| permissions | read,update,create,delete |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And uploading a file with password "%public%" should work using the new public WebDAV API
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 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>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "PARENT"
And user "Alice" has created folder "PARENT/CHILD"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/PARENT/CHILD/child.txt"
@@ -331,13 +331,13 @@ Feature: update a public link share
And the HTTP status code of responses on all endpoints should be "403"
And as "Alice" file "PARENT/CHILD/child.txt" should exist
Examples:
| ocs_api_version |
| ocs-api-version |
| 1 |
| 2 |
Scenario Outline: updating share permissions from read to change allows public to delete files using the public API
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "PARENT"
And user "Alice" has created folder "PARENT/CHILD"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/PARENT/parent.txt"
@@ -354,13 +354,13 @@ Feature: update a public link share
And as "Alice" file "PARENT/CHILD/child.txt" should not exist
And as "Alice" file "PARENT/parent.txt" should not exist
Examples:
| ocs_api_version |
| ocs-api-version |
| 1 |
| 2 |
Scenario Outline: rename a folder with public link and get its info
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And using <dav-path-version> DAV path
And user "Alice" has created folder "FOLDER"
And user "Alice" has created a public link share with settings
@@ -368,7 +368,7 @@ Feature: update a public link share
| password | %public% |
And user "Alice" has moved folder "/FOLDER" to "/RENAMED_FOLDER"
When user "Alice" gets the info of the last public link share using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" should include
| id | A_STRING |
@@ -393,7 +393,7 @@ Feature: update a public link share
| mail_send | 0 |
| name | |
Examples:
| dav-path-version | ocs_api_version | ocs_status_code |
| dav-path-version | ocs-api-version | ocs-status-code |
| old | 1 | 100 |
| old | 2 | 200 |
| new | 1 | 100 |
@@ -401,13 +401,13 @@ Feature: update a public link share
@skipOnRevaMaster
Examples:
| dav-path-version | ocs_api_version | ocs_status_code |
| dav-path-version | ocs-api-version | ocs-status-code |
| spaces | 1 | 100 |
| spaces | 2 | 200 |
Scenario Outline: rename a file with public link and get its info
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And using <dav-path-version> DAV path
And user "Alice" has uploaded file with content "some content" to "/lorem.txt"
And user "Alice" has created a public link share with settings
@@ -415,7 +415,7 @@ Feature: update a public link share
| password | %public% |
And user "Alice" has moved file "/lorem.txt" to "/new-lorem.txt"
When user "Alice" gets the info of the last public link share using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" should include
| id | A_STRING |
@@ -440,7 +440,7 @@ Feature: update a public link share
| mail_send | 0 |
| name | |
Examples:
| dav-path-version | ocs_api_version | ocs_status_code |
| dav-path-version | ocs-api-version | ocs-status-code |
| old | 1 | 100 |
| old | 2 | 200 |
| new | 1 | 100 |
@@ -448,13 +448,13 @@ Feature: update a public link share
@skipOnRevaMaster
Examples:
| dav-path-version | ocs_api_version | ocs_status_code |
| dav-path-version | ocs-api-version | ocs-status-code |
| spaces | 1 | 100 |
| spaces | 2 | 200 |
Scenario Outline: update the role of a public link to internal
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And using <dav-path-version> DAV path
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile.txt"
And user "Alice" has created a public link share with settings
@@ -463,10 +463,10 @@ Feature: update a public link share
| password | %public% |
When user "Alice" updates the last public link share using the sharing API with
| permissions | 0 |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
Examples:
| dav-path-version | ocs_api_version | ocs_status_code |
| dav-path-version | ocs-api-version | ocs-status-code |
| old | 1 | 100 |
| old | 2 | 200 |
| new | 1 | 100 |
@@ -474,6 +474,6 @@ Feature: update a public link share
@skipOnRevaMaster
Examples:
| dav-path-version | ocs_api_version | ocs_status_code |
| dav-path-version | ocs-api-version | ocs-status-code |
| spaces | 1 | 100 |
| spaces | 2 | 200 |

2
tests/acceptance/features/coreApiSharePublicLink2/uploadToPublicLinkShare.feature
View File

@@ -8,7 +8,7 @@ Feature: upload to a public link share
Background:
Given user "Alice" has been created with default attributes and without skeleton files
And user "Alice" has created folder "FOLDER"
Scenario Outline: uploading file to a public upload-only share using public API that was deleted does not work
Given using <dav-path-version> DAV path

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

@@ -13,105 +13,105 @@ Feature: sharing
@smokeTest @skipOnRevaMaster
Scenario Outline: user is not allowed to reshare file when reshare permission is not given
Given using OCS API version "<ocs_api_version>"
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 "read,update"
When user "Brian" shares file "/Shares/textfile0.txt" with user "Carol" with permissions "read,update" using the sharing API
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
And as "Carol" file "/Shares/textfile0.txt" should not exist
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 |
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
@skipOnRevaMaster
Scenario Outline: user is not allowed to reshare folder when reshare permission is not given
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "read,update"
When user "Brian" shares folder "/Shares/FOLDER" with user "Carol" with permissions "read,update" using the sharing API
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
And as "Carol" folder "/Shares/FOLDER" should not exist
And the sharing API should report to user "Carol" that no shares are in the pending state
But as "Brian" folder "/Shares/FOLDER" should exist
Examples:
| ocs_api_version | http_status_code |
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
@smokeTest
Scenario Outline: user is allowed to reshare file with the same permissions
Given using OCS API version "<ocs_api_version>"
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 "share,read"
When user "Brian" shares file "/Shares/textfile0.txt" with user "Carol" with permissions "share,read" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as "Carol" file "/Shares/textfile0.txt" should exist
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: user is allowed to reshare folder with the same permissions
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "share,read"
When user "Brian" shares folder "/Shares/FOLDER" with user "Carol" with permissions "share,read" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as "Carol" folder "/Shares/FOLDER" should exist
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: user is allowed to reshare file with less permissions
Given using OCS API version "<ocs_api_version>"
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 "share,update,read"
When user "Brian" shares file "/Shares/textfile0.txt" with user "Carol" with permissions "share,read" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as "Carol" file "/Shares/textfile0.txt" should exist
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: user is allowed to reshare folder with less permissions
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "share,update,read"
When user "Brian" shares folder "/Shares/FOLDER" with user "Carol" with permissions "share,read" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as "Carol" folder "/Shares/FOLDER" should exist
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@skipOnRevaMaster
Scenario Outline: user is not allowed to reshare file and set more permissions bits
Given using OCS API version "<ocs_api_version>"
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 17
When user "Brian" shares file "/Shares/textfile0.txt" with user "Carol" with permissions <reshare_permissions> using the sharing API
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 "403"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
And as "Carol" file "/Shares/textfile0.txt" should not exist
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 | reshare_permissions |
| ocs-api-version | http-status-code | reshare-permissions |
# passing on more bits including reshare
| 1 | 200 | 19 |
| 2 | 403 | 19 |
@@ -129,16 +129,16 @@ Feature: sharing
Scenario Outline: user is allowed to reshare file and set create (4) or delete (8) permissions bits, which get ignored
Given using OCS API version "<ocs_api_version>"
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>
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 "<ocs_status_code>"
And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions <received-permissions>
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 "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Brian" sharing with user "Carol" should include
| share_with | %username% |
| file_target | /Shares/textfile0.txt |
| path | /textfile0.txt |
| path | /textfile0.txt |
| permissions | <granted_permissions> |
| uid_owner | %username% |
And as "Carol" file "/Shares/textfile0.txt" should exist
@@ -148,7 +148,7 @@ Feature: sharing
But as "Brian" file "/Shares/textfile0.txt" should exist
And as "Alice" file "/textfile0.txt" should exist
Examples:
| ocs_api_version | ocs_status_code | received_permissions | reshare_permissions | granted_permissions |
| ocs-api-version | ocs-status-code | received-permissions | reshare-permissions | granted-permissions |
| 1 | 100 | 19 | 23 | 19 |
| 2 | 200 | 19 | 23 | 19 |
| 1 | 100 | 19 | 31 | 19 |
@@ -168,17 +168,17 @@ Feature: sharing
@skipOnRevaMaster
Scenario Outline: user is not allowed to reshare folder and set more permissions bits
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/PARENT"
And user "Alice" has shared folder "/PARENT" with user "Brian" with permissions <received_permissions>
When user "Brian" shares folder "/Shares/PARENT" with user "Carol" with permissions <reshare_permissions> using the sharing API
And user "Alice" has shared folder "/PARENT" with user "Brian" with permissions <received-permissions>
When user "Brian" shares folder "/Shares/PARENT" with user "Carol" with permissions <reshare-permissions> using the sharing API
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
And as "Carol" folder "/Shares/PARENT" should not exist
And the sharing API should report to user "Carol" that no shares are in the pending state
But as "Brian" folder "/Shares/PARENT" should exist
Examples:
| ocs_api_version | http_status_code | received_permissions | reshare_permissions |
| ocs-api-version | http-status-code | received-permissions | reshare-permissions |
# try to pass on more bits including reshare
| 1 | 200 | 17 | 19 |
| 2 | 403 | 17 | 19 |
@@ -208,17 +208,17 @@ Feature: sharing
@skipOnRevaMaster
Scenario Outline: user is not allowed to reshare folder and add delete permission bit (8)
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/PARENT"
And user "Alice" has shared folder "/PARENT" with user "Brian" with permissions <received_permissions>
When user "Brian" shares folder "/Shares/PARENT" with user "Carol" with permissions <reshare_permissions> using the sharing API
And user "Alice" has shared folder "/PARENT" with user "Brian" with permissions <received-permissions>
When user "Brian" shares folder "/Shares/PARENT" with user "Carol" with permissions <reshare-permissions> using the sharing API
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
And as "Carol" folder "/Shares/PARENT" should not exist
And the sharing API should report to user "Carol" that no shares are in the pending state
But as "Brian" folder "/Shares/PARENT" should exist
Examples:
| ocs_api_version | http_status_code | received_permissions | reshare_permissions |
| ocs-api-version | http-status-code | received-permissions | reshare-permissions |
# try to pass on extra delete (including reshare)
| 1 | 200 | 17 | 25 |
| 2 | 403 | 17 | 25 |
@@ -236,48 +236,48 @@ Feature: sharing
Scenario Outline: reshare a file with same name as a deleted file
Given using OCS API version "<ocs_api_version>"
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"
And user "Alice" has deleted file "textfile0.txt"
And user "Alice" has uploaded file with content "ownCloud new test text file 0" to "/textfile0.txt"
When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the content of file "/Shares/textfile0.txt" for user "Brian" should be "ownCloud new test text file 0"
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: reshare a folder with same name as a deleted folder
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/PARENT"
And user "Alice" has shared folder "PARENT" with user "Brian"
And user "Alice" has deleted folder "PARENT"
And user "Alice" has created folder "/PARENT"
When user "Alice" shares folder "PARENT" with user "Brian" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as "Brian" folder "/Shares/PARENT" should exist
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: reshare a folder with same name as a deleted file
Given using OCS API version "<ocs_api_version>"
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"
And user "Alice" has deleted file "/textfile0.txt"
And user "Alice" has created folder "/textfile0.txt"
When user "Alice" shares folder "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 "<ocs-status-code>"
And the HTTP status code should be "200"
And as "Brian" folder "/Shares/textfile0.txt" should exist
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |

6
tests/acceptance/features/coreApiShareReshareToShares1/reShareDisabled.feature
View File

@@ -11,12 +11,12 @@ Feature: resharing can be disabled
| Alice |
| Brian |
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And using OCS API version "<ocs_api_version>"
And using OCS API version "<ocs-api-version>"
When user "Alice" shares file "/textfile0.txt" with user "Brian" with permissions "share,update,read" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as "Brian" file "/Shares/textfile0.txt" should exist
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |

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

@@ -15,30 +15,30 @@ Feature: a subfolder of a received share can be reshared
@smokeTest @issue-2214
Scenario Outline: user is allowed to reshare a sub-folder with the same permissions
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,read"
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>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as "Carol" folder "/Shares/SUB" should exist
And as "Brian" folder "/Shares/TMP/SUB" should exist
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@skipOnRevaMaster
Scenario Outline: user is not allowed to reshare a sub-folder with more permissions
Given using OCS API version "<ocs_api_version>"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions <received_permissions>
When user "Brian" shares folder "/Shares/TMP/SUB" with user "Carol" with permissions <reshare_permissions> using the sharing API
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions <received-permissions>
When user "Brian" shares folder "/Shares/TMP/SUB" with user "Carol" with permissions <reshare-permissions> using the sharing API
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
And as "Carol" folder "/Shares/SUB" should not exist
And the sharing API should report to user "Carol" that no shares are in the pending state
And as "Brian" folder "/Shares/TMP/SUB" should exist
Examples:
| ocs_api_version | http_status_code | received_permissions | reshare_permissions |
| ocs-api-version | http-status-code | received-permissions | reshare-permissions |
# try to pass on more bits including reshare
| 1 | 200 | 17 | 19 |
| 2 | 403 | 17 | 19 |
@@ -82,54 +82,54 @@ Feature: a subfolder of a received share can be reshared
@issue-2214
Scenario Outline: user is allowed to update reshare of a sub-folder with less permissions
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
And user "Brian" has shared folder "/Shares/TMP/SUB" with user "Carol" with permissions "share,create,update,read"
When user "Brian" updates the last share using the sharing API with
| permissions | share,read |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as "Carol" folder "/Shares/SUB" should exist
But user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "/Shares/SUB/textfile.txt"
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 |
| 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
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
And user "Brian" has shared folder "/Shares/TMP/SUB" with user "Carol" with permissions "share,read"
When user "Brian" updates the last share using the sharing API with
| permissions | share,create,update,read |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as "Carol" folder "/Shares/SUB" should exist
And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "/Shares/SUB/textfile.txt"
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 |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@issue-2214 @skipOnRevaMaster
Scenario Outline: user is not allowed to update reshare of a sub-folder with more permissions
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,read"
And user "Brian" has shared folder "/Shares/TMP/SUB" with user "Carol" with permissions "share,read"
When user "Brian" updates the last share using the sharing API with
| permissions | all |
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
And as "Carol" folder "/Shares/SUB" should exist
But user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "/Shares/SUB/textfile.txt"
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 |
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |

48
tests/acceptance/features/coreApiShareReshareToShares2/reShareUpdate.feature
View File

@@ -14,125 +14,125 @@ Feature: sharing
Scenario Outline: update of reshare can reduce permissions
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,create,update,read"
When user "Brian" updates the last share using the sharing API with
| permissions | share,read |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt"
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: update of reshare can increase permissions to the maximum allowed
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,read"
When user "Brian" updates the last share using the sharing API with
| permissions | share,create,update,read |
Then the OCS status code should be "<ocs_status_code>"
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 upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt"
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@skipOnRevaMaster
Scenario Outline: do not allow update of reshare to exceed permissions
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,read"
And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,read"
When user "Brian" updates the last share using the sharing API with
| permissions | all |
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
And user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt"
Examples:
| ocs_api_version | http_status_code |
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
Scenario Outline: update of user reshare by the original share owner can increase permissions up to the permissions of the top-level share
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,read"
When user "Alice" updates the last share using the sharing API with
| permissions | share,create,update,read |
Then the OCS status code should be "<ocs_status_code>"
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 upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt"
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: update of user reshare by the original share owner can increase permissions to more than the permissions of the top-level share
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,update,read"
And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,read"
When user "Alice" updates the last share using the sharing API with
| permissions | share,create,update,read |
Then the OCS status code should be "<ocs_status_code>"
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 upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt"
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: update of group reshare by the original share owner can increase permissions up to permissions of the top-level share
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And group "grp1" has been created
And user "Carol" has been added to group "grp1"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
And user "Brian" has shared folder "Shares/TMP" with group "grp1" with permissions "share,read"
When user "Alice" updates the last share using the sharing API with
| permissions | share,create,update,read |
Then the OCS status code should be "<ocs_status_code>"
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 upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt"
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: update of group reshare by the original share owner can increase permissions to more than the permissions of the top-level share
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And group "grp1" has been created
And user "Carol" has been added to group "grp1"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,update,read"
And user "Brian" has shared folder "Shares/TMP" with group "grp1" with permissions "share,read"
When user "Alice" updates the last share using the sharing API with
| permissions | share,create,update,read |
Then the OCS status code should be "<ocs_status_code>"
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 upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt"
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: after losing share permissions user can still delete a previously reshared share
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,create,update,read"
And user "Alice" has updated the last share of "Alice" with
| permissions | create,update,read |
When user "Brian" deletes the last share using the sharing API
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And user "Carol" should not have any received shares
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |

18
tests/acceptance/features/coreApiShareReshareToShares2/reShareWithExpiryDate.feature
View File

@@ -14,7 +14,7 @@ Feature: resharing a resource with an expiration date
Scenario Outline: user should be able to set expiration while resharing a file with user
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share"
When user "Brian" creates a share using the sharing API with settings
| path | /Shares/textfile0.txt |
@@ -23,19 +23,19 @@ Feature: resharing a resource with an expiration date
| shareWith | Carol |
| expireDate | +3 days |
Then the HTTP status code should be "200"
And the OCS status code should be "<ocs_status_code>"
And the OCS status code should be "<ocs-status-code>"
And the information of the last share of user "Brian" should include
| expiration | +3 days |
And the response when user "Carol" gets the info of the last share should include
| expiration | +3 days |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@issue-1289
Scenario Outline: user should be able to set expiration while resharing a file with group
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And group "grp1" has been created
And user "Carol" has been added to group "grp1"
And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share"
@@ -46,19 +46,19 @@ Feature: resharing a resource with an expiration date
| shareWith | grp1 |
| expireDate | +3 days |
Then the HTTP status code should be "200"
And the OCS status code should be "<ocs_status_code>"
And the OCS status code should be "<ocs-status-code>"
And the information of the last share of user "Brian" should include
| expiration | +3 days |
And the response when user "Carol" gets the info of the last share should include
| expiration | +3 days |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: resharing using the sharing API with default expire date set but not enforced
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share"
When user "Brian" creates a share using the sharing API with settings
| path | /Shares/textfile0.txt |
@@ -66,12 +66,12 @@ Feature: resharing a resource with an expiration date
| permissions | change |
| shareWith | Carol |
Then the HTTP status code should be "200"
And the OCS status code should be "<ocs_status_code>"
And the OCS status code should be "<ocs-status-code>"
And the information of the last share of user "Brian" should include
| expiration | |
And the response when user "Carol" gets the info of the last share should include
| expiration | |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |

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

@@ -10,7 +10,7 @@ Feature: sharing
@smokeTest
Scenario Outline: allow modification of reshare
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And these users have been created with default attributes and without skeleton files:
| username |
| Brian |
@@ -20,18 +20,18 @@ Feature: sharing
And user "Brian" has shared folder "/Shares/TMP" with user "Carol"
When user "Brian" updates the last share using the sharing API with
| permissions | read |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "/Shares/TMP/textfile.txt"
And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "/Shares/TMP/textfile.txt"
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@issue-1289 @issue-7555
Scenario Outline: keep group permissions in sync when the share is renamed by the receiver and then the permissions are updated by sharer
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
@@ -40,7 +40,7 @@ Feature: sharing
And user "Brian" has moved file "/Shares/textfile0.txt" to "/Shares/textfile_new.txt"
When user "Alice" updates the last share using the sharing API with
| permissions | read |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" sharing with group "grp1" should include
| id | A_STRING |
@@ -57,39 +57,39 @@ Feature: sharing
| displayname_owner | %displayname% |
| mimetype | text/plain |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: cannot set permissions to zero
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And group "grp1" has been created
And user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with group "grp1"
When user "Alice" updates the last share using the sharing API with
| permissions | 0 |
Then the OCS status code should be "400"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
Examples:
| ocs_api_version | http_status_code |
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 400 |
@issue-2173
Scenario Outline: cannot update a share of a file with a user to have only create and/or delete permission
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
When user "Alice" updates the last share using the sharing API with
| permissions | <permissions> |
Then the OCS status code should be "400"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
# Brian should still have at least read access to the shared file
And as "Brian" entry "/Shares/textfile0.txt" should exist
Examples:
| ocs_api_version | http_status_code | permissions |
| ocs-api-version | http-status-code | permissions |
| 1 | 200 | create |
| 2 | 400 | create |
| 1 | 200 | delete |
@@ -99,7 +99,7 @@ Feature: sharing
@issue-2173
Scenario Outline: cannot update a share of a file with a group to have only create and/or delete permission
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
@@ -108,11 +108,11 @@ Feature: sharing
When user "Alice" updates the last share using the sharing API with
| permissions | <permissions> |
Then the OCS status code should be "400"
And the HTTP status code should be "<http_status_code>"
And the HTTP status code should be "<http-status-code>"
# Brian in grp1 should still have at least read access to the shared file
And as "Brian" entry "/Shares/textfile0.txt" should exist
Examples:
| ocs_api_version | http_status_code | permissions |
| ocs-api-version | http-status-code | permissions |
| 1 | 200 | create |
| 2 | 400 | create |
| 1 | 200 | delete |
@@ -183,13 +183,13 @@ Feature: sharing
@issue-1253 @issue-1224 @issue-1225
#after fixing all the issues merge this scenario with the one below
Scenario Outline: change the permission of the share and check the API response
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "/Alice-folder"
And user "Alice" has shared folder "/Alice-folder" with user "Brian" with permissions "read"
When user "Alice" updates the last share using the sharing API with
| permissions | all |
Then the OCS status code should be "<ocs_status_code>"
Then the OCS status code should be "<ocs-status-code>"
And the OCS status message should be ""
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" sharing with user "Brian" should include
@@ -223,13 +223,13 @@ Feature: sharing
| name | |
# | token | |
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: increasing permissions is allowed for owner
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Carol" has been created with default attributes and without skeleton files
And group "grp1" has been created
@@ -241,11 +241,11 @@ Feature: sharing
| permissions | read |
When user "Carol" updates the last share using the sharing API with
| permissions | all |
Then the OCS status code should be "<ocs_status_code>"
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 upload file "filesForUpload/textfile.txt" to "/Shares/FOLDER/textfile.txt"
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |

12
tests/acceptance/features/coreApiShareUpdateToShares/updateShareGroupAndUserWithSameName.feature
View File

@@ -17,36 +17,36 @@ Feature: updating shares to users and groups that have the same name
Scenario Outline: update permissions of a user share with a user and a group having the same name
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/TMP" with group "Brian"
And user "Alice" has shared folder "/TMP" with user "Brian"
When user "Alice" updates the last share using the sharing API with
| permissions | read |
Then the HTTP status code should be "200"
And the OCS status code should be "<ocs_status_code>"
And the OCS status code should be "<ocs-status-code>"
And the content of file "/Shares/TMP/randomfile.txt" for user "Brian" should be "Random data"
And the content of file "/Shares/TMP/randomfile.txt" for user "Carol" should be "Random data"
And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile-by-Carol.txt"
But user "Brian" should not be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile-by-Brian.txt"
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: update permissions of a group share with a user and a group having the same name
Given using OCS API version "<ocs_api_version>"
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/TMP" with user "Brian"
And user "Alice" has shared folder "/TMP" with group "Brian"
When user "Alice" updates the last share using the sharing API with
| permissions | read |
Then the HTTP status code should be "200"
And the OCS status code should be "<ocs_status_code>"
And the OCS status code should be "<ocs-status-code>"
And the content of file "/Shares/TMP/randomfile.txt" for user "Brian" should be "Random data"
And the content of file "/Shares/TMP/randomfile.txt" for user "Carol" should be "Random data"
And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile-by-Carol.txt"
But user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile-by-Brian.txt"
Examples:
| ocs_api_version | ocs_status_code |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |

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

@@ -18,7 +18,7 @@ Feature: search sharees
When user "Alice" gets the sharees using the sharing API with parameters
| search | sharee |
| itemType | file |
Then the OCS status code should be "<ocs-status>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the "exact users" sharees returned should be empty
And the "users" sharees returned should be
@@ -30,9 +30,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 |
| 1 | 100 |
| 2 | 200 |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: search without exact match not-exact casing
@@ -40,7 +40,7 @@ Feature: search sharees
When user "Alice" gets the sharees using the sharing API with parameters
| search | sHaRee |
| itemType | file |
Then the OCS status code should be "<ocs-status>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the "exact users" sharees returned should be empty
And the "users" sharees returned should be
@@ -52,9 +52,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 |
| 1 | 100 |
| 2 | 200 |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: search only with group members - allowed
@@ -63,7 +63,7 @@ Feature: search sharees
When user "Alice" gets the sharees using the sharing API with parameters
| search | sharee |
| itemType | file |
Then the OCS status code should be "<ocs-status>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the "exact users" sharees returned should be empty
And the "users" sharees returned should be
@@ -75,9 +75,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 |
| 1 | 100 |
| 2 | 200 |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: search with exact match
@@ -85,7 +85,7 @@ Feature: search sharees
When user "Alice" gets the sharees using the sharing API with parameters
| search | Sharee1 |
| itemType | file |
Then the OCS status code should be "<ocs-status>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the "exact users" sharees returned should be
| Sharee One | 0 | sharee1 |
@@ -95,9 +95,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 |
| 1 | 100 |
| 2 | 200 |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: search with exact match not-exact casing
@@ -105,7 +105,7 @@ Feature: search sharees
When user "Alice" gets the sharees using the sharing API with parameters
| search | sharee1 |
| itemType | file |
Then the OCS status code should be "<ocs-status>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the "exact users" sharees returned should be
| Sharee One | 0 | sharee1 |
@@ -115,9 +115,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 |
| 1 | 100 |
| 2 | 200 |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: search with exact match not-exact casing group
@@ -125,7 +125,7 @@ Feature: search sharees
When user "Alice" gets the sharees using the sharing API with parameters
| search | shareegroup2 |
| itemType | file |
Then the OCS status code should be "<ocs-status>"
Then the OCS status code should be "<ocs-status-code>"
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
@@ -135,9 +135,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 |
| 1 | 100 |
| 2 | 200 |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: search with "self"
@@ -145,7 +145,7 @@ Feature: search sharees
When user "Sharee1" gets the sharees using the sharing API with parameters
| search | Sharee1 |
| itemType | file |
Then the OCS status code should be "<ocs-status>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the "exact users" sharees returned should be
| Sharee One | 0 | sharee1 |
@@ -155,9 +155,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 |
| 1 | 100 |
| 2 | 200 |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: enumerate only group members - only show partial results from member of groups
@@ -169,7 +169,7 @@ Feature: search sharees
When user "Alice" gets the sharees using the sharing API with parameters
| search | anot |
| itemType | file |
Then the OCS status code should be "<ocs-status>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the "exact users" sharees returned should be empty
And the "users" sharees returned should be
@@ -179,9 +179,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 |
| 1 | 100 |
| 2 | 200 |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: search without exact match such that the search string matches the user getting the sharees
@@ -190,7 +190,7 @@ Feature: search sharees
When user "sharee1" gets the sharees using the sharing API with parameters
| search | sharee |
| itemType | file |
Then the OCS status code should be "<ocs-status>"
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the "exact users" sharees returned should be empty
And the "users" sharees returned should be
@@ -203,6 +203,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 |
| 1 | 100 |
| 2 | 200 |
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |

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

@@ -18,20 +18,20 @@ Feature: files and folders can be deleted from the trashbin
Given using <dav-path-version> DAV path
And user "Alice" has uploaded file with content "file with comma" to "sample,0.txt"
And user "Alice" has uploaded file with content "file with comma" to "sample,1.txt"
And user "Alice" has deleted file "<filename1>"
And user "Alice" has deleted file "<filename2>"
And user "Alice" has deleted file "<file-name>"
And user "Alice" has deleted file "<file-name-2>"
When user "Alice" empties the trashbin using the trashbin API
Then the HTTP status code should be "204"
And as "Alice" the file with original path "<filename1>" should not exist in the trashbin
And as "Alice" the file with original path "<filename2>" should not exist in the trashbin
And as "Alice" the file with original path "<file-name>" should not exist in the trashbin
And as "Alice" the file with original path "<file-name-2>" should not exist in the trashbin
Examples:
| dav-path-version | filename1 | filename2 |
| dav-path-version | file-name | file-name-2 |
| new | textfile0.txt | textfile1.txt |
| new | sample,0.txt | sample,1.txt |
@skipOnRevaMaster
Examples:
| dav-path-version | filename1 | filename2 |
| dav-path-version | file-name | file-name-2 |
| spaces | textfile0.txt | textfile1.txt |
| spaces | sample,0.txt | sample,1.txt |

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

@@ -294,21 +294,21 @@ Feature: files and folders exist in the trashbin after being deleted
Scenario Outline: user with unusual username deletes a file
Given using <dav-path-version> DAV path
And user "<username>" has been created with default attributes and without skeleton files
And user "<username>" has uploaded file with content "to delete" to "/textfile0.txt"
When user "<username>" deletes file "/textfile0.txt" using the WebDAV API
And user "<user>" has been created with default attributes and without skeleton files
And user "<user>" has uploaded file with content "to delete" to "/textfile0.txt"
When user "<user>" deletes file "/textfile0.txt" using the WebDAV API
Then the HTTP status code should be "204"
And as "<username>" file "/textfile0.txt" should exist in the trashbin
But as "<username>" file "/textfile0.txt" should not exist
And as "<user>" file "/textfile0.txt" should exist in the trashbin
But as "<user>" file "/textfile0.txt" should not exist
Examples:
| dav-path-version | username |
| dav-path-version | user |
| new | dash-123 |
| new | null |
| new | nil |
@skipOnRevaMaster
Examples:
| dav-path-version | username |
| dav-path-version | user |
| spaces | dash-123 |
| spaces | null |
| spaces | nil |

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

@@ -178,15 +178,15 @@ Feature: restore deleted files/folders
Scenario Outline: files with strange names can be restored
Given using <dav-path-version> DAV path
And user "Alice" has uploaded file with content "file original content" to "<file-to-upload>"
And user "Alice" has deleted file "<file-to-upload>"
And user "Alice" restores the file with original path "<file-to-upload>" using the trashbin API
And user "Alice" has uploaded file with content "file original content" to "<file-name>"
And user "Alice" has deleted file "<file-name>"
And user "Alice" restores the file with original path "<file-name>" using the trashbin API
Then the HTTP status code should be "201"
And as "Alice" the file with original path "<file-to-upload>" should not exist in the trashbin
And as "Alice" file "<file-to-upload>" should exist
And the content of file "<file-to-upload>" for user "Alice" should be "file original content"
And as "Alice" the file with original path "<file-name>" should not exist in the trashbin
And as "Alice" file "<file-name>" should exist
And the content of file "<file-name>" for user "Alice" should be "file original content"
Examples:
| dav-path-version | file-to-upload |
| dav-path-version | file-name |
| old | 😛 😜 🐱 🐭 ⌚️ ♀️ 🚴‍♂️ |
| new | 😛 😜 🐱 🐭 ⌚️ ♀️ 🚴‍♂️ |
| old | strängé नेपाली file |

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

@@ -162,13 +162,13 @@ Feature: dav-versions
When user "Alice" downloads the version of file "textfile0.txt" with the index "1"
Then the HTTP status code should be "200"
And the following headers should be set
| header | value |
| header | value |
| Content-Disposition | attachment; filename*=UTF-8''"textfile0.txt"; filename="textfile0.txt" |
And the downloaded content should be "version 1"
When user "Alice" downloads the version of file "textfile0.txt" with the index "2"
Then the HTTP status code should be "200"
And the following headers should be set
| header | value |
| header | value |
| Content-Disposition | attachment; filename*=UTF-8''"textfile0.txt"; filename="textfile0.txt" |
And the downloaded content should be "uploaded content"
@@ -181,13 +181,13 @@ Feature: dav-versions
When user "Alice" downloads the version of file "textfile0.txt" with the index "1"
Then the HTTP status code should be "200"
And the following headers should be set
| header | value |
| header | value |
| Content-Disposition | attachment; filename*=UTF-8''"textfile0.txt"; filename="textfile0.txt" |
And the downloaded content should be "version 2"
When user "Alice" downloads the version of file "textfile0.txt" with the index "2"
Then the HTTP status code should be "200"
And the following headers should be set
| header | value |
| header | value |
| Content-Disposition | attachment; filename*=UTF-8''"textfile0.txt"; filename="textfile0.txt" |
And the downloaded content should be "uploaded content"

22
tests/acceptance/features/coreApiWebdavDelete/deleteFile.feature
View File

@@ -46,13 +46,13 @@ Feature: delete file
Scenario Outline: delete file from folder with dots in the path
Given using <dav-path-version> DAV path
And user "Alice" has created folder "<folder_name>"
And user "Alice" has uploaded file with content "uploaded content for file name with dots" to "<folder_name>/<file_name>"
When user "Alice" deletes file "<folder_name>/<file_name>" using the WebDAV API
And user "Alice" has created folder "<folder-name>"
And user "Alice" has uploaded file with content "uploaded content for file name with dots" to "<folder-name>/<file-name>"
When user "Alice" deletes file "<folder-name>/<file-name>" using the WebDAV API
Then the HTTP status code should be "204"
And as "Alice" file "<folder_name>/<file_name>" should not exist
And as "Alice" file "<folder-name>/<file-name>" should not exist
Examples:
| dav-path-version | folder_name | file_name |
| dav-path-version | folder-name | file-name |
| old | /upload. | abc. |
| old | /upload. | abc . |
| old | /upload.1 | abc.txt |
@@ -70,7 +70,7 @@ Feature: delete file
@skipOnRevaMaster
Examples:
| dav-path-version | folder_name | file_name |
| dav-path-version | folder-name | file-name |
| spaces | /upload. | abc. |
| spaces | /upload...1.. | abc...txt.. |
| spaces | /upload.1 | abc.txt |
@@ -82,12 +82,12 @@ Feature: delete file
Scenario Outline: delete a file with comma in the filename
Given using <dav-path-version> DAV path
And user "Alice" has uploaded file with content "file with comma in filename" to <filename>
When user "Alice" deletes file <filename> using the WebDAV API
And user "Alice" has uploaded file with content "file with comma in filename" to <file-name>
When user "Alice" deletes file <file-name> using the WebDAV API
Then the HTTP status code should be "204"
And as "Alice" file <filename> should not exist
And as "Alice" file <file-name> should not exist
Examples:
| dav-path-version | filename |
| dav-path-version | file-name |
| old | "sample,1.txt" |
| old | ",,,.txt" |
| old | ",,,.," |
@@ -97,7 +97,7 @@ Feature: delete file
@skipOnRevaMaster
Examples:
| dav-path-version | filename |
| dav-path-version | file-name |
| spaces | "sample,1.txt" |
| spaces | ",,,.txt" |
| spaces | ",,,.," |

10
tests/acceptance/features/coreApiWebdavDelete/deleteFolder.feature
View File

@@ -64,12 +64,12 @@ Feature: delete folder
Scenario Outline: deleting folder with dot in the name
Given using <dav-path-version> DAV path
And user "Alice" has created folder "<folder_name>"
When user "Alice" deletes folder "<folder_name>" using the WebDAV API
And user "Alice" has created folder "<folder-name>"
When user "Alice" deletes folder "<folder-name>" using the WebDAV API
Then the HTTP status code should be "204"
And as "Alice" folder "<folder_name>" should not exist
And as "Alice" folder "<folder-name>" should not exist
Examples:
| dav-path-version | folder_name |
| dav-path-version | folder-name |
| old | /fo. |
| old | /fo.1 |
| old | /fo...1.. |
@@ -87,7 +87,7 @@ Feature: delete folder
@skipOnRevaMaster
Examples:
| dav-path-version | folder_name |
| dav-path-version | folder-name |
| spaces | /fo. |
| spaces | /fo.1 |
| spaces | /fo...1.. |

10
tests/acceptance/features/coreApiWebdavMove1/moveFolder.feature
View File

@@ -103,13 +103,13 @@ Feature: move (rename) folder
Scenario Outline: renaming folder with dots in the path
Given using <dav-path-version> DAV path
And user "Alice" has created folder "<folder_name>"
And user "Alice" has uploaded file with content "uploaded content for file name ending with a dot" to "<folder_name>/abc.txt"
When user "Alice" moves folder "<folder_name>" to "/uploadFolder" using the WebDAV API
And user "Alice" has created folder "<folder-name>"
And user "Alice" has uploaded file with content "uploaded content for file name ending with a dot" to "<folder-name>/abc.txt"
When user "Alice" moves folder "<folder-name>" to "/uploadFolder" using the WebDAV API
Then the HTTP status code should be "201"
And the content of file "/uploadFolder/abc.txt" for user "Alice" should be "uploaded content for file name ending with a dot"
Examples:
| dav-path-version | folder_name |
| dav-path-version | folder-name |
| old | /upload. |
| old | /upload.1 |
| old | /upload...1.. |
@@ -123,7 +123,7 @@ Feature: move (rename) folder
@skipOnRevaMaster
Examples:
| dav-path-version | folder_name |
| dav-path-version | folder-name |
| spaces | /upload. |
| spaces | /upload.1 |
| spaces | /upload...1.. |

122
tests/acceptance/features/coreApiWebdavMove2/moveFile.feature
View File

@@ -250,13 +250,13 @@ Feature: move (rename) file
Scenario Outline: renaming file with dots in the path
Given using <dav-path-version> DAV path
And user "Alice" has created folder "<folder_name>"
And user "Alice" has uploaded file with content "uploaded content for file name ending with a dot" to "<folder_name>/<file_name>"
When user "Alice" moves file "<folder_name>/<file_name>" to "<folder_name>/abc.txt" using the WebDAV API
And user "Alice" has created folder "<folder-name>"
And user "Alice" has uploaded file with content "uploaded content for file name ending with a dot" to "<folder-name>/<file-name>"
When user "Alice" moves file "<folder-name>/<file-name>" to "<folder-name>/abc.txt" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "<folder_name>/abc.txt" should exist
And as "Alice" file "<folder-name>/abc.txt" should exist
Examples:
| dav-path-version | folder_name | file_name |
| dav-path-version | folder-name | file-name |
| old | /upload. | abc. |
| old | /upload. | abc . |
| old | /upload.1 | abc |
@@ -272,7 +272,7 @@ Feature: move (rename) file
@skipOnRevaMaster
Examples:
| dav-path-version | folder_name | file_name |
| dav-path-version | folder-name | file-name |
| spaces | /upload. | abc. |
| spaces | /upload. | abc . |
| spaces | /upload.1 | abc |
@@ -377,79 +377,79 @@ Feature: move (rename) file
Scenario Outline: moving a file (deep moves with various folder and file names)
Given using <dav-path-version> DAV path
And user "Alice" has created folder "<source_folder>"
And user "Alice" has created folder "<target_folder>"
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/<source_folder>/<source_file>"
When user "Alice" moves file "/<source_folder>/<source_file>" to "/<target_folder>/<target_file>" using the WebDAV API
And user "Alice" has created folder "<source-folder>"
And user "Alice" has created folder "<destination-folder>"
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/<source-folder>/<source-file>"
When user "Alice" moves file "/<source-folder>/<source-file>" to "/<destination-folder>/<destination-file>" using the WebDAV API
Then the HTTP status code should be "201"
And the following headers should match these regular expressions for user "Alice"
| ETag | /^"[a-f0-9:\.]{1,32}"$/ |
And the content of file "/<target_folder>/<target_file>" for user "Alice" should be "ownCloud test text file 0"
And the content of file "/<destination-folder>/<destination-file>" for user "Alice" should be "ownCloud test text file 0"
Examples:
| dav-path-version | source_folder | source_file | target_folder | target_file |
| old | text | file.txt | 0 | file.txt |
| old | text | file.txt | 1 | file.txt |
| old | 0 | file.txt | text | file.txt |
| old | 1 | file.txt | text | file.txt |
| old | texta | 0 | textb | file.txt |
| old | texta | 1 | textb | file.txt |
| old | texta | file.txt | textb | 0 |
| old | texta | file.txt | textb | 1 |
| new | text | file.txt | 0 | file.txt |
| new | text | file.txt | 1 | file.txt |
| new | 0 | file.txt | text | file.txt |
| new | 1 | file.txt | text | file.txt |
| new | texta | 0 | textb | file.txt |
| new | texta | 1 | textb | file.txt |
| new | texta | file.txt | textb | 0 |
| new | texta | file.txt | textb | 1 |
| dav-path-version | source-folder | source-file | destination-folder | destination-file |
| old | text | file.txt | 0 | file.txt |
| old | text | file.txt | 1 | file.txt |
| old | 0 | file.txt | text | file.txt |
| old | 1 | file.txt | text | file.txt |
| old | texta | 0 | textb | file.txt |
| old | texta | 1 | textb | file.txt |
| old | texta | file.txt | textb | 0 |
| old | texta | file.txt | textb | 1 |
| new | text | file.txt | 0 | file.txt |
| new | text | file.txt | 1 | file.txt |
| new | 0 | file.txt | text | file.txt |
| new | 1 | file.txt | text | file.txt |
| new | texta | 0 | textb | file.txt |
| new | texta | 1 | textb | file.txt |
| new | texta | file.txt | textb | 0 |
| new | texta | file.txt | textb | 1 |
@skipOnRevaMaster
Examples:
| dav-path-version | source_folder | source_file | target_folder | target_file |
| spaces | text | file.txt | 0 | file.txt |
| spaces | text | file.txt | 1 | file.txt |
| spaces | 0 | file.txt | text | file.txt |
| spaces | 1 | file.txt | text | file.txt |
| spaces | texta | 0 | textb | file.txt |
| spaces | texta | 1 | textb | file.txt |
| spaces | texta | file.txt | textb | 0 |
| spaces | texta | file.txt | textb | 1 |
| dav-path-version | source-folder | source-file | destination-folder | destination-file |
| spaces | text | file.txt | 0 | file.txt |
| spaces | text | file.txt | 1 | file.txt |
| spaces | 0 | file.txt | text | file.txt |
| spaces | 1 | file.txt | text | file.txt |
| spaces | texta | 0 | textb | file.txt |
| spaces | texta | 1 | textb | file.txt |
| spaces | texta | file.txt | textb | 0 |
| spaces | texta | file.txt | textb | 1 |
Scenario Outline: moving a file from a folder to the root
Given using <dav-path-version> DAV path
And user "Alice" has created folder "<source_folder>"
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/<source_folder>/<source_file>"
When user "Alice" moves file "/<source_folder>/<source_file>" to "/<target_file>" using the WebDAV API
And user "Alice" has created folder "<source-folder>"
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/<source-folder>/<source-file>"
When user "Alice" moves file "/<source-folder>/<source-file>" to "/<destination-file>" using the WebDAV API
Then the HTTP status code should be "201"
And the following headers should match these regular expressions for user "Alice"
| ETag | /^"[a-f0-9:\.]{1,32}"$/ |
And the content of file "/<target_file>" for user "Alice" should be "ownCloud test text file 0"
And the content of file "/<destination-file>" for user "Alice" should be "ownCloud test text file 0"
Examples:
| dav-path-version | source_folder | source_file | target_file |
| old | 0 | file.txt | file.txt |
| old | 1 | file.txt | file.txt |
| old | texta | 0 | file.txt |
| old | texta | 1 | file.txt |
| old | texta | file.txt | 0 |
| old | texta | file.txt | 1 |
| new | 0 | file.txt | file.txt |
| new | 1 | file.txt | file.txt |
| new | texta | 0 | file.txt |
| new | texta | 1 | file.txt |
| new | texta | file.txt | 0 |
| new | texta | file.txt | 1 |
| dav-path-version | source-folder | source-file | destination-file |
| old | 0 | file.txt | file.txt |
| old | 1 | file.txt | file.txt |
| old | texta | 0 | file.txt |
| old | texta | 1 | file.txt |
| old | texta | file.txt | 0 |
| old | texta | file.txt | 1 |
| new | 0 | file.txt | file.txt |
| new | 1 | file.txt | file.txt |
| new | texta | 0 | file.txt |
| new | texta | 1 | file.txt |
| new | texta | file.txt | 0 |
| new | texta | file.txt | 1 |
@skipOnRevaMaster
Examples:
| dav-path-version | source_folder | source_file | target_file |
| spaces | 0 | file.txt | file.txt |
| spaces | 1 | file.txt | file.txt |
| spaces | texta | 0 | file.txt |
| spaces | texta | 1 | file.txt |
| spaces | texta | file.txt | 0 |
| spaces | texta | file.txt | 1 |
| dav-path-version | source-folder | source-file | destination-file |
| spaces | 0 | file.txt | file.txt |
| spaces | 1 | file.txt | file.txt |
| spaces | texta | 0 | file.txt |
| spaces | texta | 1 | file.txt |
| spaces | texta | file.txt | 0 |
| spaces | texta | file.txt | 1 |
Scenario Outline: move a file of size zero byte

8
tests/acceptance/features/coreApiWebdavMove2/moveShareOnOcis.feature
View File

@@ -247,10 +247,10 @@ Feature: move (rename) file
And user "Brian" has created folder "testshare/child"
And user "Brian" has uploaded file with content "test data" to "testshare/testfile.txt"
And user "Brian" has created a share with settings
| path | testshare |
| shareType | user |
| permissions | read |
| shareWith | Alice |
| path | testshare |
| shareType | user |
| permissions | read |
| shareWith | Alice |
When user "Alice" moves folder "Shares/testshare/testfile.txt" to "Shares/testshare/child/testfile.txt" using the WebDAV API
Then the HTTP status code should be "403"
And as "Alice" file "/Shares/testshare/child/testfile.txt" should not exist

34
tests/acceptance/features/coreApiWebdavOperations/downloadFile.feature
View File

@@ -117,12 +117,12 @@ Feature: download file
Scenario Outline: download a file with comma in the filename
Given using <dav-path-version> DAV path
And user "Alice" has uploaded file with content "file with comma in filename" to <filename>
When user "Alice" downloads file <filename> using the WebDAV API
And user "Alice" has uploaded file with content "file with comma in filename" to <file-name>
When user "Alice" downloads file <file-name> using the WebDAV API
Then the HTTP status code should be "200"
And the downloaded content should be "file with comma in filename"
Examples:
| dav-path-version | filename |
| dav-path-version | file-name |
| old | "sample,1.txt" |
| old | ",,,.txt" |
| old | ",,,.," |
@@ -132,7 +132,7 @@ Feature: download file
@skipOnRevaMaster
Examples:
| dav-path-version | filename |
| dav-path-version | file-name |
| spaces | "sample,1.txt" |
| spaces | ",,,.txt" |
| spaces | ",,,.," |
@@ -265,22 +265,22 @@ Feature: download file
@smokeTest @issue-8361
Scenario Outline: downloading a file should serve security headers
Given using <dav-path-version> DAV path
And user "Alice" has uploaded file with content "test file" to "/<file>"
When user "Alice" downloads file "/<file>" using the WebDAV API
And user "Alice" has uploaded file with content "test file" to "/<file-name>"
When user "Alice" downloads file "/<file-name>" using the WebDAV API
Then the HTTP status code should be "200"
And the following headers should be set
| header | value |
| Content-Disposition | attachment; filename*=UTF-8''"<file>"; filename="<file>" |
| Content-Security-Policy | default-src 'none'; |
| X-Content-Type-Options | nosniff |
| X-Download-Options | noopen |
| X-Frame-Options | SAMEORIGIN |
| X-Permitted-Cross-Domain-Policies | none |
| X-Robots-Tag | none |
| X-XSS-Protection | 1; mode=block |
| header | value |
| Content-Disposition | attachment; filename*=UTF-8''"<file-name>"; filename="<file-name>" |
| Content-Security-Policy | default-src 'none'; |
| X-Content-Type-Options | nosniff |
| X-Download-Options | noopen |
| X-Frame-Options | SAMEORIGIN |
| X-Permitted-Cross-Domain-Policies | none |
| X-Robots-Tag | none |
| X-XSS-Protection | 1; mode=block |
And the downloaded content should be "test file"
Examples:
| dav-path-version | file |
| dav-path-version | file-name |
| old | textfile.txt |
| old | comma,.txt |
| old | 'quote'single'.txt |
@@ -290,7 +290,7 @@ Feature: download file
@skipOnRevaMaster
Examples:
| dav-path-version | file |
| dav-path-version | file-name |
| spaces | textfile.txt |
| spaces | comma,.txt |
| spaces | 'quote'single'.txt |

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

@@ -6,15 +6,15 @@ Feature: PROPFIND
@issue-751
Scenario Outline: send PROPFIND request to "/remote.php/dav/(files|spaces)"
Given user "Alice" has been created with default attributes and without skeleton files
When user "Alice" requests "<dav_path>" with "PROPFIND" using basic auth
When user "Alice" requests "<dav-path>" with "PROPFIND" using basic auth
Then the HTTP status code should be "405"
Examples:
| dav_path |
| dav-path |
| /remote.php/dav/files |
@skipOnRevaMaster
Examples:
| dav_path |
| dav-path |
| /remote.php/dav/spaces |
@@ -23,26 +23,26 @@ 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-code>"
Then the HTTP status code should be "<http-status-code>"
Examples:
| dav-path | depth | http-code |
| /remote.php/webdav | 0 | 207 |
| /remote.php/webdav | 1 | 207 |
| /remote.php/dav/files/alice | 0 | 207 |
| /remote.php/dav/files/alice | 1 | 207 |
| dav-path | depth | http-status-code |
| /remote.php/webdav | 0 | 207 |
| /remote.php/webdav | 1 | 207 |
| /remote.php/dav/files/alice | 0 | 207 |
| /remote.php/dav/files/alice | 1 | 207 |
@skipOnRevaMaster
Examples:
| dav-path | depth | http-code |
| /remote.php/dav/spaces/%spaceid% | 0 | 207 |
| /remote.php/dav/spaces/%spaceid% | 1 | 207 |
| /remote.php/dav/spaces/%spaceid% | infinity | 400 |
| dav-path | depth | http-status-code |
| /remote.php/dav/spaces/%spaceid% | 0 | 207 |
| /remote.php/dav/spaces/%spaceid% | 1 | 207 |
| /remote.php/dav/spaces/%spaceid% | infinity | 400 |
@skipOnReva
Examples:
| dav-path | depth | http-code |
| /remote.php/webdav | infinity | 400 |
| /remote.php/dav/files/alice | infinity | 400 |
| dav-path | depth | http-status-code |
| /remote.php/webdav | infinity | 400 |
| /remote.php/dav/files/alice | infinity | 400 |
Scenario: send PROPFIND request to a public link shared with password

20
tests/acceptance/features/coreApiWebdavPreviews/previews.feature
View File

@@ -88,12 +88,12 @@ Feature: previews of files downloaded through the webdav API
Scenario Outline: download previews of file types that don't support preview
Given using <dav-path-version> DAV path
And user "Alice" has uploaded file "filesForUpload/<filename>" to "/<filename>"
When user "Alice" downloads the preview of "/<filename>" with width "32" and height "32" using the WebDAV API
And user "Alice" has uploaded file "filesForUpload/<file-name>" to "/<file-name>"
When user "Alice" downloads the preview of "/<file-name>" with width "32" and height "32" using the WebDAV API
Then the HTTP status code should be "404"
And the value of the item "/d:error/s:exception" in the response about user "Alice" should be "Sabre\DAV\Exception\NotFound"
Examples:
| dav-path-version | filename |
| dav-path-version | file-name |
| old | simple.pdf |
| old | simple.odt |
| old | new-data.zip |
@@ -107,12 +107,12 @@ Feature: previews of files downloaded through the webdav API
Scenario Outline: download previews of different image file types
Given using <dav-path-version> DAV path
And user "Alice" has uploaded file "filesForUpload/<imageName>" to "/<imageName>"
When user "Alice" downloads the preview of "/<imageName>" with width "32" and height "32" using the WebDAV API
And user "Alice" has uploaded file "filesForUpload/<image-name>" to "/<image-name>"
When user "Alice" downloads the preview of "/<image-name>" with width "32" and height "32" using the WebDAV API
Then the HTTP status code should be "200"
And the downloaded image should be "32" pixels wide and "32" pixels high
Examples:
| dav-path-version | imageName |
| dav-path-version | image-name |
| old | testavatar.jpg |
| old | testavatar.png |
| new | testavatar.jpg |
@@ -138,13 +138,13 @@ Feature: previews of files downloaded through the webdav API
Scenario Outline: download previews of shared files (to shares folder)
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 "filesForUpload/<resource>" to "/<resource>"
And user "Alice" has shared file "/<resource>" with user "Brian"
When user "Brian" downloads the preview of shared resource "/Shares/<resource>" with width "32" and height "32" using the WebDAV API
And user "Alice" has uploaded file "filesForUpload/<file-name>" to "/<file-name>"
And user "Alice" has shared file "/<file-name>" with user "Brian"
When user "Brian" downloads the preview of shared resource "/Shares/<file-name>" with width "32" and height "32" using the WebDAV API
Then the HTTP status code should be "200"
And the downloaded image should be "32" pixels wide and "32" pixels high
Examples:
| dav-path-version | resource |
| dav-path-version | file-name |
| old | lorem.txt |
| old | example.gif |
| new | lorem.txt |

6
tests/acceptance/features/coreApiWebdavPreviews/previewsAutoAdustedSizing.feature
View File

@@ -13,11 +13,11 @@ Feature: sizing of previews of files downloaded through the webdav API
Scenario Outline: download different sizes of previews of file
Given user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt"
When user "Alice" downloads the preview of "/parent.txt" with width <request_width> and height <request_height> using the WebDAV API
When user "Alice" downloads the preview of "/parent.txt" with width <request-width> and height <request-height> using the WebDAV API
Then the HTTP status code should be "200"
And the downloaded image should be <return_width> pixels wide and <return_height> pixels high
And the downloaded image should be <return-width> pixels wide and <return-height> pixels high
Examples:
| request_width | request_height | return_width | return_height |
| request-width | request-height | return-width | return-height |
| 1 | 1 | 16 | 16 |
| 32 | 32 | 32 | 32 |
| 1024 | 1024 | 640 | 480 |

18
tests/acceptance/features/coreApiWebdavProperties/createFileFolder.feature
View File

@@ -10,11 +10,11 @@ Feature: create files and folder
Scenario Outline: create a folder
Given using <dav-path-version> DAV path
When user "Alice" creates folder "<folder_name>" using the WebDAV API
When user "Alice" creates folder "<folder-name>" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" folder "<folder_name>" should exist
And as "Alice" folder "<folder-name>" should exist
Examples:
| dav-path-version | folder_name |
| dav-path-version | folder-name |
| old | /upload |
| old | /strängé folder |
| old | /C++ folder.cpp |
@@ -34,7 +34,7 @@ Feature: create files and folder
@skipOnRevaMaster
Examples:
| dav-path-version | folder_name |
| dav-path-version | folder-name |
| spaces | /upload |
| spaces | /strängé folder |
| spaces | /C++ folder.cpp |
@@ -143,12 +143,12 @@ Feature: create files and folder
Scenario Outline: create a file
Given using <dav-path-version> DAV path
When user "Alice" uploads file with content "some text" to "<file_name>" using the WebDAV API
When user "Alice" uploads file with content "some text" to "<file-name>" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "<file_name>" should exist
And the content of file "<file_name>" for user "Alice" should be "some text"
And as "Alice" file "<file-name>" should exist
And the content of file "<file-name>" for user "Alice" should be "some text"
Examples:
| dav-path-version | file_name |
| dav-path-version | file-name |
| old | /upload.txt |
| old | /strängéfile.txt |
| old | /C++ file.cpp |
@@ -168,7 +168,7 @@ Feature: create files and folder
@skipOnRevaMaster
Examples:
| dav-path-version | file_name |
| dav-path-version | file-name |
| spaces | /upload.txt |
| spaces | /strängéfile.txt |
| spaces | /C++ file.cpp |

12
tests/acceptance/features/coreApiWebdavProperties/createFileFolderWhenSharesExist.feature
View File

@@ -15,12 +15,12 @@ Feature: create file or folder named similar to Shares folder
Scenario Outline: create a folder with a name similar to Shares
Given using <dav-path-version> DAV path
When user "Brian" creates folder "<folder_name>" using the WebDAV API
When user "Brian" creates folder "<folder-name>" using the WebDAV API
Then the HTTP status code should be "201"
And as "Brian" folder "<folder_name>" should exist
And as "Brian" folder "<folder-name>" should exist
And as "Brian" folder "/Shares" should exist
Examples:
| dav-path-version | folder_name |
| dav-path-version | folder-name |
| old | /Share |
| old | /shares |
| old | /Shares1 |
@@ -31,12 +31,12 @@ Feature: create file or folder named similar to Shares folder
Scenario Outline: create a file with a name similar to Shares
Given using <dav-path-version> DAV path
When user "Brian" uploads file with content "some text" to "<file_name>" using the WebDAV API
When user "Brian" uploads file with content "some text" to "<file-name>" using the WebDAV API
Then the HTTP status code should be "201"
And the content of file "<file_name>" for user "Brian" should be "some text"
And the content of file "<file-name>" for user "Brian" should be "some text"
And as "Brian" folder "/Shares" should exist
Examples:
| dav-path-version | file_name |
| dav-path-version | file-name |
| old | /Share |
| old | /shares |
| old | /Shares1 |

46
tests/acceptance/features/coreApiWebdavProperties/getFileProperties.feature
View File

@@ -10,12 +10,12 @@ Feature: get file properties
@smokeTest
Scenario Outline: user sends a PROPFIND request on various file names
Given using <dav-path-version> DAV path
And user "Alice" has uploaded file with content "uploaded content" to "<file_name>"
When user "Alice" gets the properties of file "<file_name>" using the WebDAV API
And user "Alice" has uploaded file with content "uploaded content" to "<file-name>"
When user "Alice" gets the properties of file "<file-name>" using the WebDAV API
Then the HTTP status code should be "207"
And the properties response should contain an etag
Examples:
| dav-path-version | file_name |
| dav-path-version | file-name |
| old | /upload.txt |
| old | /strängé file.txt |
| old | /नेपाली.txt |
@@ -27,7 +27,7 @@ Feature: get file properties
@skipOnRevaMaster
Examples:
| dav-path-version | file_name |
| dav-path-version | file-name |
| spaces | /upload.txt |
| spaces | /strängé file.txt |
| spaces | /नेपाली.txt |
@@ -36,13 +36,13 @@ Feature: get file properties
@issue-1296
Scenario Outline: user sends a PROPFIND request on various file with '?, #, &, +' in its name
Given using <dav-path-version> DAV path
And user "Alice" has uploaded file with content "uploaded content" to "<file_name>"
When user "Alice" gets the properties of file "<file_name>" using the WebDAV API
And user "Alice" has uploaded file with content "uploaded content" to "<file-name>"
When user "Alice" gets the properties of file "<file-name>" using the WebDAV API
Then the HTTP status code should be "207"
And the properties response should contain an etag
And there should be an entry with href containing "<expected_href>" in the response to user "Alice"
And there should be an entry with href containing "<expected-href>" in the response to user "Alice"
Examples:
| dav-path-version | file_name | expected_href |
| dav-path-version | file-name | expected-href |
| old | /C++ file.cpp | remote.php/webdav/C++ file.cpp |
| old | /file #2.txt | remote.php/webdav/file #2.txt |
| old | /file ?2.txt | remote.php/webdav/file ?2.txt |
@@ -54,7 +54,7 @@ Feature: get file properties
@skipOnRevaMaster
Examples:
| dav-path-version | file_name | expected_href |
| dav-path-version | file-name | expected-href |
| spaces | /C++ file.cpp | dav/spaces/%spaceid%/C++ file.cpp |
| spaces | /file #2.txt | dav/spaces/%spaceid%/file #2.txt |
| spaces | /file ?2.txt | dav/spaces/%spaceid%/file ?2.txt |
@@ -63,16 +63,16 @@ Feature: get file properties
@issue-1296
Scenario Outline: user sends a PROPFIND request on various folder names
Given using <dav-path-version> DAV path
And user "Alice" has created folder "<folder_name>"
And user "Alice" has uploaded file with content "uploaded content" to "<folder_name>/file1.txt"
And user "Alice" has uploaded file with content "uploaded content" to "<folder_name>/file2.txt"
When user "Alice" gets the properties of folder "<folder_name>" with depth 1 using the WebDAV API
And user "Alice" has created folder "<folder-name>"
And user "Alice" has uploaded file with content "uploaded content" to "<folder-name>/file1.txt"
And user "Alice" has uploaded file with content "uploaded content" to "<folder-name>/file2.txt"
When user "Alice" gets the properties of folder "<folder-name>" with depth 1 using the WebDAV API
Then the HTTP status code should be "207"
And there should be an entry with href containing "<expected_href>/" in the response to user "Alice"
And there should be an entry with href containing "<expected_href>/file1.txt" in the response to user "Alice"
And there should be an entry with href containing "<expected_href>/file2.txt" in the response to user "Alice"
And there should be an entry with href containing "<expected-href>/" in the response to user "Alice"
And there should be an entry with href containing "<expected-href>/file1.txt" in the response to user "Alice"
And there should be an entry with href containing "<expected-href>/file2.txt" in the response to user "Alice"
Examples:
| dav-path-version | folder_name | expected_href |
| dav-path-version | folder-name | expected-href |
| old | /upload | remote.php/webdav/upload |
| old | /strängé folder | remote.php/webdav/strängé folder |
| old | /C++ folder | remote.php/webdav/C++ folder |
@@ -90,7 +90,7 @@ Feature: get file properties
@skipOnRevaMaster
Examples:
| dav-path-version | folder_name | expected_href |
| dav-path-version | folder-name | expected-href |
| spaces | /upload | dav/spaces/%spaceid%/upload |
| spaces | /strängé folder | dav/spaces/%spaceid%/strängé folder |
| spaces | /C++ folder | dav/spaces/%spaceid%/C++ folder |
@@ -102,13 +102,13 @@ Feature: get file properties
Scenario Outline: user sends a PROPFIND request on various files inside various folders
Given using <dav-path-version> DAV path
And user "Alice" has created folder "<folder_name>"
And user "Alice" has uploaded file with content "uploaded content" to "<folder_name>/<file_name>"
When user "Alice" gets the properties of file "<folder_name>/<file_name>" using the WebDAV API
And user "Alice" has created folder "<folder-name>"
And user "Alice" has uploaded file with content "uploaded content" to "<folder-name>/<file-name>"
When user "Alice" gets the properties of file "<folder-name>/<file-name>" using the WebDAV API
Then the HTTP status code should be "207"
And the properties response should contain an etag
Examples:
| dav-path-version | folder_name | file_name |
| dav-path-version | folder-name | file-name |
| old | /upload | abc.txt |
| old | /strängé folder | strängé file.txt |
| old | /C++ folder | C++ file.cpp |
@@ -122,7 +122,7 @@ Feature: get file properties
@skipOnRevaMaster
Examples:
| dav-path-version | folder_name | file_name |
| dav-path-version | folder-name | file-name |
| spaces | /upload | abc.txt |
| spaces | /strängé folder | strängé file.txt |
| spaces | /C++ folder | C++ file.cpp |

4
tests/acceptance/features/coreApiWebdavProperties/getQuota.feature
View File

@@ -45,13 +45,13 @@ Feature: get quota
| shareType | user |
| permissions | all |
| shareWith | Alice |
When user "Alice" gets the following properties of folder "<folder-path>" inside space "Shares" using the WebDAV API
When user "Alice" gets the following properties of folder "<folder-name>" inside space "Shares" using the WebDAV API
| propertyName |
| d:quota-available-bytes |
Then the HTTP status code should be "207"
And the single response should contain a property "d:quota-available-bytes" with value "9000"
Examples:
| dav-path-version | folder-path |
| dav-path-version | folder-name |
| old | /Shares/testquota |
| new | /Shares/testquota |
| spaces | /testquota |

20
tests/acceptance/features/coreApiWebdavProperties/setFileProperties.feature
View File

@@ -84,21 +84,21 @@ Feature: set file properties
@issue-1263
Scenario Outline: setting custom DAV property using one endpoint and reading it with other endpoint
Given using <action-dav-path-version> DAV path
Given using <dav-path-version> DAV path
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/testnewold.txt"
And user "Alice" has set property "very-custom-prop" with namespace "x1='http://whatever.org/ns'" of file "/testnewold.txt" to "lucky"
And using <other-dav-path-version> DAV path
And using <dav-path-version-2> DAV path
When user "Alice" gets a custom property "very-custom-prop" with namespace "x1='http://whatever.org/ns'" of file "/testnewold.txt"
Then the response should contain a custom "very-custom-prop" property with namespace "x1='http://whatever.org/ns'" and value "lucky"
Examples:
| action-dav-path-version | other-dav-path-version |
| old | new |
| new | old |
| dav-path-version | dav-path-version-2 |
| old | new |
| new | old |
@skipOnRevaMaster
Examples:
| action-dav-path-version | other-dav-path-version |
| spaces | new |
| spaces | old |
| new | spaces |
| old | spaces |
| dav-path-version | dav-path-version-2 |
| spaces | new |
| spaces | old |
| new | spaces |
| old | spaces |

64
tests/acceptance/features/coreApiWebdavUpload/uploadFile.feature
View File

@@ -10,13 +10,13 @@ Feature: upload file
@smokeTest
Scenario Outline: upload a file and check etag and download content
Given using <dav-path-version> DAV path
When user "Alice" uploads file with content "uploaded content" to "<file_name>" using the WebDAV API
When user "Alice" uploads file with content "uploaded content" to "<file-name>" using the WebDAV API
Then the HTTP status code should be "201"
And the following headers should match these regular expressions for user "Alice"
| ETag | /^"[a-f0-9:\.]{1,32}"$/ |
And the content of file "<file_name>" for user "Alice" should be "uploaded content"
And the content of file "<file-name>" for user "Alice" should be "uploaded content"
Examples:
| dav-path-version | file_name |
| dav-path-version | file-name |
| old | /upload.txt |
| old | /नेपाली.txt |
| old | /strängé file.txt |
@@ -28,7 +28,7 @@ Feature: upload file
@skipOnRevaMaster
Examples:
| dav-path-version | file_name |
| dav-path-version | file-name |
| spaces | /upload.txt |
| spaces | /नेपाली.txt |
| spaces | /strängé file.txt |
@@ -37,11 +37,11 @@ Feature: upload file
Scenario Outline: upload a file and check download content
Given using <dav-path-version> DAV path
When user "Alice" uploads file with content "uploaded content" to <file_name> using the WebDAV API
When user "Alice" uploads file with content "uploaded content" to <file-name> using the WebDAV API
Then the HTTP status code should be "201"
And the content of file <file_name> for user "Alice" should be "uploaded content"
And the content of file <file-name> for user "Alice" should be "uploaded content"
Examples:
| dav-path-version | file_name |
| dav-path-version | file-name |
| old | "C++ file.cpp" |
| old | "file #2.txt" |
| new | "C++ file.cpp" |
@@ -49,7 +49,7 @@ Feature: upload file
@skipOnRevaMaster
Examples:
| dav-path-version | file_name |
| dav-path-version | file-name |
| spaces | "C++ file.cpp" |
| spaces | "file #2.txt" |
@@ -57,11 +57,11 @@ Feature: upload file
#after fixing all issues delete this Scenario and merge with the one above
Scenario Outline: upload a file with character '?' in its name and check download content
Given using <dav-path-version> DAV path
When user "Alice" uploads file with content "uploaded content" to <file_name> using the WebDAV API
When user "Alice" uploads file with content "uploaded content" to <file-name> using the WebDAV API
Then the HTTP status code should be "201"
And the content of file <file_name> for user "Alice" should be "uploaded content"
And the content of file <file-name> for user "Alice" should be "uploaded content"
Examples:
| dav-path-version | file_name |
| dav-path-version | file-name |
| old | "file ?2.txt" |
| old | " ?fi=le&%#2 . txt" |
| old | " # %ab ab?=ed " |
@@ -71,7 +71,7 @@ Feature: upload file
@skipOnRevaMaster
Examples:
| dav-path-version | file_name |
| dav-path-version | file-name |
| spaces | "file ?2.txt" |
| spaces | " ?fi=le&%#2 . txt" |
| spaces | " # %ab ab?=ed " |
@@ -79,11 +79,11 @@ Feature: upload file
Scenario Outline: upload a file with comma in the filename and check download content
Given using <dav-path-version> DAV path
When user "Alice" uploads file with content "file with comma" to <file_name> using the WebDAV API
When user "Alice" uploads file with content "file with comma" to <file-name> using the WebDAV API
Then the HTTP status code should be "201"
And the content of file <file_name> for user "Alice" should be "file with comma"
And the content of file <file-name> for user "Alice" should be "file with comma"
Examples:
| dav-path-version | file_name |
| dav-path-version | file-name |
| old | "sample,1.txt" |
| old | ",,,.txt" |
| old | ",,,.," |
@@ -93,7 +93,7 @@ Feature: upload file
@skipOnRevaMaster
Examples:
| dav-path-version | file_name |
| dav-path-version | file-name |
| spaces | "sample,1.txt" |
| spaces | ",,,.txt" |
| spaces | ",,,.," |
@@ -101,12 +101,12 @@ Feature: upload file
Scenario Outline: upload a file into a folder and check download content
Given using <dav-path-version> DAV path
And user "Alice" has created folder "<folder_name>"
When user "Alice" uploads file with content "uploaded content" to "<folder_name>/<file_name>" using the WebDAV API
And user "Alice" has created folder "<folder-name>"
When user "Alice" uploads file with content "uploaded content" to "<folder-name>/<file-name>" using the WebDAV API
Then the HTTP status code should be "201"
And the content of file "<folder_name>/<file_name>" for user "Alice" should be "uploaded content"
And the content of file "<folder-name>/<file-name>" for user "Alice" should be "uploaded content"
Examples:
| dav-path-version | folder_name | file_name |
| dav-path-version | folder-name | file-name |
| old | /upload | abc.txt |
| old | /strängé folder | strängé file.txt |
| old | /C++ folder | C++ file.cpp |
@@ -120,7 +120,7 @@ Feature: upload file
@skipOnRevaMaster
Examples:
| dav-path-version | folder_name | file_name |
| dav-path-version | folder-name | file-name |
| spaces | /strängé folder | strängé file.txt |
| spaces | /upload | abc.txt |
| spaces | /C++ folder | C++ file.cpp |
@@ -131,12 +131,12 @@ Feature: upload file
#after fixing all issues delete this Scenario and merge with the one above
Scenario Outline: upload a file into a folder with character '?' in its name and check download content
Given using <dav-path-version> DAV path
And user "Alice" has created folder "<folder_name>"
When user "Alice" uploads file with content "uploaded content" to "<folder_name>/<file_name>" using the WebDAV API
And user "Alice" has created folder "<folder-name>"
When user "Alice" uploads file with content "uploaded content" to "<folder-name>/<file-name>" using the WebDAV API
Then the HTTP status code should be "201"
And the content of file "<folder_name>/<file_name>" for user "Alice" should be "uploaded content"
And the content of file "<folder-name>/<file-name>" for user "Alice" should be "uploaded content"
Examples:
| dav-path-version | folder_name | file_name |
| dav-path-version | folder-name | file-name |
| old | /folder ?2.txt | file ?2.txt |
| old | /?fi=le&%#2 . txt | # %ab ab?=ed |
| new | /folder ?2.txt | file ?2.txt |
@@ -144,7 +144,7 @@ Feature: upload file
@skipOnRevaMaster
Examples:
| dav-path-version | folder_name | file_name |
| dav-path-version | folder-name | file-name |
| spaces | /folder ?2.txt | file ?2.txt |
| spaces | /?fi=le&%#2 . txt | # %ab ab?=ed |
@@ -188,13 +188,13 @@ Feature: upload file
Scenario Outline: upload a file into a folder with dots in the path and check download content
Given using <dav-path-version> DAV path
And user "Alice" has created folder "<folder_name>"
When user "Alice" uploads file with content "uploaded content for file name ending with a dot" to "<folder_name>/<file_name>" using the WebDAV API
And user "Alice" has created folder "<folder-name>"
When user "Alice" uploads file with content "uploaded content for file name ending with a dot" to "<folder-name>/<file-name>" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "/<folder_name>/<file_name>" should exist
And the content of file "<folder_name>/<file_name>" for user "Alice" should be "uploaded content for file name ending with a dot"
And as "Alice" file "/<folder-name>/<file-name>" should exist
And the content of file "<folder-name>/<file-name>" for user "Alice" should be "uploaded content for file name ending with a dot"
Examples:
| dav-path-version | folder_name | file_name |
| dav-path-version | folder-name | file-name |
| old | /upload. | abc. |
| old | /upload. | abc . |
| old | /upload.1 | abc.txt |
@@ -209,7 +209,7 @@ Feature: upload file
@skipOnRevaMaster
Examples:
| dav-path-version | folder_name | file_name |
| dav-path-version | folder-name | file-name |
| spaces | /upload. | abc. |
| spaces | /upload. | abc . |
| spaces | /upload.1 | abc.txt |

30
tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature
View File

@@ -78,11 +78,11 @@ Feature: checksums
| Upload-Length | 5 |
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
When user "Alice" uploads file with checksum "<incorrect_checksum>" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API
When user "Alice" uploads file with checksum "<checksum>" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API
Then the HTTP status code should be "406"
And as "Alice" file "textFile.txt" should not exist
Examples:
| dav-path-version | incorrect_checksum |
| dav-path-version | checksum |
| old | MD5 827ccb0eea8a706c4c34a16891f84e7a |
| new | MD5 827ccb0eea8a706c4c34a16891f84e7a |
| old | SHA1 8cb2237d0679ca88db6464eac60da96345513963 |
@@ -90,7 +90,7 @@ Feature: checksums
@skipOnRevaMaster
Examples:
| dav-path-version | incorrect_checksum |
| dav-path-version | checksum |
| spaces | MD5 827ccb0eea8a706c4c34a16891f84e7a |
| spaces | SHA1 8cb2237d0679ca88db6464eac60da96345513963 |
@@ -189,7 +189,7 @@ Feature: checksums
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
And user "Alice" has uploaded a chunk to the last created TUS Location with offset "0" and data "01234" with checksum "MD5 4100c4d44da9177247e44a5fc1546778" using the TUS protocol on the WebDAV API
And user "Alice" has uploaded a chunk to the last created TUS Location with offset "5" and data "56789" with checksum "MD5 099ebea48ea9666a7da2177267983138" using the TUS protocol on the WebDAV API
When user "Alice" overwrites existing file with offset "0" and data "hello" with checksum "<overwriteChecksum>" using the TUS protocol on the WebDAV API with these headers:
When user "Alice" overwrites existing file with offset "0" and data "hello" with checksum "<checksum>" using the TUS protocol on the WebDAV API with these headers:
| Upload-Length | 5 |
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
And user "Alice" requests the checksum of "/textFile.txt" via propfind
@@ -197,7 +197,7 @@ Feature: checksums
And the webdav checksum should match "SHA1:aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d MD5:5d41402abc4b2a76b9719d911017c592 ADLER32:062c0215"
And the content of file "/textFile.txt" for user "Alice" should be "hello"
Examples:
| dav-path-version | overwriteChecksum |
| dav-path-version | checksum |
| old | MD5 5d41402abc4b2a76b9719d911017c592 |
| new | MD5 5d41402abc4b2a76b9719d911017c592 |
| old | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d |
@@ -205,7 +205,7 @@ Feature: checksums
@skipOnRevaMaster
Examples:
| dav-path-version | overwriteChecksum |
| dav-path-version | checksum |
| spaces | MD5 5d41402abc4b2a76b9719d911017c592 |
| spaces | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d |
@@ -218,13 +218,13 @@ Feature: checksums
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
And user "Alice" has uploaded a chunk to the last created TUS Location with offset "0" and data "01234" with checksum "MD5 4100c4d44da9177247e44a5fc1546778" using the TUS protocol on the WebDAV API
And user "Alice" has uploaded a chunk to the last created TUS Location with offset "5" and data "56789" with checksum "MD5 099ebea48ea9666a7da2177267983138" using the TUS protocol on the WebDAV API
When user "Alice" overwrites existing file with offset "0" and data "hello" with checksum "<overwriteInvalidChecksum>" using the TUS protocol on the WebDAV API with these headers:
When user "Alice" overwrites existing file with offset "0" and data "hello" with checksum "<checksum>" using the TUS protocol on the WebDAV API with these headers:
| Upload-Length | 5 |
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
Then the HTTP status code should be "406"
And the content of file "/textFile.txt" for user "Alice" should be "0123456789"
Examples:
| dav-path-version | overwriteInvalidChecksum |
| dav-path-version | checksum |
| old | MD5 5d41402abc4b2a76b9719d911017c593 |
| new | MD5 5d41402abc4b2a76b9719d911017c593 |
| old | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434a |
@@ -232,7 +232,7 @@ Feature: checksums
@skipOnRevaMaster
Examples:
| dav-path-version | overwriteInvalidChecksum |
| dav-path-version | checksum |
| spaces | MD5 5d41402abc4b2a76b9719d911017c593 |
| spaces | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434a |
@@ -244,7 +244,7 @@ Feature: checksums
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
And user "Alice" has uploaded file with checksum "MD5 827ccb0eea8a706c4c34a16891f84e7b" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API
When user "Alice" overwrites existing file with offset "0" and data "hello" with checksum "<overwriteChecksum>" using the TUS protocol on the WebDAV API with these headers:
When user "Alice" overwrites existing file with offset "0" and data "hello" with checksum "<checksum>" using the TUS protocol on the WebDAV API with these headers:
| Upload-Length | 5 |
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
@@ -253,7 +253,7 @@ Feature: checksums
And the webdav checksum should match "SHA1:aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d MD5:5d41402abc4b2a76b9719d911017c592 ADLER32:062c0215"
And the content of file "/textFile.txt" for user "Alice" should be "hello"
Examples:
| dav-path-version | overwriteChecksum |
| dav-path-version | checksum |
| old | MD5 5d41402abc4b2a76b9719d911017c592 |
| new | MD5 5d41402abc4b2a76b9719d911017c592 |
| old | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d |
@@ -261,7 +261,7 @@ Feature: checksums
@skipOnRevaMaster
Examples:
| dav-path-version | overwriteChecksum |
| dav-path-version | checksum |
| spaces | MD5 5d41402abc4b2a76b9719d911017c592 |
| spaces | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d |
@@ -273,14 +273,14 @@ Feature: checksums
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
And user "Alice" has uploaded file with checksum "MD5 827ccb0eea8a706c4c34a16891f84e7b" to the last created TUS Location with offset "0" and content "12345" using the TUS protocol on the WebDAV API
When user "Alice" overwrites existing file with offset "0" and data "hello" with checksum "<overwriteChecksum>" using the TUS protocol on the WebDAV API with these headers:
When user "Alice" overwrites existing file with offset "0" and data "hello" with checksum "<checksum>" using the TUS protocol on the WebDAV API with these headers:
| Upload-Length | 5 |
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
Then the HTTP status code should be "406"
And the content of file "/textFile.txt" for user "Alice" should be "12345"
Examples:
| dav-path-version | overwriteChecksum |
| dav-path-version | checksum |
| old | MD5 5d41402abc4b2a76b9719d911017c593 |
| new | MD5 5d41402abc4b2a76b9719d911017c593 |
| old | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434a |
@@ -288,6 +288,6 @@ Feature: checksums
@skipOnRevaMaster
Examples:
| dav-path-version | overwriteChecksum |
| dav-path-version | checksum |
| spaces | MD5 5d41402abc4b2a76b9719d911017c593 |
| spaces | SHA1 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434a |

24
tests/acceptance/features/coreApiWebdavUploadTUS/uploadFile.feature
View File

@@ -9,10 +9,10 @@ Feature: upload file
Scenario Outline: upload a file and check download content
Given using <dav-path-version> DAV path
When user "Alice" uploads file with content "uploaded content" to "<file_name>" using the TUS protocol on the WebDAV API
Then the content of file "<file_name>" for user "Alice" should be "uploaded content"
When user "Alice" uploads file with content "uploaded content" to "<file-name>" using the TUS protocol on the WebDAV API
Then the content of file "<file-name>" for user "Alice" should be "uploaded content"
Examples:
| dav-path-version | file_name |
| dav-path-version | file-name |
| old | /upload.txt |
| old | /नेपाली.txt |
| old | /strängé file.txt |
@@ -30,7 +30,7 @@ Feature: upload file
@skipOnRevaMaster
Examples:
| dav-path-version | file_name |
| dav-path-version | file-name |
| spaces | /upload.txt |
| spaces | /strängé file.txt |
| spaces | /नेपाली.txt |
@@ -42,11 +42,11 @@ Feature: upload file
Scenario Outline: upload a file into a folder and check download content
Given using <dav-path-version> DAV path
And user "Alice" has created folder "<folder_name>"
When user "Alice" uploads file with content "uploaded content" to "<folder_name>/<file_name>" using the TUS protocol on the WebDAV API
Then the content of file "<folder_name>/<file_name>" for user "Alice" should be "uploaded content"
And user "Alice" has created folder "<folder-name>"
When user "Alice" uploads file with content "uploaded content" to "<folder-name>/<file-name>" using the TUS protocol on the WebDAV API
Then the content of file "<folder-name>/<file-name>" for user "Alice" should be "uploaded content"
Examples:
| dav-path-version | folder_name | file_name |
| dav-path-version | folder-name | file-name |
| old | /upload | abc.txt |
| old | /strängé folder | strängé file.txt |
| old | /C++ folder | C++ file.cpp |
@@ -64,7 +64,7 @@ Feature: upload file
@skipOnRevaMaster
Examples:
| dav-path-version | folder_name | file_name |
| dav-path-version | folder-name | file-name |
| spaces | /upload | abc.txt |
| spaces | /strängé folder (duplicate #2 &) | strängé file (duplicate #2 &) |
| spaces | /C++ folder | C++ file.cpp |
@@ -189,9 +189,9 @@ Feature: upload file
And the following headers should not be set
| header |
| Location |
And as "Alice" file <file_name> should not exist
And as "Alice" file <file-name> should not exist
Examples:
| dav-path-version | file_name | metadata |
| dav-path-version | file-name | metadata |
| old | " " | IA== |
| old | "filewithLF-and-CR\r\n" | ZmlsZXdpdGhMRi1hbmQtQ1INCgo= |
| old | "folder/file" | Zm9sZGVyL2ZpbGU= |
@@ -203,7 +203,7 @@ Feature: upload file
@skipOnRevaMaster
Examples:
| dav-path-version | file_name | metadata |
| dav-path-version | file-name | metadata |
| spaces | " " | IA== |
| spaces | "filewithLF-and-CR\r\n" | ZmlsZXdpdGhMRi1hbmQtQ1INCgo= |
| spaces | "folder/file" | Zm9sZGVyL2ZpbGU= |