From 3f2e1ce516321ce011ea6fcaf9b0f9bbaac0e326 Mon Sep 17 00:00:00 2001 From: Prarup Gurung Date: Wed, 1 Feb 2023 12:18:19 +0545 Subject: [PATCH] Removed core bug demonstration scenarios --- .../createShareReceivedInMultipleWays.feature | 6 +- ...hareReceivedMultipleWaysIssue39347.feature | 130 ------------------ .../createPublicLinkShare.feature | 4 +- ...reatePublicLinkShareOc10Issue37605.feature | 31 ----- .../copyFromPublicLink.feature | 4 +- .../copyFromPublicLinkOc10Issue37683.feature | 37 ----- .../updatePublicLinkShare.feature | 89 +----------- ...pdatePublicLinkShareOc10Issue37653.feature | 47 ------- .../reShareWithExpiryDate.feature | 6 +- ...eShareWithExpiryDateOc10Issue37013.feature | 110 --------------- .../trashbinFilesFolders.feature | 2 +- ...trashbinFilesFoldersOc10Issue23151.feature | 43 ------ .../trashbinRestore.feature | 2 +- .../trashbinRestoreOc10Issue35974.feature | 34 ----- .../coreApiWebdavLocks/exclusiveLocks.feature | 2 +- .../exclusiveLocksOc10Issue34358.feature | 22 --- .../requestsWithToken.feature | 4 +- .../requestsWithTokenOc10Issue34338.feature | 25 ---- .../requestsWithTokenOc10Issue34360.feature | 29 ---- .../coreApiWebdavLocksUnlock/unlock.feature | 2 +- .../unlockOc10Issue34302.feature | 19 --- ...eToBlacklistedNameUsingOldChunking.feature | 6 +- ...NameUsingOldChunkingOc10Issue36645.feature | 39 ------ ...oExcludedDirectoryUsingOldChunking.feature | 6 +- ...toryUsingOldChunkingOc10Issue36645.feature | 42 ------ .../uploadFileUsingOldChunking.feature | 4 +- ...FileUsingOldChunkingOc10Issue36115.feature | 43 ------ 27 files changed, 25 insertions(+), 763 deletions(-) delete mode 100644 tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedMultipleWaysIssue39347.feature delete mode 100644 tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShareOc10Issue37605.feature delete mode 100644 tests/acceptance/features/coreApiSharePublicLink2/copyFromPublicLinkOc10Issue37683.feature delete mode 100644 tests/acceptance/features/coreApiShareReshareToShares3/reShareWithExpiryDateOc10Issue37013.feature delete mode 100644 tests/acceptance/features/coreApiTrashbin/trashbinFilesFoldersOc10Issue23151.feature delete mode 100644 tests/acceptance/features/coreApiTrashbinRestore/trashbinRestoreOc10Issue35974.feature delete mode 100644 tests/acceptance/features/coreApiWebdavLocks/exclusiveLocksOc10Issue34358.feature delete mode 100644 tests/acceptance/features/coreApiWebdavLocks/requestsWithTokenOc10Issue34338.feature delete mode 100644 tests/acceptance/features/coreApiWebdavLocks/requestsWithTokenOc10Issue34360.feature delete mode 100644 tests/acceptance/features/coreApiWebdavLocksUnlock/unlockOc10Issue34302.feature delete mode 100644 tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunkingOc10Issue36645.feature delete mode 100644 tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingOldChunkingOc10Issue36645.feature delete mode 100644 tests/acceptance/features/coreApiWebdavUpload2/uploadFileUsingOldChunkingOc10Issue36115.feature diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature index 0c98008bdfd..4a2eb030078 100644 --- a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature +++ b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature @@ -536,7 +536,7 @@ Feature: share resources where the sharee receives the share in multiple ways | path | | /child1 | - @skipOnOcV10 @issue-39347 + Scenario Outline: Share receiver renames the received group share and shares same folder through user share again Given using OCS API version "" And group "grp" has been created @@ -567,7 +567,7 @@ Feature: share resources where the sharee receives the share in multiple ways | 1 | 100 | | 2 | 200 | - @skipOnOcV10 @issue-39347 + Scenario Outline: Share receiver renames a group share and receives same resource through user share with additional permissions Given using OCS API version "" And group "grp" has been created @@ -596,7 +596,7 @@ Feature: share resources where the sharee receives the share in multiple ways | 1 | | 2 | - @skipOnOcV10 @issue-39347 + Scenario Outline: Share receiver renames a group share and receives same resource through user share with less permissions Given using OCS API version "" And group "grp" has been created diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedMultipleWaysIssue39347.feature b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedMultipleWaysIssue39347.feature deleted file mode 100644 index de6cc55f527..00000000000 --- a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedMultipleWaysIssue39347.feature +++ /dev/null @@ -1,130 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: share resources where the sharee receives the share in multiple ways - - # These are the bug demonstration scenarios for https://github.com/owncloud/core/issues/39347 - # Once the issue is fixed, delete this file and unskip all the respective tests tagged with @issue-39347 - Background: - Given the administrator has set the default folder for received shares to "Shares" - And auto-accept shares has been disabled - And these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - - - Scenario Outline: Share receiver renames the received group share and shares same folder through user share again - 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" - And user "Alice" has created folder "parent" - And user "Alice" has created folder "parent/child" - And user "Alice" has uploaded file with content "Share content" to "parent/child/lorem.txt" - And user "Alice" has created a share with settings - | path | parent | - | shareType | group | - | shareWith | grp | - | permissions | read | - When user "Brian" accepts share "/parent" offered by user "Alice" using the sharing API - Then the HTTP status code should be "200" - And the OCS status code should be "" - And user "Brian" should be able to rename folder "/Shares/parent" to "/Shares/sharedParent" - And user "Alice" should be able to share folder "parent" with user "Brian" with permissions "read" using the sharing API - And user "Brian" should be able to accept pending share "/parent" offered by user "Alice" - And as "Brian" folder "Shares/parent" should exist - And as "Brian" folder "Shares/sharedParent" should not exist - And as "Brian" file "Shares/sharedParent/child/lorem.txt" should not exist - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - # Note: after fixing the bug, this scenario is no longer relevant. - # Brian should not get a chance to decline (or accept) the 2nd share of the resource from Alice - Scenario Outline: Share receiver renames the received group share and declines another share of same folder through user share again - 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" - And user "Alice" has created folder "parent" - And user "Alice" has created folder "parent/child" - And user "Alice" has uploaded file with content "Share content" to "parent/child/lorem.txt" - And user "Alice" has created a share with settings - | path | parent | - | shareType | group | - | shareWith | grp | - | permissions | read | - When user "Brian" accepts share "/parent" offered by user "Alice" using the sharing API - Then the HTTP status code should be "200" - And the OCS status code should be "" - And user "Brian" should be able to rename folder "/Shares/parent" to "/Shares/sharedParent" - And user "Alice" should be able to share folder "parent" with user "Brian" with permissions "read" using the sharing API - And user "Brian" should be able to decline pending share "/parent" offered by user "Alice" - And as "Brian" folder "Shares/parent" should not exist - And as "Brian" folder "Shares/sharedParent" should not exist - And as "Brian" file "Shares/sharedParent/child/lorem.txt" should not exist - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: Share receiver renames a group share and receives same resource through user share with additional permissions - 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" - And user "Alice" has created folder "parent" - And user "Alice" has created folder "parent/child" - And user "Alice" has uploaded file with content "Share content" to "parent/child/lorem.txt" - And user "Alice" has created a share with settings - | path | parent | - | shareType | group | - | shareWith | grp | - | permissions | read | - When user "Brian" accepts share "/parent" offered by user "Alice" using the sharing API - Then the HTTP status code should be "200" - And the OCS status code should be "" - And user "Brian" should be able to rename folder "/Shares/parent" to "/Shares/sharedParent" - And user "Alice" should be able to share folder "parent" with user "Brian" with permissions "all" using the sharing API - And user "Brian" should be able to accept pending share "/parent" offered by user "Alice" - And as "Brian" folder "Shares/parent" should exist - And as "Brian" folder "Shares/sharedParent" should not exist - And as "Brian" file "Shares/sharedParent/child/lorem.txt" should not exist - And as "Brian" file "Shares/parent/child/lorem.txt" should exist - And user "Brian" should be able to delete file "Shares/parent/child/lorem.txt" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: Share receiver renames a group share and receives same resource through user share with less permissions - 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" - And user "Alice" has created folder "parent" - And user "Alice" has created folder "parent/child" - And user "Alice" has uploaded file with content "Share content" to "parent/child/lorem.txt" - And user "Alice" has created a share with settings - | path | parent | - | shareType | group | - | shareWith | grp | - | permissions | all | - When user "Brian" accepts share "/parent" offered by user "Alice" using the sharing API - Then the HTTP status code should be "200" - And the OCS status code should be "" - And user "Brian" should be able to rename folder "/Shares/parent" to "/Shares/sharedParent" - And user "Alice" should be able to share folder "parent" with user "Brian" with permissions "read" using the sharing API - And user "Brian" should be able to accept pending share "/parent" offered by user "Alice" - And as "Brian" folder "Shares/parent" should exist - And as "Brian" folder "Shares/sharedParent" should not exist - And as "Brian" file "Shares/sharedParent/child/lorem.txt" should not exist - And as "Brian" file "Shares/parent/child/lorem.txt" should exist - And user "Brian" should be able to delete file "Shares/parent/child/lorem.txt" - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | diff --git a/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShare.feature b/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShare.feature index b02ef09f1d1..6cf6d1ff63c 100644 --- a/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShare.feature +++ b/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShare.feature @@ -587,7 +587,7 @@ Feature: create a public link share | old | | new | - @issue-37605 @skipOnOcV10 + Scenario: Get the mtime of a file inside a folder shared by public link using new webDAV version Given user "Alice" has created folder "testFolder" And user "Alice" has created a public link share with settings @@ -599,7 +599,7 @@ Feature: create a public link share And as "Alice" the mtime of the file "testFolder/file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT" And the mtime of file "file.txt" in the last shared public link using the WebDAV API should be "Thu, 08 Aug 2019 04:18:13 GMT" - @issue-37605 @skipOnOcV10 + Scenario: overwriting a file changes its mtime (new public webDAV API) Given user "Alice" has created folder "testFolder" When user "Alice" uploads file with content "uploaded content for file name ending with a dot" to "testFolder/file.txt" using the WebDAV API diff --git a/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShareOc10Issue37605.feature b/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShareOc10Issue37605.feature deleted file mode 100644 index 22fd35fbc80..00000000000 --- a/tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShareOc10Issue37605.feature +++ /dev/null @@ -1,31 +0,0 @@ -@api @files_sharing-app-required @public_link_share-feature-required @notToImplementOnOCIS - -Feature: create a public link share - - Background: - Given user "Alice" has been created with default attributes and without skeleton files - And user "Alice" has created folder "testFolder" - And user "Alice" has created a public link share with settings - | path | /testFolder | - | permissions | read,update,create,delete | - - @issue-37605 - Scenario: Get the mtime of a file inside a folder shared by public link using new webDAV version - When the public uploads file "file.txt" to the last public link shared folder with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the new public WebDAV API - Then the HTTP status code should be "201" - And as "Alice" file "testFolder/file.txt" should exist - And as "Alice" the mtime of the file "testFolder/file.txt" should not be "Thu, 08 Aug 2019 04:18:13 GMT" -# And as "Alice" the mtime of the file "testFolder/file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT" - And the mtime of file "file.txt" in the last shared public link using the WebDAV API should not be "Thu, 08 Aug 2019 04:18:13 GMT" -# And the mtime of file "file.txt" in the last shared public link using the WebDAV API should be "Thu, 08 Aug 2019 04:18:13 GMT" - - @issue-37605 - Scenario: overwriting a file changes its mtime (new public webDAV API) - Given user "Alice" has uploaded file with content "uploaded content for file name ending with a dot" to "testFolder/file.txt" - When the public uploads file "file.txt" to the last public link shared folder with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the new public WebDAV API - Then the HTTP status code should be "204" - And as "Alice" file "/testFolder/file.txt" should exist - And as "Alice" the mtime of the file "testFolder/file.txt" should not be "Thu, 08 Aug 2019 04:18:13 GMT" -# And as "Alice" the mtime of the file "testFolder/file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT" - And the mtime of file "file.txt" in the last shared public link using the WebDAV API should not be "Thu, 08 Aug 2019 04:18:13 GMT" -# And the mtime of file "file.txt" in the last shared public link using the WebDAV API should be "Thu, 08 Aug 2019 04:18:13 GMT" \ No newline at end of file diff --git a/tests/acceptance/features/coreApiSharePublicLink2/copyFromPublicLink.feature b/tests/acceptance/features/coreApiSharePublicLink2/copyFromPublicLink.feature index 95dfc7f4327..5ec3d4ddd91 100644 --- a/tests/acceptance/features/coreApiSharePublicLink2/copyFromPublicLink.feature +++ b/tests/acceptance/features/coreApiSharePublicLink2/copyFromPublicLink.feature @@ -59,7 +59,7 @@ Feature: copying from public link share And as "Alice" file "/PARENT/copy1.txt" should exist And the content of file "/PARENT/copy1.txt" for user "Alice" should be "some data 0" - @skipOnOcV10 @issue-ocis-reva-373 @issue-37683 + @issue-ocis-reva-373 Scenario: Copy folder within a public link folder to the same folder name as an already existing file Given user "Alice" has created folder "/PARENT/testFolder" And user "Alice" has uploaded file with content "some data" to "/PARENT/testFolder/testfile.txt" @@ -85,7 +85,7 @@ Feature: copying from public link share Then the HTTP status code should be "204" And as "Alice" file "/PARENT/copy1.txt" should not exist - @skipOnOcV10 @issue-ocis-reva-373 @issue-37683 + @issue-ocis-reva-373 Scenario: Copy file within a public link folder to a file with name same as an existing folder Given user "Alice" has uploaded file with content "some data" to "/PARENT/testfile.txt" And user "Alice" has created folder "/PARENT/new-folder" diff --git a/tests/acceptance/features/coreApiSharePublicLink2/copyFromPublicLinkOc10Issue37683.feature b/tests/acceptance/features/coreApiSharePublicLink2/copyFromPublicLinkOc10Issue37683.feature deleted file mode 100644 index cb5f4e005d4..00000000000 --- a/tests/acceptance/features/coreApiSharePublicLink2/copyFromPublicLinkOc10Issue37683.feature +++ /dev/null @@ -1,37 +0,0 @@ -@api @files_sharing-app-required @public_link_share-feature-required @issue-ocis-reva-310 @notToImplementOnOCIS -Feature: copying from public link share - - Background: - Given user "Alice" has been created with default attributes and without skeleton files - And user "Alice" has created folder "/PARENT" - - @issue-ocis-reva-373 @issue-37683 @skipOnLDAP @issue-user_ldap-702 - Scenario: Copy folder within a public link folder to the same folder name as an already existing file - Given user "Alice" has created folder "/PARENT/testFolder" - And user "Alice" has uploaded file with content "some data" to "/PARENT/testFolder/testfile.txt" - And user "Alice" has uploaded file with content "some data 1" to "/PARENT/copy1.txt" - And user "Alice" has created a public link share with settings - | path | /PARENT | - | permissions | read,update,create,delete | - When the public copies folder "/testFolder" to "/copy1.txt" using the new public WebDAV API - Then the HTTP status code should be "204" - And as "Alice" folder "/PARENT/testFolder" should exist - And as "Alice" folder "/PARENT/copy1.txt" should exist - And as "Alice" file "/PARENT/copy1.txt/testfile.txt" should exist - And the content of file "/PARENT/copy1.txt/testfile.txt" for user "Alice" should be "some data" - And the content of file "/PARENT/testFolder/testfile.txt" for user "Alice" should be "some data" - - @issue-ocis-reva-373 @issue-37683 - Scenario: Copy file within a public link folder to a file with name same as an existing folder - Given user "Alice" has uploaded file with content "some data" to "/PARENT/testfile.txt" - And user "Alice" has created folder "/PARENT/new-folder" - And user "Alice" has uploaded file with content "some data 1" to "/PARENT/new-folder/testfile1.txt" - And user "Alice" has created a public link share with settings - | path | /PARENT | - | permissions | read,update,create,delete | - When the public copies file "/testfile.txt" to "/new-folder" using the new public WebDAV API - Then the HTTP status code should be "204" - And as "Alice" file "/PARENT/testfile.txt" should exist - And as "Alice" file "/PARENT/new-folder" should exist - And the content of file "/PARENT/testfile.txt" for user "Alice" should be "some data" - And the content of file "/PARENT/new-folder" for user "Alice" should be "some data" diff --git a/tests/acceptance/features/coreApiSharePublicLink3/updatePublicLinkShare.feature b/tests/acceptance/features/coreApiSharePublicLink3/updatePublicLinkShare.feature index 19e12fa04a6..a8452ed7e90 100644 --- a/tests/acceptance/features/coreApiSharePublicLink3/updatePublicLinkShare.feature +++ b/tests/acceptance/features/coreApiSharePublicLink3/updatePublicLinkShare.feature @@ -5,7 +5,7 @@ Feature: update a public link share Given using OCS API version "1" And user "Alice" has been created with default attributes and without skeleton files - @issue-37653 @skipOnOcV10 + Scenario Outline: API responds with a full set of parameters when owner changes the expireDate of a public share Given using OCS API version "" And user "Alice" has created folder "FOLDER" @@ -78,50 +78,6 @@ Feature: update a public link share | 1 | 100 | | 2 | 200 | - @notToImplementOnOCIS @issue-39820 - Scenario Outline: API responds with a full set of parameters when owner renames the folder with a public link (bug demonstration) - 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 - | path | FOLDER | - 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 "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" should include - | id | A_STRING | - | share_type | public_link | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | permissions | read | - | stime | A_NUMBER | - | parent | | - | expiration | | - | token | A_STRING | - | uid_file_owner | %username% | - | displayname_file_owner | %displayname% | - | additional_info_owner | | - | additional_info_file_owner | | - | item_type | folder | - | item_source | A_STRING | - | path | /RENAMED_FOLDER | - | mimetype | httpd/unix-directory | - | storage_id | A_STRING | - | storage | A_STRING | - | file_source | A_STRING | - # uncomment the following line and remove the next one after the issue has been fixed - # | file_target | /RENAMED_FOLDER | - | file_target | /FOLDER | - | mail_send | 0 | - | name | | - Examples: - | dav-path | ocs_api_version | ocs_status_code | - | old | 1 | 100 | - | old | 2 | 200 | - | new | 1 | 100 | - | new | 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 "" @@ -521,49 +477,6 @@ Feature: update a public link share | spaces | 1 | 100 | | spaces | 2 | 200 | - @notToImplementOnOCIS @issue-39820 - Scenario Outline: API responds with a full set of parameters when owner renames the file with a public link (bug demonstration) - 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 - | path | lorem.txt | - 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 "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" should include - | id | A_STRING | - | share_type | public_link | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | permissions | read | - | stime | A_NUMBER | - | parent | | - | expiration | | - | token | A_STRING | - | uid_file_owner | %username% | - | displayname_file_owner | %displayname% | - | additional_info_owner | | - | additional_info_file_owner | | - | item_type | file | - | item_source | A_STRING | - | path | /new-lorem.txt | - | mimetype | text/plain | - | storage_id | A_STRING | - | storage | A_STRING | - | file_source | A_STRING | - # uncomment the following line and remove the next one after the issue has been fixed - # | file_target | /new-lorem.txt | - | file_target | /lorem.txt | - | mail_send | 0 | - | name | | - Examples: - | dav-path | ocs_api_version | ocs_status_code | - | old | 1 | 100 | - | old | 2 | 200 | - | new | 1 | 100 | - | new | 2 | 200 | @skipOnOcV10 Scenario Outline: API responds with a full set of parameters when owner renames the file with a public link in ocis diff --git a/tests/acceptance/features/coreApiSharePublicLink3/updatePublicLinkShareOc10Issue37653.feature b/tests/acceptance/features/coreApiSharePublicLink3/updatePublicLinkShareOc10Issue37653.feature index 139a6938931..e69de29bb2d 100644 --- a/tests/acceptance/features/coreApiSharePublicLink3/updatePublicLinkShareOc10Issue37653.feature +++ b/tests/acceptance/features/coreApiSharePublicLink3/updatePublicLinkShareOc10Issue37653.feature @@ -1,47 +0,0 @@ -@api @files_sharing-app-required @public_link_share-feature-required @notToImplementOnOCIS -Feature: update a public link share - - Background: - Given using OCS API version "1" - And user "Alice" has been created with default attributes and without skeleton files - - @issue-37653 - Scenario Outline: API responds with a full set of parameters when owner changes the expireDate of a public share - 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 | - 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 "" - And the OCS status message 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 - | id | A_STRING | - | share_type | public_link | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | permissions | read | - | stime | A_NUMBER | - | parent | | - | expiration | A_STRING | - | token | A_STRING | - | uid_file_owner | %username% | - | displayname_file_owner | %displayname% | - | additional_info_owner | | - | additional_info_file_owner | | - | item_type | folder | - | item_source | A_STRING | - | path | /FOLDER | - | mimetype | httpd/unix-directory | - | storage_id | A_STRING | - | storage | A_NUMBER | - | file_source | A_STRING | - | file_target | /FOLDER | - | mail_send | 0 | - | name | | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareReshareToShares3/reShareWithExpiryDate.feature b/tests/acceptance/features/coreApiShareReshareToShares3/reShareWithExpiryDate.feature index 5cbef9a893d..018f239bd83 100644 --- a/tests/acceptance/features/coreApiShareReshareToShares3/reShareWithExpiryDate.feature +++ b/tests/acceptance/features/coreApiShareReshareToShares3/reShareWithExpiryDate.feature @@ -348,7 +348,7 @@ Feature: resharing a resource with an expiration date | 1 | no | 100 | | 2 | no | 200 | - @skipOnOcV10 @issue-37013 + Scenario Outline: reshare extends the received expiry date up to the default by default Given using OCS API version "" And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" @@ -383,7 +383,7 @@ Feature: resharing a resource with an expiration date | 1 | no | no | 100 | | 2 | no | no | 200 | - @skipOnOcV10 @issue-37013 + Scenario Outline: reshare cannot extend the received expiry date further into the future Given using OCS API version "" And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" @@ -415,7 +415,7 @@ Feature: resharing a resource with an expiration date | 1 | no | | 2 | no | - @skipOnOcV10 @issue-37013 + Scenario Outline: reshare cannot extend the received expiry date past the default when the default is enforced Given using OCS API version "" And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" diff --git a/tests/acceptance/features/coreApiShareReshareToShares3/reShareWithExpiryDateOc10Issue37013.feature b/tests/acceptance/features/coreApiShareReshareToShares3/reShareWithExpiryDateOc10Issue37013.feature deleted file mode 100644 index bce4ee0a155..00000000000 --- a/tests/acceptance/features/coreApiShareReshareToShares3/reShareWithExpiryDateOc10Issue37013.feature +++ /dev/null @@ -1,110 +0,0 @@ -@api @files_sharing-app-required @issue-ocis-1250 @notToImplementOnOCIS -Feature: resharing a resource with an expiration date - - Background: - Given the administrator has set the default folder for received shares to "Shares" - And auto-accept shares has been disabled - And these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - - @issue-37013 - Scenario Outline: reshare extends the received expiry date up to the default by default - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" - And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" - And user "Carol" has been created with default attributes and without skeleton files - And user "Alice" has created a share with settings - | path | textfile0.txt | - | shareType | user | - | permissions | all | - | shareWith | Brian | - | expireDate | +20 days | - And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" - When user "Brian" creates a share using the sharing API with settings - | path | /Shares/textfile0.txt | - | shareType | user | - | permissions | change | - | shareWith | Carol | - Then the HTTP status code should be "200" - And the OCS status code should be "" - And user "Carol" should be able to accept pending share "/textfile0.txt" offered by user "Brian" - And the information of the last share of user "Alice" should include - | expiration | +20 days | - And the response when user "Carol" gets the info of the last share should include - | expiration | | - Examples: - | ocs_api_version | default-expire-date | enforce-expire-date | actual-expire-date | ocs_status_code | - | 1 | yes | yes | +30 days | 100 | - | 2 | yes | yes | +30 days | 200 | - | 1 | yes | no | | 100 | - | 2 | yes | no | | 200 | - | 1 | no | no | | 100 | - | 2 | no | no | | 200 | - - @issue-37013 - Scenario Outline: reshare can extend the received expiry date further into the future - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "no" - And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" - And user "Carol" has been created with default attributes and without skeleton files - And user "Alice" has created a share with settings - | path | textfile0.txt | - | shareType | user | - | permissions | all | - | shareWith | Brian | - | expireDate | +20 days | - And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" - When user "Brian" creates a share using the sharing API with settings - | path | /Shares/textfile0.txt | - | shareType | user | - | permissions | change | - | shareWith | Carol | - | expireDate | +40 days | - Then the HTTP status code should be "200" - And the OCS status code should be "" - And user "Carol" should be able to accept pending share "/textfile0.txt" offered by user "Brian" - And the information of the last share of user "Alice" should include - | expiration | +20 days | - And the response when user "Carol" gets the info of the last share should include - | expiration | +40 days | - Examples: - | ocs_api_version | default-expire-date | ocs_status_code | - | 1 | yes | 100 | - | 2 | yes | 200 | - | 1 | no | 100 | - | 2 | no | 200 | - - @issue-37013 - Scenario Outline: reshare cannot extend the received expiry date past the default when the default is enforced - Given using OCS API version "" - And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" - And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" - And user "Carol" has been created with default attributes and without skeleton files - And user "Alice" has created a share with settings - | path | textfile0.txt | - | shareType | user | - | permissions | all | - | shareWith | Brian | - | expireDate | +20 days | - And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" - When user "Brian" creates a share using the sharing API with settings - | path | /Shares/textfile0.txt | - | shareType | user | - | permissions | change | - | shareWith | Carol | - | expireDate | +40 days | - Then the HTTP status code should be "" - And the OCS status code should be "404" - And the sharing API should report to user "Carol" that no shares are in the pending state - And the information of the last share of user "Alice" should include - | expiration | +20 days | - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | diff --git a/tests/acceptance/features/coreApiTrashbin/trashbinFilesFolders.feature b/tests/acceptance/features/coreApiTrashbin/trashbinFilesFolders.feature index df0ce24f161..c7e9dec76ab 100644 --- a/tests/acceptance/features/coreApiTrashbin/trashbinFilesFolders.feature +++ b/tests/acceptance/features/coreApiTrashbin/trashbinFilesFolders.feature @@ -99,7 +99,7 @@ Feature: files and folders exist in the trashbin after being deleted | dav-path | | spaces | - @skipOnOcV10 @issue-23151 + # This scenario deletes many files as close together in time as the test can run. # On a very slow system, the file deletes might all happen in different seconds. # But on "reasonable" systems, some of the files will be deleted in the same second, diff --git a/tests/acceptance/features/coreApiTrashbin/trashbinFilesFoldersOc10Issue23151.feature b/tests/acceptance/features/coreApiTrashbin/trashbinFilesFoldersOc10Issue23151.feature deleted file mode 100644 index 578ed1c9756..00000000000 --- a/tests/acceptance/features/coreApiTrashbin/trashbinFilesFoldersOc10Issue23151.feature +++ /dev/null @@ -1,43 +0,0 @@ -@api @files_trashbin-app-required @issue-ocis-reva-52 @notToImplementOnOCIS -Feature: files and folders exist in the trashbin after being deleted - As a user - I want deleted files and folders to be available in the trashbin - So that I can recover data easily - - Background: - Given user "Alice" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file with content "to delete" to "/textfile0.txt" - - # This scenario deletes many files as close together in time as the test can run. - # On a very slow system, the file deletes might all happen in different seconds. - # But on "reasonable" systems, some of the files will be deleted in the same second, - # thus testing the required behavior. - # Note: skipOnDbOracle because Oracle is slow and so "close together in time" does not really happen - @issue-23151 @skipOnDbOracle - Scenario Outline: trashbin can store two files with the same name but different origins when the files are deleted close together in time - Given using DAV path - And user "Alice" has created folder "/folderA" - And user "Alice" has created folder "/folderB" - And user "Alice" has created folder "/folderC" - And user "Alice" has created folder "/folderD" - And user "Alice" has copied file "/textfile0.txt" to "/folderA/textfile0.txt" - And user "Alice" has copied file "/textfile0.txt" to "/folderB/textfile0.txt" - And user "Alice" has copied file "/textfile0.txt" to "/folderC/textfile0.txt" - And user "Alice" has copied file "/textfile0.txt" to "/folderD/textfile0.txt" - When user "Alice" deletes these files without delays using the WebDAV API - | /textfile0.txt | - | /folderA/textfile0.txt | - | /folderB/textfile0.txt | - | /folderC/textfile0.txt | - | /folderD/textfile0.txt | - Then the HTTP status code of responses on all endpoints should be "204" - # When issue-23151 is fixed, uncomment these lines. They should pass reliably. - # These files may or may not exist in the trashbin -# Then as "Alice" the folder with original path "/folderA/textfile0.txt" should not exist in the trashbin -# And as "Alice" the folder with original path "/folderB/textfile0.txt" should not exist in the trashbin -# And as "Alice" the folder with original path "/folderC/textfile0.txt" should not exist in the trashbin -# And as "Alice" the folder with original path "/folderD/textfile0.txt" should not exist in the trashbin - And as "Alice" the folder with original path "/textfile0.txt" should exist in the trashbin - Examples: - | dav-path | - | new | diff --git a/tests/acceptance/features/coreApiTrashbinRestore/trashbinRestore.feature b/tests/acceptance/features/coreApiTrashbinRestore/trashbinRestore.feature index 950f2fdc537..7294a27a468 100644 --- a/tests/acceptance/features/coreApiTrashbinRestore/trashbinRestore.feature +++ b/tests/acceptance/features/coreApiTrashbinRestore/trashbinRestore.feature @@ -92,7 +92,7 @@ Feature: Restore deleted files/folders | old | /textfile0.txt | PARENT/textfile0.txt | | new | /textfile0.txt | PARENT/textfile0.txt | - @skipOnOcV10 @issue-35974 + Scenario Outline: restoring a file to an already existing path overrides the file Given user "Alice" has uploaded file with content "file to delete" to "/.hiddenfile0.txt" And using DAV path diff --git a/tests/acceptance/features/coreApiTrashbinRestore/trashbinRestoreOc10Issue35974.feature b/tests/acceptance/features/coreApiTrashbinRestore/trashbinRestoreOc10Issue35974.feature deleted file mode 100644 index 3989f7d6e14..00000000000 --- a/tests/acceptance/features/coreApiTrashbinRestore/trashbinRestoreOc10Issue35974.feature +++ /dev/null @@ -1,34 +0,0 @@ -@api @files_trashbin-app-required @issue-ocis-reva-52 @notToImplementOnOCIS -Feature: Restore deleted files/folders - As a user - I would like to restore files/folders - So that I can recover accidentally deleted files/folders in ownCloud - - @issue-35974 - Scenario Outline: restoring a file to an already existing path overrides the file - Given user "Alice" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file with content "file to delete" to "/textfile0.txt" - And user "Alice" has uploaded file with content "file to delete" to "/.hiddenfile0.txt" - And using DAV path - And user "Alice" has created folder "/PARENT" - And user "Alice" has uploaded file with content "PARENT file content" to - And user "Alice" has deleted file - When user "Alice" restores the file with original path to using the trashbin API - Then the HTTP status code should be "204" - # Sometimes is found in the trashbin. Should it? Or not? - # That seems to be what happens when the restore-overwrite happens properly, - # The original seems to be "deleted" and so goes to the trashbin - #And as "Alice" the file with original path should not exist in the trashbin - And as "Alice" file should exist - # sometimes the restore from trashbin does overwrite the existing file, but sometimes it does not. That is also surprising. - # the current observed behavior is that if the original ended up in the trashbin, - # then the new has the "file to delete" content. - # otherwise has its old content - And the content of file for user "Alice" if the file is also in the trashbin should be "file to delete" otherwise "PARENT file content" - #And the content of file for user "Alice" should be "file to delete" - Examples: - | dav-path | upload-path | delete-path | - | old | "/PARENT/textfile0.txt" | "/textfile0.txt" | - | new | "/PARENT/textfile0.txt" | "/textfile0.txt" | - | old | "/PARENT/.hiddenfile0.txt" | ".hiddenfile0.txt" | - | new | "/PARENT/.hiddenfile0.txt" | ".hiddenfile0.txt" | diff --git a/tests/acceptance/features/coreApiWebdavLocks/exclusiveLocks.feature b/tests/acceptance/features/coreApiWebdavLocks/exclusiveLocks.feature index 34850981d3c..e4acb8096e5 100644 --- a/tests/acceptance/features/coreApiWebdavLocks/exclusiveLocks.feature +++ b/tests/acceptance/features/coreApiWebdavLocks/exclusiveLocks.feature @@ -66,7 +66,7 @@ Feature: there can be only one exclusive lock on a resource | new | shared | | new | exclusive | - @skipOnOcV10 @issue-34358 @notToImplementOnOCIS + @notToImplementOnOCIS Scenario Outline: if a child resource is exclusively locked a parent resource cannot be locked again Given using DAV path And user "Alice" has created folder "PARENT" diff --git a/tests/acceptance/features/coreApiWebdavLocks/exclusiveLocksOc10Issue34358.feature b/tests/acceptance/features/coreApiWebdavLocks/exclusiveLocksOc10Issue34358.feature deleted file mode 100644 index 5cd973e747c..00000000000 --- a/tests/acceptance/features/coreApiWebdavLocks/exclusiveLocksOc10Issue34358.feature +++ /dev/null @@ -1,22 +0,0 @@ -@api @notToImplementOnOCIS @issue-ocis-reva-172 -Feature: there can be only one exclusive lock on a resource - - @issue-34358 - Scenario Outline: if a child resource is exclusively locked a parent resource cannot be locked again - Given user "Alice" has been created with default attributes and without skeleton files - 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" - And using DAV path - And user "Alice" has locked folder "PARENT/CHILD" setting the following properties - | lockscope | exclusive | - When user "Alice" locks folder "PARENT" using the WebDAV API setting the following properties - | lockscope | | - Then the HTTP status code should be "200" - And 2 locks should be reported for file "PARENT/CHILD/child.txt" of user "Alice" by the WebDAV API - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavLocks/requestsWithToken.feature b/tests/acceptance/features/coreApiWebdavLocks/requestsWithToken.feature index 40f7cd43663..47d6de925cc 100644 --- a/tests/acceptance/features/coreApiWebdavLocks/requestsWithToken.feature +++ b/tests/acceptance/features/coreApiWebdavLocks/requestsWithToken.feature @@ -63,7 +63,7 @@ Feature: actions on a locked item are possible if the token is sent with the req | new | shared | | new | exclusive | - @skipOnOcV10 @issue-34338 @files_sharing-app-required @notToImplementOnOCIS + @files_sharing-app-required @notToImplementOnOCIS Scenario Outline: share receiver cannot rename a file in a folder locked by the owner even when sending the locktoken Given using DAV path And user "Alice" has created folder "PARENT" @@ -101,7 +101,7 @@ Feature: actions on a locked item are possible if the token is sent with the req | shared | new | 423 | | exclusive | new | 423 | - @skipOnOcV10 @issue-34360 @files_sharing-app-required + @files_sharing-app-required Scenario Outline: two users having both a shared lock can use the resource Given using DAV path And user "Brian" has been created with default attributes and without skeleton files diff --git a/tests/acceptance/features/coreApiWebdavLocks/requestsWithTokenOc10Issue34338.feature b/tests/acceptance/features/coreApiWebdavLocks/requestsWithTokenOc10Issue34338.feature deleted file mode 100644 index 9118ecf63c4..00000000000 --- a/tests/acceptance/features/coreApiWebdavLocks/requestsWithTokenOc10Issue34338.feature +++ /dev/null @@ -1,25 +0,0 @@ -@api @notToImplementOnOCIS @issue-ocis-reva-172 -Feature: actions on a locked item are possible if the token is sent with the request - - @issue-34338 @files_sharing-app-required - Scenario Outline: share receiver cannot rename a file in a folder locked by the owner even when sending the locktoken - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - And using DAV path - And user "Alice" has created folder "PARENT" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" - And user "Alice" has shared folder "PARENT" with user "Brian" - And user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - When user "Brian" moves file "PARENT/parent.txt" to "PARENT/renamed-file.txt" sending the locktoken of file "PARENT" of user "Alice" using the WebDAV API - Then the HTTP status code should be "201" - And as "Alice" file "/PARENT/parent.txt" should not exist - But as "Alice" file "/PARENT/renamed-file.txt" should exist - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavLocks/requestsWithTokenOc10Issue34360.feature b/tests/acceptance/features/coreApiWebdavLocks/requestsWithTokenOc10Issue34360.feature deleted file mode 100644 index e9aafe396ff..00000000000 --- a/tests/acceptance/features/coreApiWebdavLocks/requestsWithTokenOc10Issue34360.feature +++ /dev/null @@ -1,29 +0,0 @@ -@api @notToImplementOnOCIS @issue-ocis-reva-172 -Feature: actions on a locked item are possible if the token is sent with the request - - @issue-34360 @files_sharing-app-required - Scenario Outline: two users having both a shared lock can use the resource - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - And using DAV path - And user "Alice" has uploaded file with content "ownCloud test text file 0" to "textfile0.txt" - And user "Brian" has uploaded file with content "ownCloud test text file 0" to "textfile0.txt" - And user "Alice" has shared file "textfile0.txt" with user "Brian" - And user "Alice" has locked file "textfile0.txt" setting the following properties - | lockscope | shared | - And user "Brian" has locked file "textfile0 (2).txt" setting the following properties - | lockscope | shared | - When user "Alice" uploads file with content "from user 0" to "textfile0.txt" sending the locktoken of file "textfile0.txt" using the WebDAV API - Then the HTTP status code should be "423" - And the content of file "textfile0.txt" for user "Alice" should be "ownCloud test text file 0" - And the content of file "textfile0 (2).txt" for user "Brian" should be "ownCloud test text file 0" - When user "Brian" uploads file with content "from user 1" to "textfile0 (2).txt" sending the locktoken of file "textfile0 (2).txt" using the WebDAV API - Then the HTTP status code should be "423" - And the content of file "textfile0.txt" for user "Alice" should be "ownCloud test text file 0" - And the content of file "textfile0 (2).txt" for user "Brian" should be "ownCloud test text file 0" - Examples: - | dav-path | - | old | - | new | diff --git a/tests/acceptance/features/coreApiWebdavLocksUnlock/unlock.feature b/tests/acceptance/features/coreApiWebdavLocksUnlock/unlock.feature index 61a65a40f62..cf45ac5ac98 100644 --- a/tests/acceptance/features/coreApiWebdavLocksUnlock/unlock.feature +++ b/tests/acceptance/features/coreApiWebdavLocksUnlock/unlock.feature @@ -64,7 +64,7 @@ Feature: UNLOCK locked items | new | shared | | new | exclusive | - @skipOnOcV10 @issue-34302 @files_sharing-app-required + @files_sharing-app-required Scenario Outline: as public unlocking a file in a share that was locked by the file owner is not possible. To unlock use the owners locktoken Given user "Alice" has created folder "PARENT" And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" diff --git a/tests/acceptance/features/coreApiWebdavLocksUnlock/unlockOc10Issue34302.feature b/tests/acceptance/features/coreApiWebdavLocksUnlock/unlockOc10Issue34302.feature deleted file mode 100644 index 957aa584772..00000000000 --- a/tests/acceptance/features/coreApiWebdavLocksUnlock/unlockOc10Issue34302.feature +++ /dev/null @@ -1,19 +0,0 @@ -@api @notToImplementOnOCIS @issue-ocis-reva-172 -Feature: UNLOCK locked items - - @issue-34302 @files_sharing-app-required - Scenario Outline: as public unlocking a file in a share that was locked by the file owner is not possible. To unlock use the owners locktoken - Given user "Alice" has been created with default attributes and without skeleton files - And user "Alice" has created folder "PARENT" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" - And user "Alice" has created a public link share of folder "PARENT" with change permission - And user "Alice" has locked file "PARENT/parent.txt" setting the following properties - | lockscope | | - When the public unlocks file "/parent.txt" with the last created lock of file "PARENT/parent.txt" of user "Alice" using the WebDAV API - Then the HTTP status code should be "405" - #Then the HTTP status code should be "403" - And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API - Examples: - | lock-scope | - | shared | - | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunking.feature b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunking.feature index 57181e3b5f3..973265c179b 100644 --- a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunking.feature +++ b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunking.feature @@ -9,20 +9,20 @@ Feature: users cannot upload a file to a blacklisted name using old chunking And using old DAV path And user "Alice" has been created with default attributes and without skeleton files - @skipOnOcV10 @issue-36645 @notToImplementOnOCIS + @notToImplementOnOCIS Scenario: Upload a file to a filename that is banned by default using old chunking When user "Alice" uploads file "filesForUpload/textfile.txt" to "/.htaccess" in 3 chunks using the WebDAV API Then the HTTP status code should be "403" And as "Alice" file ".htaccess" should not exist - @skipOnOcV10 @issue-36645 + Scenario: Upload a file to a banned filename using old chunking Given the administrator has updated system config key "blacklisted_files" with value '["blacklisted-file.txt",".htaccess"]' and type "json" When user "Alice" uploads file "filesForUpload/textfile.txt" to "blacklisted-file.txt" in 3 chunks using the WebDAV API Then the HTTP status code should be "403" And as "Alice" file "blacklisted-file.txt" should not exist - @skipOnOcV10 @issue-36645 + Scenario Outline: upload a file to a filename that matches blacklisted_files_regex using old chunking # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it # The actual regular expressions end up being .*\.ext$ and ^bannedfilename\..+ diff --git a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunkingOc10Issue36645.feature b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunkingOc10Issue36645.feature deleted file mode 100644 index 9f0135c5ed7..00000000000 --- a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunkingOc10Issue36645.feature +++ /dev/null @@ -1,39 +0,0 @@ -@notToImplementOnOCIS @api @issue-ocis-reva-15 -Feature: users cannot upload a file to a blacklisted name using old chunking - As an administrator - I want to be able to prevent users from uploading files to specified file names - So that I can prevent unwanted file names existing in the cloud storage - - Background: - Given using OCS API version "1" - And using old DAV path - And user "Alice" has been created with default attributes and without skeleton files - - @issue-36645 - Scenario: Upload a file to a filename that is banned by default using old chunking - When user "Alice" uploads file "filesForUpload/textfile.txt" to "/.htaccess" in 3 chunks using the WebDAV API - Then the HTTP status code should be "507" -# Then the HTTP status code should be "403" - And as "Alice" file ".htaccess" should not exist - - @issue-36645 - Scenario: Upload a file to a banned filename using old chunking - Given the administrator has updated system config key "blacklisted_files" with value '["blacklisted-file.txt",".htaccess"]' and type "json" - When user "Alice" uploads file "filesForUpload/textfile.txt" to "blacklisted-file.txt" in 3 chunks using the WebDAV API - Then the HTTP status code should be "507" -# Then the HTTP status code should be "403" - And as "Alice" file "blacklisted-file.txt" should not exist - - @issue-36645 - Scenario Outline: upload a file to a filename that matches blacklisted_files_regex using old chunking - # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it - # The actual regular expressions end up being .*\.ext$ and ^bannedfilename\..+ - Given the administrator has updated system config key "blacklisted_files_regex" with value '[".*\\.ext$","^bannedfilename\\..+","containsbannedstring"]' and type "json" - When user "Alice" uploads file "filesForUpload/textfile.txt" to "" in 3 chunks using the WebDAV API - Then the HTTP status code should be "" - And as "Alice" file "" should not exist - Examples: - | filename | http-status | comment | - | filename.ext | 507 | issue-36645 | - | bannedfilename.txt | 403 | ok | - | this-ContainsBannedString.txt | 403 | ok | diff --git a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingOldChunking.feature b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingOldChunking.feature index b86c037efe8..e4e6e558c07 100644 --- a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingOldChunking.feature +++ b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingOldChunking.feature @@ -9,14 +9,14 @@ Feature: users cannot upload a file to or into an excluded directory using old c And using old DAV path And user "Alice" has been created with default attributes and without skeleton files - @skipOnOcV10 @issue-36645 + Scenario: Upload a file to an excluded directory name using old chunking Given the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" When user "Alice" uploads file "filesForUpload/textfile.txt" to "/.github" in 3 chunks using the WebDAV API Then the HTTP status code should be "403" And as "Alice" file ".github" should not exist - @skipOnOcV10 @issue-36645 + Scenario: Upload a file to an excluded directory name inside a parent directory using old chunking Given user "Alice" has created folder "FOLDER" And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" @@ -25,7 +25,7 @@ Feature: users cannot upload a file to or into an excluded directory using old c And as "Alice" folder "/FOLDER" should exist But as "Alice" file "/FOLDER/.github" should not exist - @skipOnOcV10 @issue-36645 + Scenario Outline: upload a file to a filename that matches excluded_directories_regex using old chunking # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it # The actual regular expressions end up being endswith\.bad$ and ^\.git diff --git a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingOldChunkingOc10Issue36645.feature b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingOldChunkingOc10Issue36645.feature deleted file mode 100644 index 34a74b048d6..00000000000 --- a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingOldChunkingOc10Issue36645.feature +++ /dev/null @@ -1,42 +0,0 @@ -@notToImplementOnOCIS @api @issue-ocis-reva-15 -Feature: users cannot upload a file to or into an excluded directory using old chunking - As an administrator - I want to be able to exclude directories (folders) from being processed. Any attempt to upload a file to one of those names should be refused. - So that I can have directories on my cloud server storage that are not available for syncing. - - Background: - Given using OCS API version "1" - And using old DAV path - And user "Alice" has been created with default attributes and without skeleton files - - @issue-36645 - Scenario: Upload a file to an excluded directory name using old chunking - Given the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" - When user "Alice" uploads file "filesForUpload/textfile.txt" to "/.github" in 3 chunks using the WebDAV API - Then the HTTP status code should be "507" -# Then the HTTP status code should be "403" - And as "Alice" file ".github" should not exist - - @issue-36645 - Scenario: Upload a file to an excluded directory name inside a parent directory using old chunking - Given user "Alice" has created folder "FOLDER" - And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" - When user "Alice" uploads file "filesForUpload/textfile.txt" to "/FOLDER/.github" in 3 chunks using the WebDAV API - Then the HTTP status code should be "507" -# Then the HTTP status code should be "403" - And as "Alice" folder "/FOLDER" should exist - But as "Alice" file "/FOLDER/.github" should not exist - - @issue-36645 - Scenario Outline: upload a file to a filename that matches excluded_directories_regex using old chunking - # Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it - # The actual regular expressions end up being endswith\.bad$ and ^\.git - Given the administrator has updated system config key "excluded_directories_regex" with value '["endswith\\.bad$","^\\.git","containsvirusinthename"]' and type "json" - When user "Alice" uploads file "filesForUpload/textfile.txt" to "" in 3 chunks using the WebDAV API - Then the HTTP status code should be "" - And as "Alice" file "" should not exist - Examples: - | filename | http-status | comment | - | thisendswith.bad | 507 | issue-36645 | - | .github | 403 | ok | - | this-containsvirusinthename.txt | 403 | ok | diff --git a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileUsingOldChunking.feature b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileUsingOldChunking.feature index 938351d63b0..53b57f7a9ed 100644 --- a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileUsingOldChunking.feature +++ b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileUsingOldChunking.feature @@ -8,7 +8,7 @@ Feature: upload file using old chunking Given using OCS API version "1" And user "Alice" has been created with default attributes and without skeleton files - @skipOnOcV10 @issue-36115 + Scenario Outline: Upload chunked file asc Given using DAV path When user "Alice" uploads the following "3" chunks to "/myChunkedFile.txt" with old chunking and using the WebDAV API @@ -162,7 +162,7 @@ Feature: upload file using old chunking | spaces | @a#8a=b?c=d | | spaces | ?abc=oc # | - @skipOnOcV10 @issue-36115 + Scenario Outline: Upload chunked file with old chunking with lengthy filenames Given using DAV path Given the owncloud log level has been set to debug diff --git a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileUsingOldChunkingOc10Issue36115.feature b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileUsingOldChunkingOc10Issue36115.feature deleted file mode 100644 index a52fc8c0bba..00000000000 --- a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileUsingOldChunkingOc10Issue36115.feature +++ /dev/null @@ -1,43 +0,0 @@ -@notToImplementOnOCIS @api @issue-ocis-reva-17 -Feature: upload file using old chunking - As a user - I want to be able to upload "large" files in chunks - So that the upload can be completed in less elapsed time - - @issue-36115 - Scenario: Upload chunked file asc - Given using OCS API version "1" - And using old DAV path - And user "Alice" has been created with default attributes and without skeleton files - When user "Alice" uploads the following "3" chunks to "/myChunkedFile.txt" with old chunking and using the WebDAV API - | number | content | - | 1 | AAAAA | - | 2 | BBBBB | - | 3 | CCCCC | - 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}$/ | -# | ETag | /^"[a-f0-9:\.]{1,32}"$/ | - And as "Alice" file "/myChunkedFile.txt" should exist - And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" - - - Scenario: Upload chunked file with old chunking with lengthy filenames - Given using OCS API version "1" - And using old DAV path - And user "Alice" has been created with default attributes and without skeleton files - And the owncloud log level has been set to debug - And the owncloud log has been cleared - When user "Alice" uploads the following chunks to "नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-12345678910.txt" with old chunking and using the WebDAV API - | number | content | - | 1 | AAAAAAAAAAAAAAAAAAAAAAAAA | - | 2 | BBBBBBBBBBBBBBBBBBBBBBBBB | - | 3 | CCCCCCCCCCCCCCCCCCCCCCCCC | - 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 as "Alice" file "नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-12345678910.txt" should exist - And the content of file "नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-12345678910.txt" for user "Alice" should be "AAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCCCCCCCCCCC" - And the log file should not contain any log-entries containing these attributes: - | app | - | dav | \ No newline at end of file