From ba7d91ebce7d502ff37589fbf524966f1408172b Mon Sep 17 00:00:00 2001 From: Prarup Gurung Date: Wed, 20 Mar 2024 15:01:51 +0545 Subject: [PATCH] Used kebab case for example table header name --- .../features/coreApiAuth/ocsPUTAuth.feature | 6 +- .../features/coreApiAuth/webDavAuth.feature | 10 +- .../coreApiAuth/webDavSpecialURLs.feature | 4 +- .../features/coreApiMain/checksums.feature | 8 +- ...eateShareResourceCaseSensitiveName.feature | 2 +- ...hareDefaultFolderForReceivedShares.feature | 8 +- .../createShareReceivedInMultipleWays.feature | 46 ++--- .../createShareWithInvalidPermissions.feature | 38 ++--- .../createShareToSharesFolder.feature | 158 +++++++++--------- .../deleteShareFromShares.feature | 72 ++++---- .../acceptShares.feature | 2 +- .../moveReceivedShare.feature | 52 +++--- .../accessToShare.feature | 24 +-- .../gettingShares.feature | 46 ++--- .../gettingSharesPendingFiltered.feature | 12 +- .../gettingSharesReceivedFiltered.feature | 12 +- ...gettingSharesReceivedFilteredEmpty.feature | 18 +- .../gettingSharesSharedFiltered.feature | 24 +-- .../gettingSharesSharedFilteredEmpty.feature | 18 +- .../shareAccessByID.feature | 62 +++---- .../changingPublicLinkShare.feature | 30 ++-- .../createPublicLinkShare.feature | 82 ++++----- .../createPublicLinkShareToShares.feature | 6 +- .../deletePublicLinkShare.feature | 24 +-- .../multilinkSharing.feature | 24 +-- .../reShareAsPublicLinkToSharesNewDav.feature | 54 +++--- .../updatePublicLinkShare.feature | 98 +++++------ .../uploadToPublicLinkShare.feature | 2 +- .../reShare.feature | 94 +++++------ .../reShareDisabled.feature | 6 +- .../reShareSubfolder.feature | 34 ++-- .../reShareUpdate.feature | 48 +++--- .../reShareWithExpiryDate.feature | 18 +- .../updateShare.feature | 42 ++--- ...pdateShareGroupAndUserWithSameName.feature | 12 +- .../features/coreApiSharees/sharees.feature | 72 ++++---- .../coreApiTrashbin/trashbinDelete.feature | 12 +- .../trashbinFilesFolders.feature | 14 +- .../trashbinRestore.feature | 14 +- .../coreApiVersions/fileVersions.feature | 8 +- .../coreApiWebdavDelete/deleteFile.feature | 22 +-- .../coreApiWebdavDelete/deleteFolder.feature | 10 +- .../coreApiWebdavMove1/moveFolder.feature | 10 +- .../coreApiWebdavMove2/moveFile.feature | 122 +++++++------- .../moveShareOnOcis.feature | 8 +- .../downloadFile.feature | 34 ++-- .../coreApiWebdavOperations/propfind.feature | 32 ++-- .../coreApiWebdavPreviews/previews.feature | 20 +-- .../previewsAutoAdustedSizing.feature | 6 +- .../createFileFolder.feature | 18 +- .../createFileFolderWhenSharesExist.feature | 12 +- .../getFileProperties.feature | 46 ++--- .../coreApiWebdavProperties/getQuota.feature | 4 +- .../setFileProperties.feature | 20 +-- .../coreApiWebdavUpload/uploadFile.feature | 64 +++---- .../coreApiWebdavUploadTUS/checksums.feature | 30 ++-- .../coreApiWebdavUploadTUS/uploadFile.feature | 24 +-- 57 files changed, 900 insertions(+), 898 deletions(-) diff --git a/tests/acceptance/features/coreApiAuth/ocsPUTAuth.feature b/tests/acceptance/features/coreApiAuth/ocsPUTAuth.feature index 3ab00a67cf..d2aa947406 100644 --- a/tests/acceptance/features/coreApiAuth/ocsPUTAuth.feature +++ b/tests/acceptance/features/coreApiAuth/ocsPUTAuth.feature @@ -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" diff --git a/tests/acceptance/features/coreApiAuth/webDavAuth.feature b/tests/acceptance/features/coreApiAuth/webDavAuth.feature index e19534ce93..73b84500e6 100644 --- a/tests/acceptance/features/coreApiAuth/webDavAuth.feature +++ b/tests/acceptance/features/coreApiAuth/webDavAuth.feature @@ -8,22 +8,22 @@ Feature: auth @smokeTest Scenario Outline: using WebDAV anonymously - When a user requests "" with "PROPFIND" and no authentication + When a user requests "" 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 "" with "PROPFIND" using basic auth + When user "Alice" requests "" 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% | diff --git a/tests/acceptance/features/coreApiAuth/webDavSpecialURLs.feature b/tests/acceptance/features/coreApiAuth/webDavSpecialURLs.feature index 2de2f082c9..056e946b9e 100644 --- a/tests/acceptance/features/coreApiAuth/webDavSpecialURLs.feature +++ b/tests/acceptance/features/coreApiAuth/webDavSpecialURLs.feature @@ -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 diff --git a/tests/acceptance/features/coreApiMain/checksums.feature b/tests/acceptance/features/coreApiMain/checksums.feature index ffc8548a59..5ebb9bd232 100644 --- a/tests/acceptance/features/coreApiMain/checksums.feature +++ b/tests/acceptance/features/coreApiMain/checksums.feature @@ -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 - When user "Alice" uploads file "filesForUpload/textfile.txt" to with checksum "MD5:d70b40f177b14b470d1756a3c12b963a" using the WebDAV API + When user "Alice" uploads file "filesForUpload/textfile.txt" to with checksum "MD5:d70b40f177b14b470d1756a3c12b963a" using the WebDAV API Then the HTTP status code should be "201" - And the content of file for user "Alice" should be: + And the content of 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" | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToShares1/createShareResourceCaseSensitiveName.feature b/tests/acceptance/features/coreApiShareCreateSpecialToShares1/createShareResourceCaseSensitiveName.feature index f3d12d2a01..8f1fe6f7f1 100644 --- a/tests/acceptance/features/coreApiShareCreateSpecialToShares1/createShareResourceCaseSensitiveName.feature +++ b/tests/acceptance/features/coreApiShareCreateSpecialToShares1/createShareResourceCaseSensitiveName.feature @@ -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 diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareDefaultFolderForReceivedShares.feature b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareDefaultFolderForReceivedShares.feature index 76430e3fa8..0825a44a79 100644 --- a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareDefaultFolderForReceivedShares.feature +++ b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareDefaultFolderForReceivedShares.feature @@ -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 "" + Given using 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 "" respectively - And the HTTP status code of responses on each endpoint should be "" respectively + Then the OCS status code of responses on each endpoint should be "" respectively + And the HTTP status code of responses on each endpoint should be "" 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 | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature index 46d95e8bf3..ec40ec7e4d 100644 --- a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature +++ b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature @@ -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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + And the OCS status code should be "" 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 "" + And the OCS status code should be "" 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 "" + Given using 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 "" + And the OCS status code should be "" 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 "" + Given using 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 "" + Given using 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 | diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWithInvalidPermissions.feature b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWithInvalidPermissions.feature index 593bfb801d..bc7ff7e202 100644 --- a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWithInvalidPermissions.feature +++ b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareWithInvalidPermissions.feature @@ -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 "" + Given using 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 | | + | path | | | shareWith | Brian | | shareType | user | | permissions | | - Then the OCS status code should be "" - And the HTTP status code should be "" - And as "Brian" entry "" should not exist - And as "Brian" entry "/Shares/" should not exist + Then the OCS status code should be "" + And the HTTP status code should be "" + And as "Brian" entry "" should not exist + And as "Brian" entry "/Shares/" 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 "" + Given using 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 "" + And the HTTP status code should be "" 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 "" + Given using 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 | | Then the OCS status code should be "400" - And the HTTP status code should be "" + And the HTTP status code should be "" 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 "" + Given using 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 "" + And the HTTP status code should be "" 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 "" + Given using 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 | | Then the OCS status code should be "400" - And the HTTP status code should be "" + And the HTTP status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature b/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature index 8ea802c838..8b72e781be 100644 --- a/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature +++ b/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature @@ -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 "" + Given using 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 "" + Then the OCS status code 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 | 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 "" + Given using 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 "" + Then the OCS status code 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 | 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 "" + Given using 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 using the sharing API - Then the OCS status code should be "" + When user "Alice" shares file "textfile0.txt" with user "Brian" with permissions using the sharing API + Then the OCS status code 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 | share_with | %username% | | share_with_displayname | %displayname% | | file_target | /Shares/textfile0.txt | | path | /textfile0.txt | - | permissions | | + | 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 "" + Given using 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 "" + Given using 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 "" + Given using 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 "" + Then the OCS status code 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 | 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code 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 | 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Given using 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 "" + Given using 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 "" + Given using 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code 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 | 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code 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 | 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 "" + Then the HTTP status code should be "" 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 "" + Then the HTTP status code should be "" 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 "" + Then the HTTP status code should be "" 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 "" + Then the HTTP status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature b/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature index 501606d77a..e3829d89c4 100644 --- a/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature +++ b/tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature @@ -13,33 +13,33 @@ Feature: sharing @issue-7555 Scenario Outline: delete all group shares - Given using OCS API version "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" with group "grp1" + And user "Alice" has shared entry "" 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 "" - And as "Alice" entry "" should exist - And as "Brian" entry "" should exist - And as "Carol" entry "" should exist + And the HTTP status code should be "" + And as "Alice" entry "" should exist + And as "Brian" entry "" should exist + And as "Carol" 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 "" + Given using 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 "" with user "Brian" + And user "Alice" has shared entry "" 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 "" - And as "Alice" entry "" should exist - And as "Brian" entry "" should exist + And the HTTP status code should be "" + And as "Alice" entry "" should exist + And as "Brian" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + And the HTTP status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature b/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature index 760010e46e..5367617766 100644 --- a/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature +++ b/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature @@ -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" diff --git a/tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShare.feature b/tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShare.feature index 8ee20c53bd..b94354a662 100644 --- a/tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShare.feature +++ b/tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShare.feature @@ -62,7 +62,7 @@ Feature: sharing And as user "Carol" the value of the item "//oc:name" of path "/sharefile.txt" in the response should be "sharefile.txt" And as user "Carol" the value of the item "//d:displayname" of 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 "/sharefile.txt" in the response should be "sharefile.txt" And as user "Brian" the value of the item "//d:displayname" of 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 "" - And user "Alice" has created folder "" - And user "Alice" has shared folder "" with user "Brian" - When user "Brian" moves folder "/Shares/" to "/Shares/" using the WebDAV API + And user "Alice" has created folder "" + And user "Alice" has created folder "" + And user "Alice" has shared folder "" with user "Brian" + When user "Brian" moves folder "/Shares/" to "/Shares/" using the WebDAV API Then the HTTP status code should be "201" - And as "Alice" folder "" should not exist - And as "Brian" folder "/Shares/" should exist - When user "Alice" shares folder "" with group "grp1" using the sharing API - And user "Carol" moves folder "/Shares/" to "/Shares/" using the WebDAV API + And as "Alice" folder "" should not exist + And as "Brian" folder "/Shares/" should exist + When user "Alice" shares folder "" with group "grp1" using the sharing API + And user "Carol" moves folder "/Shares/" to "/Shares/" using the WebDAV API Then the HTTP status code should be "201" - And as "Alice" folder "" should not exist - But as "Carol" folder "/Shares/" should exist + And as "Alice" folder "" should not exist + But as "Carol" folder "/Shares/" 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 "" - And user "Alice" has created folder "" - And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "//fileInside" - And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "//fileInside" - And user "Alice" has shared folder "" with user "Brian" with permissions "share,read,change" - When user "Brian" moves folder "/Shares//fileInside" to "/Shares//" using the WebDAV API + And user "Alice" has created folder "" + And user "Alice" has created folder "" + And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "//fileInside" + And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "//fileInside" + And user "Alice" has shared folder "" with user "Brian" with permissions "share,read,change" + When user "Brian" moves folder "/Shares//fileInside" to "/Shares//" using the WebDAV API Then the HTTP status code should be "201" - And as "Alice" file "/" should exist - And as "Brian" file "/Shares//" should exist - When user "Alice" shares folder "" with group "grp1" with permissions "share,read,change" using the sharing API - And user "Carol" moves folder "/Shares//fileInside" to "/Shares//" using the WebDAV API + And as "Alice" file "/" should exist + And as "Brian" file "/Shares//" should exist + When user "Alice" shares folder "" with group "grp1" with permissions "share,read,change" using the sharing API + And user "Carol" moves folder "/Shares//fileInside" to "/Shares//" using the WebDAV API Then the HTTP status code should be "201" - And as "Alice" file "/" should exist - And as "Carol" file "/Shares//" should exist + And as "Alice" file "/" should exist + And as "Carol" file "/Shares//" 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 | diff --git a/tests/acceptance/features/coreApiShareOperationsToShares1/accessToShare.feature b/tests/acceptance/features/coreApiShareOperationsToShares1/accessToShare.feature index 7e8498ff6e..c56b238674 100644 --- a/tests/acceptance/features/coreApiShareOperationsToShares1/accessToShare.feature +++ b/tests/acceptance/features/coreApiShareOperationsToShares1/accessToShare.feature @@ -13,58 +13,58 @@ Feature: sharing @smokeTest Scenario Outline: sharee can see the share - Given using OCS API version "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiShareOperationsToShares1/gettingShares.feature b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingShares.feature index 76216b85be..9f72d0c2b8 100644 --- a/tests/acceptance/features/coreApiShareOperationsToShares1/gettingShares.feature +++ b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingShares.feature @@ -12,35 +12,35 @@ Feature: sharing @smokeTest @issue-1258 Scenario Outline: getting all shares from a user - Given using OCS API version "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code 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 | 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 "" + Given using 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 "" 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 "" + Given using 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 "" + Then the OCS status code 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 | 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 | diff --git a/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesPendingFiltered.feature b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesPendingFiltered.feature index e65eb774ec..a99c3702ae 100644 --- a/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesPendingFiltered.feature +++ b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesPendingFiltered.feature @@ -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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesReceivedFiltered.feature b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesReceivedFiltered.feature index 34932effb8..431b153c36 100644 --- a/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesReceivedFiltered.feature +++ b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesReceivedFiltered.feature @@ -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 "" + Given using OCS API version "" When user "Brian" gets the user shares shared with him using the sharing API - Then the OCS status code should be "" + Then the OCS status code should be "" 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 "" + Given using OCS API version "" When user "Brian" gets the group shares shared with him using the sharing API - Then the OCS status code should be "" + Then the OCS status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesReceivedFilteredEmpty.feature b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesReceivedFilteredEmpty.feature index 2a3ea33063..f173ed07cc 100644 --- a/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesReceivedFilteredEmpty.feature +++ b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesReceivedFilteredEmpty.feature @@ -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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesSharedFiltered.feature b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesSharedFiltered.feature index 540ac90e09..03e4a364b5 100644 --- a/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesSharedFiltered.feature +++ b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesSharedFiltered.feature @@ -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 "" + Given using OCS API version "" When user "Alice" gets the user shares shared by her using the sharing API - Then the OCS status code should be "" + Then the OCS status code should be "" 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 "" + Given using OCS API version "" When user "Alice" gets the group shares shared by her using the sharing API - Then the OCS status code should be "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesSharedFilteredEmpty.feature b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesSharedFilteredEmpty.feature index af11ab5560..e38b31a979 100644 --- a/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesSharedFilteredEmpty.feature +++ b/tests/acceptance/features/coreApiShareOperationsToShares1/gettingSharesSharedFilteredEmpty.feature @@ -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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiShareOperationsToShares2/shareAccessByID.feature b/tests/acceptance/features/coreApiShareOperationsToShares2/shareAccessByID.feature index b4a7c20b1d..7bed8c4c44 100644 --- a/tests/acceptance/features/coreApiShareOperationsToShares2/shareAccessByID.feature +++ b/tests/acceptance/features/coreApiShareOperationsToShares2/shareAccessByID.feature @@ -12,11 +12,11 @@ Feature: share access by ID Scenario Outline: get a share with a valid share ID - Given using OCS API version "" + Given using 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 "" + And user "Alice" gets share with id "%last_share-id%" using the sharing API + Then the OCS status code 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 | 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 "" - When user "Alice" gets share with id "" using the sharing API + Given using OCS API version "" + When user "Alice" gets share with id "" using the sharing API Then the OCS status code should be "404" - And the HTTP status code should be "" + And the HTTP status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using OCS API version "" + When user "Brian" accepts share with ID "" using the sharing API Then the OCS status code should be "404" - And the HTTP status code should be "" + And the HTTP status code should be "" 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 "" - Then the OCS status code should be "" - And the HTTP status code should be "" + Given using OCS API version "" + When user "Brian" accepts share with ID "" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "" 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 "" + Given using 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 "" + When user "Brian" declines share with ID "%last_share-id%" using the sharing API + Then the OCS status code should be "" 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 "" - When user "Brian" declines share with ID "" using the sharing API + Given using OCS API version "" + When user "Brian" declines share with ID "" using the sharing API Then the OCS status code should be "404" - And the HTTP status code should be "" + And the HTTP status code should be "" 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 "" + Given using OCS API version "" When user "Brian" declines share with ID "" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "" + Then the OCS status code should be "" + And the HTTP status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiSharePublicLink1/changingPublicLinkShare.feature b/tests/acceptance/features/coreApiSharePublicLink1/changingPublicLinkShare.feature index 14ea10de4d..efa8ebadf2 100644 --- a/tests/acceptance/features/coreApiSharePublicLink1/changingPublicLinkShare.feature +++ b/tests/acceptance/features/coreApiSharePublicLink1/changingPublicLinkShare.feature @@ -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 "" + Given using OCS API version "" And user "Alice" has created a public link share with settings | path | /PARENT | | permissions | | @@ -143,11 +143,11 @@ Feature: changing a public link share | path | /PARENT | | permissions | | | password | | - Then the HTTP status code should be "" + Then the HTTP status code should be "" 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 "" + Given using 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 "" + Then the HTTP status code should be "" 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 "" + Given using 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 "" + And the OCS status code should be "" 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 "" + Given using 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 "" + And the OCS status code should be "" 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 "" + Given using 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 | | | password | | - Then the HTTP status code should be "" + Then the HTTP status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShare.feature b/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShare.feature index c69953ca72..defff9e8b1 100644 --- a/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShare.feature +++ b/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShare.feature @@ -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 "" + Given using 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 "" + And the HTTP status code should be "" 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 "" + And the HTTP status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + And using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + And the HTTP status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + And the HTTP status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShareToShares.feature b/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShareToShares.feature index 9982931937..9944f51ff2 100644 --- a/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShareToShares.feature +++ b/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShareToShares.feature @@ -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 "" + Given using 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 "" + Then the OCS status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiSharePublicLink1/deletePublicLinkShare.feature b/tests/acceptance/features/coreApiSharePublicLink1/deletePublicLinkShare.feature index 0c1f3f225d..d4fc1834e8 100644 --- a/tests/acceptance/features/coreApiSharePublicLink1/deletePublicLinkShare.feature +++ b/tests/acceptance/features/coreApiSharePublicLink1/deletePublicLinkShare.feature @@ -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 "" + Given using 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 "" + And the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + And the OCS status code should be "" 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 "" + Given using 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 "" + And the OCS status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiSharePublicLink2/multilinkSharing.feature b/tests/acceptance/features/coreApiSharePublicLink2/multilinkSharing.feature index 170b0b485f..be532ca0dc 100644 --- a/tests/acceptance/features/coreApiSharePublicLink2/multilinkSharing.feature +++ b/tests/acceptance/features/coreApiSharePublicLink2/multilinkSharing.feature @@ -8,7 +8,7 @@ Feature: multi-link sharing @smokeTest Scenario Outline: creating three public shares of a folder - Given using OCS API version "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiSharePublicLink2/reShareAsPublicLinkToSharesNewDav.feature b/tests/acceptance/features/coreApiSharePublicLink2/reShareAsPublicLinkToSharesNewDav.feature index f681ac2892..5cf28e274c 100644 --- a/tests/acceptance/features/coreApiSharePublicLink2/reShareAsPublicLinkToSharesNewDav.feature +++ b/tests/acceptance/features/coreApiSharePublicLink2/reShareAsPublicLinkToSharesNewDav.feature @@ -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 "" + Given using 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 "" + And the HTTP status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + And the HTTP status code should be "" 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 "" + Given using 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 "" + And the HTTP status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + And the HTTP status code should be "" 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 "" + Given using 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 "" + And the HTTP status code should be "" 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 "" + Given using 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 "" + And the HTTP status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiSharePublicLink2/updatePublicLinkShare.feature b/tests/acceptance/features/coreApiSharePublicLink2/updatePublicLinkShare.feature index 07970716cb..b87d19ca4a 100644 --- a/tests/acceptance/features/coreApiSharePublicLink2/updatePublicLinkShare.feature +++ b/tests/acceptance/features/coreApiSharePublicLink2/updatePublicLinkShare.feature @@ -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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + And the HTTP status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + And the HTTP status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Given using 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 "" + Given using OCS API version "" And using 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 "" + Then the OCS status code should be "" 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 "" + Given using OCS API version "" And using 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 "" + Then the OCS status code should be "" 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 "" + Given using OCS API version "" And using 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 "" + Then the OCS status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiSharePublicLink2/uploadToPublicLinkShare.feature b/tests/acceptance/features/coreApiSharePublicLink2/uploadToPublicLinkShare.feature index 0e4a398e57..f4ba4eaf1c 100644 --- a/tests/acceptance/features/coreApiSharePublicLink2/uploadToPublicLinkShare.feature +++ b/tests/acceptance/features/coreApiSharePublicLink2/uploadToPublicLinkShare.feature @@ -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 diff --git a/tests/acceptance/features/coreApiShareReshareToShares1/reShare.feature b/tests/acceptance/features/coreApiShareReshareToShares1/reShare.feature index 7084808ac8..cb464d3313 100644 --- a/tests/acceptance/features/coreApiShareReshareToShares1/reShare.feature +++ b/tests/acceptance/features/coreApiShareReshareToShares1/reShare.feature @@ -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 "" + Given using 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 "" + And the HTTP status code should be "" 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 "" + Given using 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 "" + And the HTTP status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 using the sharing API + When user "Brian" shares file "/Shares/textfile0.txt" with user "Carol" with permissions using the sharing API Then the OCS status code should be "403" - And the HTTP status code should be "" + And the HTTP status code should be "" 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 "" + Given using 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 - When user "Brian" shares file "/Shares/textfile0.txt" with user "Carol" with permissions using the sharing API - Then the OCS status code should be "" + And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions + When user "Brian" shares file "/Shares/textfile0.txt" with user "Carol" with permissions using the sharing API + Then the OCS status code should be "" 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 | | | 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 "" + Given using OCS API version "" And user "Alice" has created folder "/PARENT" - And user "Alice" has shared folder "/PARENT" with user "Brian" with permissions - When user "Brian" shares folder "/Shares/PARENT" with user "Carol" with permissions using the sharing API + And user "Alice" has shared folder "/PARENT" with user "Brian" with permissions + When user "Brian" shares folder "/Shares/PARENT" with user "Carol" with permissions using the sharing API Then the OCS status code should be "403" - And the HTTP status code should be "" + And the HTTP status code should be "" 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 "" + Given using OCS API version "" And user "Alice" has created folder "/PARENT" - And user "Alice" has shared folder "/PARENT" with user "Brian" with permissions - When user "Brian" shares folder "/Shares/PARENT" with user "Carol" with permissions using the sharing API + And user "Alice" has shared folder "/PARENT" with user "Brian" with permissions + When user "Brian" shares folder "/Shares/PARENT" with user "Carol" with permissions using the sharing API Then the OCS status code should be "403" - And the HTTP status code should be "" + And the HTTP status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiShareReshareToShares1/reShareDisabled.feature b/tests/acceptance/features/coreApiShareReshareToShares1/reShareDisabled.feature index 06914abb5a..52cb73736f 100644 --- a/tests/acceptance/features/coreApiShareReshareToShares1/reShareDisabled.feature +++ b/tests/acceptance/features/coreApiShareReshareToShares1/reShareDisabled.feature @@ -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 "" + And using 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 "" + Then the OCS status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiShareReshareToShares2/reShareSubfolder.feature b/tests/acceptance/features/coreApiShareReshareToShares2/reShareSubfolder.feature index 3b5b0df2a9..6b7a1e15b7 100644 --- a/tests/acceptance/features/coreApiShareReshareToShares2/reShareSubfolder.feature +++ b/tests/acceptance/features/coreApiShareReshareToShares2/reShareSubfolder.feature @@ -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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" - And user "Alice" has shared folder "/TMP" with user "Brian" with permissions - When user "Brian" shares folder "/Shares/TMP/SUB" with user "Carol" with permissions using the sharing API + Given using OCS API version "" + And user "Alice" has shared folder "/TMP" with user "Brian" with permissions + When user "Brian" shares folder "/Shares/TMP/SUB" with user "Carol" with permissions using the sharing API Then the OCS status code should be "403" - And the HTTP status code should be "" + And the HTTP status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + And the HTTP status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiShareReshareToShares2/reShareUpdate.feature b/tests/acceptance/features/coreApiShareReshareToShares2/reShareUpdate.feature index c65b421a5e..f7330fef7b 100644 --- a/tests/acceptance/features/coreApiShareReshareToShares2/reShareUpdate.feature +++ b/tests/acceptance/features/coreApiShareReshareToShares2/reShareUpdate.feature @@ -14,125 +14,125 @@ Feature: sharing Scenario Outline: update of reshare can reduce permissions - Given using OCS API version "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + And the HTTP status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiShareReshareToShares2/reShareWithExpiryDate.feature b/tests/acceptance/features/coreApiShareReshareToShares2/reShareWithExpiryDate.feature index 526b6a89bb..909df57a2f 100644 --- a/tests/acceptance/features/coreApiShareReshareToShares2/reShareWithExpiryDate.feature +++ b/tests/acceptance/features/coreApiShareReshareToShares2/reShareWithExpiryDate.feature @@ -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 "" + Given using 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 "" + And the OCS status code should be "" 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 "" + Given using 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 "" + And the OCS status code should be "" 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 "" + Given using 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 "" + And the OCS status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature b/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature index 132afb1be8..6a0b53d5a3 100644 --- a/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature +++ b/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature @@ -10,7 +10,7 @@ Feature: sharing @smokeTest Scenario Outline: allow modification of reshare - Given using OCS API version "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + And the HTTP status code should be "" 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 "" + Given using 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 | | Then the OCS status code should be "400" - And the HTTP status code should be "" + And the HTTP status code should be "" # 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 "" + Given using 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 | | Then the OCS status code should be "400" - And the HTTP status code should be "" + And the HTTP status code should be "" # 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 "" + Given using 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 "" + Then the OCS status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiShareUpdateToShares/updateShareGroupAndUserWithSameName.feature b/tests/acceptance/features/coreApiShareUpdateToShares/updateShareGroupAndUserWithSameName.feature index bde7cf7340..f32b237253 100644 --- a/tests/acceptance/features/coreApiShareUpdateToShares/updateShareGroupAndUserWithSameName.feature +++ b/tests/acceptance/features/coreApiShareUpdateToShares/updateShareGroupAndUserWithSameName.feature @@ -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 "" + Given using 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 "" + And the OCS status code should be "" 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 "" + Given using 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 "" + And the OCS status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiSharees/sharees.feature b/tests/acceptance/features/coreApiSharees/sharees.feature index 069bd6e22f..dd5176c9c2 100644 --- a/tests/acceptance/features/coreApiSharees/sharees.feature +++ b/tests/acceptance/features/coreApiSharees/sharees.feature @@ -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 "" + Then the OCS status code should be "" 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 "" + Then the OCS status code should be "" 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 "" + Then the OCS status code should be "" 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 "" + Then the OCS status code should be "" 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 "" + Then the OCS status code should be "" 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 "" + Then the OCS status code should be "" 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 "" + Then the OCS status code should be "" 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 "" + Then the OCS status code should be "" 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 "" + Then the OCS status code should be "" 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 | diff --git a/tests/acceptance/features/coreApiTrashbin/trashbinDelete.feature b/tests/acceptance/features/coreApiTrashbin/trashbinDelete.feature index 6578776766..508e216989 100644 --- a/tests/acceptance/features/coreApiTrashbin/trashbinDelete.feature +++ b/tests/acceptance/features/coreApiTrashbin/trashbinDelete.feature @@ -18,20 +18,20 @@ Feature: files and folders can be deleted from the trashbin Given using 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 "" - And user "Alice" has deleted file "" + And user "Alice" has deleted file "" + And user "Alice" has deleted file "" 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 "" should not exist in the trashbin - And as "Alice" the file with original path "" should not exist in the trashbin + And as "Alice" the file with original path "" should not exist in the trashbin + And as "Alice" the file with original path "" 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 | diff --git a/tests/acceptance/features/coreApiTrashbin/trashbinFilesFolders.feature b/tests/acceptance/features/coreApiTrashbin/trashbinFilesFolders.feature index a475f967ba..40174bf53b 100644 --- a/tests/acceptance/features/coreApiTrashbin/trashbinFilesFolders.feature +++ b/tests/acceptance/features/coreApiTrashbin/trashbinFilesFolders.feature @@ -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 - And user "" has been created with default attributes and without skeleton files - And user "" has uploaded file with content "to delete" to "/textfile0.txt" - When user "" deletes file "/textfile0.txt" using the WebDAV API + And user "" has been created with default attributes and without skeleton files + And user "" has uploaded file with content "to delete" to "/textfile0.txt" + When user "" deletes file "/textfile0.txt" using the WebDAV API Then the HTTP status code should be "204" - And as "" file "/textfile0.txt" should exist in the trashbin - But as "" file "/textfile0.txt" should not exist + And as "" file "/textfile0.txt" should exist in the trashbin + But as "" 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 | diff --git a/tests/acceptance/features/coreApiTrashbinRestore/trashbinRestore.feature b/tests/acceptance/features/coreApiTrashbinRestore/trashbinRestore.feature index ab911fd233..6d9c9dbd2e 100644 --- a/tests/acceptance/features/coreApiTrashbinRestore/trashbinRestore.feature +++ b/tests/acceptance/features/coreApiTrashbinRestore/trashbinRestore.feature @@ -178,15 +178,15 @@ Feature: restore deleted files/folders Scenario Outline: files with strange names can be restored Given using DAV path - And user "Alice" has uploaded file with content "file original content" to "" - And user "Alice" has deleted file "" - And user "Alice" restores the file with original path "" using the trashbin API + And user "Alice" has uploaded file with content "file original content" to "" + And user "Alice" has deleted file "" + And user "Alice" restores the file with original path "" using the trashbin API Then the HTTP status code should be "201" - And as "Alice" the file with original path "" should not exist in the trashbin - And as "Alice" file "" should exist - And the content of file "" for user "Alice" should be "file original content" + And as "Alice" the file with original path "" should not exist in the trashbin + And as "Alice" file "" should exist + And the content of file "" 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 | diff --git a/tests/acceptance/features/coreApiVersions/fileVersions.feature b/tests/acceptance/features/coreApiVersions/fileVersions.feature index 56e1180aa3..2607caf0bf 100644 --- a/tests/acceptance/features/coreApiVersions/fileVersions.feature +++ b/tests/acceptance/features/coreApiVersions/fileVersions.feature @@ -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" diff --git a/tests/acceptance/features/coreApiWebdavDelete/deleteFile.feature b/tests/acceptance/features/coreApiWebdavDelete/deleteFile.feature index 2e8f14cc10..3a856f5cd5 100644 --- a/tests/acceptance/features/coreApiWebdavDelete/deleteFile.feature +++ b/tests/acceptance/features/coreApiWebdavDelete/deleteFile.feature @@ -46,13 +46,13 @@ Feature: delete file Scenario Outline: delete file from folder with dots in the path Given using DAV path - And user "Alice" has created folder "" - And user "Alice" has uploaded file with content "uploaded content for file name with dots" to "/" - When user "Alice" deletes file "/" using the WebDAV API + And user "Alice" has created folder "" + And user "Alice" has uploaded file with content "uploaded content for file name with dots" to "/" + When user "Alice" deletes file "/" using the WebDAV API Then the HTTP status code should be "204" - And as "Alice" file "/" should not exist + And as "Alice" file "/" 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 - And user "Alice" has uploaded file with content "file with comma in filename" to - When user "Alice" deletes file using the WebDAV API + And user "Alice" has uploaded file with content "file with comma in filename" to + When user "Alice" deletes file using the WebDAV API Then the HTTP status code should be "204" - And as "Alice" file should not exist + And as "Alice" file 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 | ",,,.," | diff --git a/tests/acceptance/features/coreApiWebdavDelete/deleteFolder.feature b/tests/acceptance/features/coreApiWebdavDelete/deleteFolder.feature index f86ee25811..28e0d518da 100644 --- a/tests/acceptance/features/coreApiWebdavDelete/deleteFolder.feature +++ b/tests/acceptance/features/coreApiWebdavDelete/deleteFolder.feature @@ -64,12 +64,12 @@ Feature: delete folder Scenario Outline: deleting folder with dot in the name Given using DAV path - And user "Alice" has created folder "" - When user "Alice" deletes folder "" using the WebDAV API + And user "Alice" has created folder "" + When user "Alice" deletes folder "" using the WebDAV API Then the HTTP status code should be "204" - And as "Alice" folder "" should not exist + And as "Alice" folder "" 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.. | diff --git a/tests/acceptance/features/coreApiWebdavMove1/moveFolder.feature b/tests/acceptance/features/coreApiWebdavMove1/moveFolder.feature index d7760ef269..52474528c9 100644 --- a/tests/acceptance/features/coreApiWebdavMove1/moveFolder.feature +++ b/tests/acceptance/features/coreApiWebdavMove1/moveFolder.feature @@ -103,13 +103,13 @@ Feature: move (rename) folder Scenario Outline: renaming folder with dots in the path Given using DAV path - And user "Alice" has created folder "" - And user "Alice" has uploaded file with content "uploaded content for file name ending with a dot" to "/abc.txt" - When user "Alice" moves folder "" to "/uploadFolder" using the WebDAV API + And user "Alice" has created folder "" + And user "Alice" has uploaded file with content "uploaded content for file name ending with a dot" to "/abc.txt" + When user "Alice" moves folder "" 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.. | diff --git a/tests/acceptance/features/coreApiWebdavMove2/moveFile.feature b/tests/acceptance/features/coreApiWebdavMove2/moveFile.feature index 5eba558a66..6198535f36 100644 --- a/tests/acceptance/features/coreApiWebdavMove2/moveFile.feature +++ b/tests/acceptance/features/coreApiWebdavMove2/moveFile.feature @@ -250,13 +250,13 @@ Feature: move (rename) file Scenario Outline: renaming file with dots in the path Given using DAV path - And user "Alice" has created folder "" - And user "Alice" has uploaded file with content "uploaded content for file name ending with a dot" to "/" - When user "Alice" moves file "/" to "/abc.txt" using the WebDAV API + And user "Alice" has created folder "" + And user "Alice" has uploaded file with content "uploaded content for file name ending with a dot" to "/" + When user "Alice" moves file "/" to "/abc.txt" using the WebDAV API Then the HTTP status code should be "201" - And as "Alice" file "/abc.txt" should exist + And as "Alice" file "/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 - And user "Alice" has created folder "" - And user "Alice" has created folder "" - And user "Alice" has uploaded file with content "ownCloud test text file 0" to "//" - When user "Alice" moves file "//" to "//" using the WebDAV API + And user "Alice" has created folder "" + And user "Alice" has created folder "" + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "//" + When user "Alice" moves file "//" to "//" 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 "//" for user "Alice" should be "ownCloud test text file 0" + And the content of 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 - And user "Alice" has created folder "" - And user "Alice" has uploaded file with content "ownCloud test text file 0" to "//" - When user "Alice" moves file "//" to "/" using the WebDAV API + And user "Alice" has created folder "" + And user "Alice" has uploaded file with content "ownCloud test text file 0" to "//" + When user "Alice" moves file "//" to "/" 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 "/" for user "Alice" should be "ownCloud test text file 0" + And the content of 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 diff --git a/tests/acceptance/features/coreApiWebdavMove2/moveShareOnOcis.feature b/tests/acceptance/features/coreApiWebdavMove2/moveShareOnOcis.feature index da4e86296d..0668570a09 100644 --- a/tests/acceptance/features/coreApiWebdavMove2/moveShareOnOcis.feature +++ b/tests/acceptance/features/coreApiWebdavMove2/moveShareOnOcis.feature @@ -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 diff --git a/tests/acceptance/features/coreApiWebdavOperations/downloadFile.feature b/tests/acceptance/features/coreApiWebdavOperations/downloadFile.feature index a028ceada2..ccf5d2e5f3 100644 --- a/tests/acceptance/features/coreApiWebdavOperations/downloadFile.feature +++ b/tests/acceptance/features/coreApiWebdavOperations/downloadFile.feature @@ -117,12 +117,12 @@ Feature: download file Scenario Outline: download a file with comma in the filename Given using DAV path - And user "Alice" has uploaded file with content "file with comma in filename" to - When user "Alice" downloads file using the WebDAV API + And user "Alice" has uploaded file with content "file with comma in filename" to + When user "Alice" downloads file 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 - And user "Alice" has uploaded file with content "test file" to "/" - When user "Alice" downloads file "/" using the WebDAV API + And user "Alice" has uploaded file with content "test file" to "/" + When user "Alice" downloads file "/" 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''""; filename="" | - | 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''""; filename="" | + | 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 | diff --git a/tests/acceptance/features/coreApiWebdavOperations/propfind.feature b/tests/acceptance/features/coreApiWebdavOperations/propfind.feature index 51283dda70..9fae2789e4 100644 --- a/tests/acceptance/features/coreApiWebdavOperations/propfind.feature +++ b/tests/acceptance/features/coreApiWebdavOperations/propfind.feature @@ -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 "" with "PROPFIND" using basic auth + When user "Alice" requests "" 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 "" with "PROPFIND" using basic auth and with headers | header | value | | depth | | - Then the HTTP status code should be "" + Then the HTTP status code should be "" 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 diff --git a/tests/acceptance/features/coreApiWebdavPreviews/previews.feature b/tests/acceptance/features/coreApiWebdavPreviews/previews.feature index afcae4a129..58c543a397 100644 --- a/tests/acceptance/features/coreApiWebdavPreviews/previews.feature +++ b/tests/acceptance/features/coreApiWebdavPreviews/previews.feature @@ -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 - And user "Alice" has uploaded file "filesForUpload/" to "/" - When user "Alice" downloads the preview of "/" with width "32" and height "32" using the WebDAV API + And user "Alice" has uploaded file "filesForUpload/" to "/" + When user "Alice" downloads the preview of "/" 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 - And user "Alice" has uploaded file "filesForUpload/" to "/" - When user "Alice" downloads the preview of "/" with width "32" and height "32" using the WebDAV API + And user "Alice" has uploaded file "filesForUpload/" to "/" + When user "Alice" downloads the preview of "/" 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 And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file "filesForUpload/" to "/" - And user "Alice" has shared file "/" with user "Brian" - When user "Brian" downloads the preview of shared resource "/Shares/" with width "32" and height "32" using the WebDAV API + And user "Alice" has uploaded file "filesForUpload/" to "/" + And user "Alice" has shared file "/" with user "Brian" + When user "Brian" downloads the preview of shared resource "/Shares/" 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 | diff --git a/tests/acceptance/features/coreApiWebdavPreviews/previewsAutoAdustedSizing.feature b/tests/acceptance/features/coreApiWebdavPreviews/previewsAutoAdustedSizing.feature index a6566dee20..3793f9829e 100644 --- a/tests/acceptance/features/coreApiWebdavPreviews/previewsAutoAdustedSizing.feature +++ b/tests/acceptance/features/coreApiWebdavPreviews/previewsAutoAdustedSizing.feature @@ -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 and height using the WebDAV API + When user "Alice" downloads the preview of "/parent.txt" with width and height using the WebDAV API Then the HTTP status code should be "200" - And the downloaded image should be pixels wide and pixels high + And the downloaded image should be pixels wide and 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 | diff --git a/tests/acceptance/features/coreApiWebdavProperties/createFileFolder.feature b/tests/acceptance/features/coreApiWebdavProperties/createFileFolder.feature index ae7e9c4001..07b5b27f17 100644 --- a/tests/acceptance/features/coreApiWebdavProperties/createFileFolder.feature +++ b/tests/acceptance/features/coreApiWebdavProperties/createFileFolder.feature @@ -10,11 +10,11 @@ Feature: create files and folder Scenario Outline: create a folder Given using DAV path - When user "Alice" creates folder "" using the WebDAV API + When user "Alice" creates folder "" using the WebDAV API Then the HTTP status code should be "201" - And as "Alice" folder "" should exist + And as "Alice" folder "" 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 - When user "Alice" uploads file with content "some text" to "" using the WebDAV API + When user "Alice" uploads file with content "some text" to "" using the WebDAV API Then the HTTP status code should be "201" - And as "Alice" file "" should exist - And the content of file "" for user "Alice" should be "some text" + And as "Alice" file "" should exist + And the content of file "" 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 | diff --git a/tests/acceptance/features/coreApiWebdavProperties/createFileFolderWhenSharesExist.feature b/tests/acceptance/features/coreApiWebdavProperties/createFileFolderWhenSharesExist.feature index 0c3efd01cc..895667401c 100644 --- a/tests/acceptance/features/coreApiWebdavProperties/createFileFolderWhenSharesExist.feature +++ b/tests/acceptance/features/coreApiWebdavProperties/createFileFolderWhenSharesExist.feature @@ -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 - When user "Brian" creates folder "" using the WebDAV API + When user "Brian" creates folder "" using the WebDAV API Then the HTTP status code should be "201" - And as "Brian" folder "" should exist + And as "Brian" folder "" 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 - When user "Brian" uploads file with content "some text" to "" using the WebDAV API + When user "Brian" uploads file with content "some text" to "" using the WebDAV API Then the HTTP status code should be "201" - And the content of file "" for user "Brian" should be "some text" + And the content of file "" 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 | diff --git a/tests/acceptance/features/coreApiWebdavProperties/getFileProperties.feature b/tests/acceptance/features/coreApiWebdavProperties/getFileProperties.feature index 87ddf0df68..02738b93d9 100644 --- a/tests/acceptance/features/coreApiWebdavProperties/getFileProperties.feature +++ b/tests/acceptance/features/coreApiWebdavProperties/getFileProperties.feature @@ -10,12 +10,12 @@ Feature: get file properties @smokeTest Scenario Outline: user sends a PROPFIND request on various file names Given using DAV path - And user "Alice" has uploaded file with content "uploaded content" to "" - When user "Alice" gets the properties of file "" using the WebDAV API + And user "Alice" has uploaded file with content "uploaded content" to "" + When user "Alice" gets the properties of file "" 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 - And user "Alice" has uploaded file with content "uploaded content" to "" - When user "Alice" gets the properties of file "" using the WebDAV API + And user "Alice" has uploaded file with content "uploaded content" to "" + When user "Alice" gets the properties of file "" 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 "" in the response to user "Alice" + And there should be an entry with href containing "" 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 - And user "Alice" has created folder "" - And user "Alice" has uploaded file with content "uploaded content" to "/file1.txt" - And user "Alice" has uploaded file with content "uploaded content" to "/file2.txt" - When user "Alice" gets the properties of folder "" with depth 1 using the WebDAV API + And user "Alice" has created folder "" + And user "Alice" has uploaded file with content "uploaded content" to "/file1.txt" + And user "Alice" has uploaded file with content "uploaded content" to "/file2.txt" + When user "Alice" gets the properties of folder "" with depth 1 using the WebDAV API Then the HTTP status code should be "207" - And there should be an entry with href containing "/" in the response to user "Alice" - And there should be an entry with href containing "/file1.txt" in the response to user "Alice" - And there should be an entry with href containing "/file2.txt" in the response to user "Alice" + And there should be an entry with href containing "/" in the response to user "Alice" + And there should be an entry with href containing "/file1.txt" in the response to user "Alice" + And there should be an entry with href containing "/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 - And user "Alice" has created folder "" - And user "Alice" has uploaded file with content "uploaded content" to "/" - When user "Alice" gets the properties of file "/" using the WebDAV API + And user "Alice" has created folder "" + And user "Alice" has uploaded file with content "uploaded content" to "/" + When user "Alice" gets the properties of file "/" 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 | diff --git a/tests/acceptance/features/coreApiWebdavProperties/getQuota.feature b/tests/acceptance/features/coreApiWebdavProperties/getQuota.feature index 6811716660..eeaf462ac0 100644 --- a/tests/acceptance/features/coreApiWebdavProperties/getQuota.feature +++ b/tests/acceptance/features/coreApiWebdavProperties/getQuota.feature @@ -45,13 +45,13 @@ Feature: get quota | shareType | user | | permissions | all | | shareWith | Alice | - When user "Alice" gets the following properties of folder "" inside space "Shares" using the WebDAV API + When user "Alice" gets the following properties of folder "" 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 | diff --git a/tests/acceptance/features/coreApiWebdavProperties/setFileProperties.feature b/tests/acceptance/features/coreApiWebdavProperties/setFileProperties.feature index 8d7f2bcbd6..0210a764be 100644 --- a/tests/acceptance/features/coreApiWebdavProperties/setFileProperties.feature +++ b/tests/acceptance/features/coreApiWebdavProperties/setFileProperties.feature @@ -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 DAV path + Given using 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 DAV path + And using 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 | diff --git a/tests/acceptance/features/coreApiWebdavUpload/uploadFile.feature b/tests/acceptance/features/coreApiWebdavUpload/uploadFile.feature index 1990756297..1653acf0c5 100644 --- a/tests/acceptance/features/coreApiWebdavUpload/uploadFile.feature +++ b/tests/acceptance/features/coreApiWebdavUpload/uploadFile.feature @@ -10,13 +10,13 @@ Feature: upload file @smokeTest Scenario Outline: upload a file and check etag and download content Given using DAV path - When user "Alice" uploads file with content "uploaded content" to "" using the WebDAV API + When user "Alice" uploads file with content "uploaded content" to "" 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 "" for user "Alice" should be "uploaded content" + And the content of file "" 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 - When user "Alice" uploads file with content "uploaded content" to using the WebDAV API + When user "Alice" uploads file with content "uploaded content" to using the WebDAV API Then the HTTP status code should be "201" - And the content of file for user "Alice" should be "uploaded content" + And the content of file 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 - When user "Alice" uploads file with content "uploaded content" to using the WebDAV API + When user "Alice" uploads file with content "uploaded content" to using the WebDAV API Then the HTTP status code should be "201" - And the content of file for user "Alice" should be "uploaded content" + And the content of file 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 - When user "Alice" uploads file with content "file with comma" to using the WebDAV API + When user "Alice" uploads file with content "file with comma" to using the WebDAV API Then the HTTP status code should be "201" - And the content of file for user "Alice" should be "file with comma" + And the content of file 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 - And user "Alice" has created folder "" - When user "Alice" uploads file with content "uploaded content" to "/" using the WebDAV API + And user "Alice" has created folder "" + When user "Alice" uploads file with content "uploaded content" to "/" using the WebDAV API Then the HTTP status code should be "201" - And the content of file "/" for user "Alice" should be "uploaded content" + And the content of file "/" 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 - And user "Alice" has created folder "" - When user "Alice" uploads file with content "uploaded content" to "/" using the WebDAV API + And user "Alice" has created folder "" + When user "Alice" uploads file with content "uploaded content" to "/" using the WebDAV API Then the HTTP status code should be "201" - And the content of file "/" for user "Alice" should be "uploaded content" + And the content of file "/" 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 - And user "Alice" has created folder "" - When user "Alice" uploads file with content "uploaded content for file name ending with a dot" to "/" using the WebDAV API + And user "Alice" has created folder "" + When user "Alice" uploads file with content "uploaded content for file name ending with a dot" to "/" using the WebDAV API Then the HTTP status code should be "201" - And as "Alice" file "//" should exist - And the content of file "/" for user "Alice" should be "uploaded content for file name ending with a dot" + And as "Alice" file "//" should exist + And the content of file "/" 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 | diff --git a/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature b/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature index 75e4aefb5b..ce0e0d8a54 100644 --- a/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature +++ b/tests/acceptance/features/coreApiWebdavUploadTUS/checksums.feature @@ -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 "" 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 "" 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 "" 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 "" 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 "" 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 "" 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 "" 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 "" 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 "" 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 "" 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 | diff --git a/tests/acceptance/features/coreApiWebdavUploadTUS/uploadFile.feature b/tests/acceptance/features/coreApiWebdavUploadTUS/uploadFile.feature index 9337ad7f20..ea3f1e6896 100644 --- a/tests/acceptance/features/coreApiWebdavUploadTUS/uploadFile.feature +++ b/tests/acceptance/features/coreApiWebdavUploadTUS/uploadFile.feature @@ -9,10 +9,10 @@ Feature: upload file Scenario Outline: upload a file and check download content Given using DAV path - When user "Alice" uploads file with content "uploaded content" to "" using the TUS protocol on the WebDAV API - Then the content of file "" for user "Alice" should be "uploaded content" + When user "Alice" uploads file with content "uploaded content" to "" using the TUS protocol on the WebDAV API + Then the content of file "" 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 - And user "Alice" has created folder "" - When user "Alice" uploads file with content "uploaded content" to "/" using the TUS protocol on the WebDAV API - Then the content of file "/" for user "Alice" should be "uploaded content" + And user "Alice" has created folder "" + When user "Alice" uploads file with content "uploaded content" to "/" using the TUS protocol on the WebDAV API + Then the content of file "/" 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 should not exist + And as "Alice" file 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= |