From 672350af9e3bccd32eb5c28c79374f69ce122112 Mon Sep 17 00:00:00 2001 From: Swikriti Tripathi Date: Mon, 2 Aug 2021 13:21:52 +0545 Subject: [PATCH 1/2] remove api bug demonstration scenarios that are covered by exected-to-fail-file --- .../expected-failures-API-on-OCIS-storage.md | 2 - ...pected-failures-API-on-OWNCLOUD-storage.md | 2 - .../apiAuthOcs-ocsDELETEAuth.feature | 34 ---- .../apiAuthOcs-ocsGETAuth.feature | 176 ------------------ .../apiAuthOcs-ocsPOSTAuth.feature | 43 ----- .../apiAuthOcs-ocsPUTAuth.feature | 29 --- .../apiAuthWebDav-webDavLOCKAuth.feature | 21 --- .../apiAuthWebDav-webDavMOVEAuth.feature | 20 -- ...ilities-capabilitiesWithNormalUser.feature | 48 ----- .../apiBugDemonstration/apiMain-main.feature | 8 - ...piShareManagementBasic-createShare.feature | 117 ------------ .../apiShareOperations-gettingShares.feature | 37 ---- ...harePublicLink2-copyFromPublicLink.feature | 22 --- .../apiShareUpdate-updateShare.feature | 75 -------- .../apiTrashbin-trashbinDelete.feature | 14 -- .../apiVersions-fileVersions.feature | 91 --------- .../apiWebdavMove1-moveFolder.feature | 9 - ...vMove1-moveFolderToBlacklistedName.feature | 22 --- .../apiWebdavMove2-moveFile.feature | 21 --- ...davMove2-moveFileToBlacklistedName.feature | 22 --- .../apiWebdavOperations-refuseAccess.feature | 22 --- .../apiWebdavProperties1-createFolder.feature | 37 ---- ...ebdavProperties2-getFileProperties.feature | 53 ------ .../apiWebdavUpload1-uploadFile.feature | 27 --- .../apiWebdavUploadTUS-optionsRequest.feature | 29 --- 25 files changed, 981 deletions(-) diff --git a/tests/acceptance/expected-failures-API-on-OCIS-storage.md b/tests/acceptance/expected-failures-API-on-OCIS-storage.md index 1640d8b57c..6903d71bbf 100644 --- a/tests/acceptance/expected-failures-API-on-OCIS-storage.md +++ b/tests/acceptance/expected-failures-API-on-OCIS-storage.md @@ -1612,8 +1612,6 @@ Scenario Outline: Do a PROPFIND to a non-existing URL - [apiWebdavUploadTUS/checksums.feature:218](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/checksums.feature#L218) - [apiWebdavUploadTUS/optionsRequest.feature:7](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L7) - [apiWebdavUploadTUS/optionsRequest.feature:20](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L20) -- [apiWebdavUploadTUS/optionsRequest.feature:33](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L33) -- [apiWebdavUploadTUS/optionsRequest.feature:46](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L46) - [apiWebdavUploadTUS/uploadToShare.feature:173](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToShare.feature#L173) - [apiWebdavUploadTUS/uploadToShare.feature:174](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToShare.feature#L174) - [apiWebdavUploadTUS/uploadToShare.feature:192](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToShare.feature#L192) diff --git a/tests/acceptance/expected-failures-API-on-OWNCLOUD-storage.md b/tests/acceptance/expected-failures-API-on-OWNCLOUD-storage.md index bf20c138b6..eb0ddbdbfe 100644 --- a/tests/acceptance/expected-failures-API-on-OWNCLOUD-storage.md +++ b/tests/acceptance/expected-failures-API-on-OWNCLOUD-storage.md @@ -1795,8 +1795,6 @@ Scenario Outline: Do a PROPFIND to a non-existing URL - [apiWebdavUploadTUS/checksums.feature:218](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/checksums.feature#L218) - [apiWebdavUploadTUS/optionsRequest.feature:7](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L7) - [apiWebdavUploadTUS/optionsRequest.feature:20](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L20) -- [apiWebdavUploadTUS/optionsRequest.feature:33](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L33) -- [apiWebdavUploadTUS/optionsRequest.feature:46](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L46) - [apiWebdavUploadTUS/uploadToShare.feature:173](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToShare.feature#L173) - [apiWebdavUploadTUS/uploadToShare.feature:174](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToShare.feature#L174) - [apiWebdavUploadTUS/uploadToShare.feature:192](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToShare.feature#L192) diff --git a/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsDELETEAuth.feature b/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsDELETEAuth.feature index 0d22a6596b..8b13789179 100644 --- a/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsDELETEAuth.feature +++ b/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsDELETEAuth.feature @@ -1,35 +1 @@ -@api @issue-ocis-ocs-26 -# after fixing all issues delete these Scenarios and use the one from oC10 core -Feature: auth - - # these endpoints are handled by the reva ocs implementation - Scenario: send DELETE requests to OCS endpoints as admin with wrong password - When the administrator requests these endpoints with "DELETE" using password "invalid" about user "Alice" - | endpoint | - | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending/123 | - | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending/123 | - | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/123 | - | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/123 | - | /ocs/v2.php/apps/files_sharing/api/v1/shares/123 | - | /ocs/v1.php/apps/files_sharing/api/v1/shares/pending/123 | - | /ocs/v2.php/apps/files_sharing/api/v1/shares/pending/123 | - | /ocs/v1.php/cloud/apps/testing | - | /ocs/v2.php/cloud/apps/testing | - | /ocs/v1.php/cloud/groups/group1 | - | /ocs/v2.php/cloud/groups/group1 | - Then the HTTP status code of responses on all endpoints should be "401" - And the OCS status code of responses on all endpoints should be "notset" - - # these endpoints are handled by the ocis ocs implementation - Scenario: send DELETE requests to OCS endpoints as admin with wrong password - When the administrator requests these endpoints with "DELETE" using password "invalid" about user "Alice" - | endpoint | - | /ocs/v1.php/cloud/users/%username% | - | /ocs/v2.php/cloud/users/%username% | - | /ocs/v1.php/cloud/users/%username%/subadmins | - | /ocs/v2.php/cloud/users/%username%/subadmins | - | /ocs/v1.php/cloud/users/%username%/groups | - | /ocs/v2.php/cloud/users/%username%/groups | - Then the HTTP status code of responses on all endpoints should be "401" - And the OCS status code of responses on all endpoints should be "notset" diff --git a/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsGETAuth.feature b/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsGETAuth.feature index 20b4d9c3fc..e69de29bb2 100644 --- a/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsGETAuth.feature +++ b/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsGETAuth.feature @@ -1,176 +0,0 @@ -@api -Feature: auth - - Background: - Given user "Alice" has been created with default attributes and without skeleton files - - @issue-ocis-reva-29 - @issue-ocis-reva-30 - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario: using OCS anonymously - When a user requests these endpoints with "GET" and no authentication - | endpoint | - | /ocs/v1.php/apps/files_external/api/v1/mounts | - | /ocs/v2.php/apps/files_external/api/v1/mounts | - | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares | - | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares | - | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending | - | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending | - | /ocs/v1.php/apps/files_sharing/api/v1/shares | - | /ocs/v2.php/apps/files_sharing/api/v1/shares | - | /ocs/v1.php/cloud/apps | - | /ocs/v2.php/cloud/apps | - | /ocs/v1.php/config | - | /ocs/v2.php/config | - | /ocs/v1.php/privatedata/getattribute | - | /ocs/v2.php/privatedata/getattribute | - Then the HTTP status code of responses on all endpoints should be "401" - And the OCS status code of responses on all endpoints should be "notset" - - @issue-ocis-ocs-26 - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario: using OCS anonymously - When a user requests these endpoints with "GET" and no authentication - | endpoint | - | /ocs/v1.php/cloud/users | - | /ocs/v2.php/cloud/users | - | /ocs/v1.php/cloud/groups | - | /ocs/v2.php/cloud/groups | - Then the HTTP status code of responses on all endpoints should be "401" - And the OCS status code of responses on all endpoints should be "997" - - - @issue-ocis-reva-11 - @issue-ocis-reva-30 - @issue-ocis-reva-31 - @issue-ocis-reva-32 - @issue-ocis-reva-33 - @issue-ocis-reva-34 - @issue-ocis-reva-35 - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario: using OCS with non-admin basic auth - When the user "Alice" requests these endpoints with "GET" with basic auth - | endpoint | - | /ocs/v1.php/apps/files_external/api/v1/mounts | - | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares | - | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending | - | /ocs/v1.php/privatedata/getattribute | - | /ocs/v1.php/cloud/apps | - 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 "998" - When the user "Alice" requests these endpoints with "GET" with basic auth - | endpoint | - | /ocs/v1.php/config | - Then the HTTP status code of responses on all endpoints should be "200" - And the OCS status code of responses on all endpoints should be "100" - When the user "Alice" requests these endpoints with "GET" with basic auth - | endpoint | - | /ocs/v2.php/apps/files_external/api/v1/mounts | - | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares | - | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending | - # | /ocs/v1.php/apps/files_sharing/api/v1/shares | 100 | 200 | - # | /ocs/v2.php/apps/files_sharing/api/v1/shares | 100 | 200 | - - | /ocs/v2.php/cloud/apps | - | /ocs/v2.php/privatedata/getattribute | - Then the HTTP status code of responses on all endpoints should be "404" - And the OCS status code of responses on all endpoints should be "998" - When the user "Alice" requests these endpoints with "GET" with basic auth - | endpoint | - | /ocs/v1.php/cloud/users | - | /ocs/v2.php/cloud/users | - | /ocs/v1.php/cloud/groups | - | /ocs/v2.php/cloud/groups | - Then the HTTP status code of responses on all endpoints should be "401" - And the OCS status code of responses on all endpoints should be "997" - When the user "Alice" requests these endpoints with "GET" with basic auth - | endpoint | - | /ocs/v2.php/config | - 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 "200" - - @issue-ocis-reva-29 - @issue-ocis-reva-30 - @issue-ocis-accounts-73 - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario: using OCS as normal user (username has a capital letter) with wrong password - When user "Alice" requests these endpoints with "GET" using password "invalid" - | endpoint | - | /ocs/v1.php/apps/files_external/api/v1/mounts | - | /ocs/v2.php/apps/files_external/api/v1/mounts | - | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares | - | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares | - | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending | - | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending | - | /ocs/v1.php/apps/files_sharing/api/v1/shares | - | /ocs/v2.php/apps/files_sharing/api/v1/shares | - | /ocs/v1.php/cloud/apps | - | /ocs/v2.php/cloud/apps | - | /ocs/v1.php/cloud/groups | - | /ocs/v2.php/cloud/groups | - | /ocs/v1.php/config | - | /ocs/v2.php/config | - | /ocs/v1.php/privatedata/getattribute | - | /ocs/v2.php/privatedata/getattribute | - Then the HTTP status code of responses on all endpoints should be "401" - And the OCS status code of responses on all endpoints should be "notset" - - @issue-ocis-reva-29 - @issue-ocis-reva-30 - @issue-ocis-accounts-73 - @issue-ocis-ocs-26 - @smokeTest - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario: using OCS as normal user (username has a capital letter) with wrong password - When user "Alice" requests these endpoints with "GET" using password "invalid" - | endpoint | - | /ocs/v1.php/cloud/users | - | /ocs/v2.php/cloud/users | - Then the HTTP status code of responses on all endpoints should be "401" - And the OCS status code of responses on all endpoints should be "notset" - - @skipOnOcV10 - @issue-ocis-reva-29 - @issue-ocis-reva-30 - @issue-ocis-accounts-73 - @issue-ocis-ocs-26 - @smokeTest - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario: using OCS as normal user (username does not have a capital letter) with wrong password - Given user "brian" has been created with default attributes and without skeleton files - When user "brian" requests these endpoints with "GET" using password "invalid" - | endpoint | - | /ocs/v1.php/apps/files_external/api/v1/mounts | - | /ocs/v2.php/apps/files_external/api/v1/mounts | - | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares | - | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares | - | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending | - | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending | - | /ocs/v1.php/apps/files_sharing/api/v1/shares | - | /ocs/v2.php/apps/files_sharing/api/v1/shares | - | /ocs/v1.php/cloud/apps | - | /ocs/v2.php/cloud/apps | - | /ocs/v1.php/cloud/groups | - | /ocs/v2.php/cloud/groups | - | /ocs/v1.php/config | - | /ocs/v2.php/config | - | /ocs/v1.php/privatedata/getattribute | - | /ocs/v2.php/privatedata/getattribute | - Then the HTTP status code of responses on all endpoints should be "401" - And the OCS status code of responses on all endpoints should be "notset" - - @skipOnOcV10 - @issue-ocis-reva-29 - @issue-ocis-reva-30 - @issue-ocis-accounts-73 - @issue-ocis-ocs-26 - @smokeTest - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario: using OCS as normal user (username does not have a capital letter) with wrong password - Given user "brian" has been created with default attributes and without skeleton files - When user "brian" requests these endpoints with "GET" using password "invalid" - | endpoint | - | /ocs/v1.php/cloud/users | - | /ocs/v2.php/cloud/users | - Then the HTTP status code of responses on all endpoints should be "401" - And the OCS status code of responses on all endpoints should be "notset" diff --git a/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsPOSTAuth.feature b/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsPOSTAuth.feature index 70551de80a..e69de29bb2 100644 --- a/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsPOSTAuth.feature +++ b/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsPOSTAuth.feature @@ -1,43 +0,0 @@ -@api -Feature: auth - - Background: - Given user "Alice" has been created with default attributes and without skeleton files - - @issue-ocis-ocs-26 @issue-ocis-reva-30 - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario: send POST requests to OCS endpoints as normal user with wrong password - When user "Alice" requests these endpoints with "POST" including body "doesnotmatter" using password "invalid" about user "Alice" - | endpoint | - | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending/123 | - | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending/123 | - | /ocs/v1.php/apps/files_sharing/api/v1/shares | - | /ocs/v2.php/apps/files_sharing/api/v1/shares | - | /ocs/v1.php/apps/files_sharing/api/v1/shares/pending/123 | - | /ocs/v2.php/apps/files_sharing/api/v1/shares/pending/123 | - | /ocs/v1.php/cloud/apps/testing | - | /ocs/v2.php/cloud/apps/testing | - | /ocs/v1.php/cloud/groups | - | /ocs/v2.php/cloud/groups | - | /ocs/v1.php/person/check | - | /ocs/v2.php/person/check | - | /ocs/v1.php/privatedata/deleteattribute/testing/test | - | /ocs/v2.php/privatedata/deleteattribute/testing/test | - | /ocs/v1.php/privatedata/setattribute/testing/test | - | /ocs/v2.php/privatedata/setattribute/testing/test | - Then the HTTP status code of responses on all endpoints should be "401" - And the OCS status code of responses on all endpoints should be "notset" - - @issue-ocis-reva-30 - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario: send POST requests to OCS endpoints as normal user with wrong password - When user "Alice" requests these endpoints with "POST" including body "doesnotmatter" using password "invalid" about user "Alice" - | endpoint | - | /ocs/v1.php/cloud/users | - | /ocs/v2.php/cloud/users | - | /ocs/v1.php/cloud/users/%username%/groups | - | /ocs/v2.php/cloud/users/%username%/groups | - | /ocs/v1.php/cloud/users/%username%/subadmins | - | /ocs/v2.php/cloud/users/%username%/subadmins | - Then the HTTP status code of responses on all endpoints should be "401" - And the OCS status code of responses on all endpoints should be "notset" diff --git a/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsPUTAuth.feature b/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsPUTAuth.feature index 13448ea000..e69de29bb2 100644 --- a/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsPUTAuth.feature +++ b/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsPUTAuth.feature @@ -1,29 +0,0 @@ -@api -Feature: auth - - @issue-ocis-reva-30 - @issue-ocis-ocs-26 - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario: send PUT request to OCS endpoints as admin with wrong password - When the administrator requests these endpoints with "PUT" with body "doesnotmatter" using password "invalid" about user "Alice" - | endpoint | - | /ocs/v1.php/apps/files_sharing/api/v1/shares/123 | - | /ocs/v2.php/apps/files_sharing/api/v1/shares/123 | - | /ocs/v1.php/cloud/users/%username% | - | /ocs/v2.php/cloud/users/%username% | - Then the HTTP status code of responses on all endpoints should be "401" - And the OCS status code of responses on all endpoints should be "notset" - - @issue-ocis-reva-30 - @issue-ocis-ocs-28 - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario: send PUT request to OCS endpoints as admin with wrong password - When the administrator requests these endpoints with "PUT" with body "doesnotmatter" using password "invalid" about user "Alice" - | endpoint | - | /ocs/v1.php/cloud/users/%username%/disable | - | /ocs/v2.php/cloud/users/%username%/disable | - | /ocs/v1.php/cloud/users/%username%/enable | - | /ocs/v2.php/cloud/users/%username%/enable | - Then the HTTP status code of responses on all endpoints should be "401" - And the OCS status code of responses on all endpoints should be "notset" - diff --git a/tests/acceptance/features/apiBugDemonstration/apiAuthWebDav-webDavLOCKAuth.feature b/tests/acceptance/features/apiBugDemonstration/apiAuthWebDav-webDavLOCKAuth.feature index fe5c1c6751..e69de29bb2 100644 --- a/tests/acceptance/features/apiBugDemonstration/apiAuthWebDav-webDavLOCKAuth.feature +++ b/tests/acceptance/features/apiBugDemonstration/apiAuthWebDav-webDavLOCKAuth.feature @@ -1,21 +0,0 @@ -@api -Feature: LOCK file/folder - - Background: - Given user "Alice" 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 uploaded file with content "some data" to "/textfile1.txt" - And user "Alice" has created folder "/PARENT" - And user "Alice" has created folder "/FOLDER" - And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" - And user "Brian" has been created with default attributes and without skeleton files - - @issue-ocis-reva-9 - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario: send LOCK requests to another user's webDav endpoints as normal user - When user "Brian" requests these endpoints with "LOCK" to get property "d:shared" about user "Alice" - | endpoint | - | /remote.php/dav/files/%username%/textfile0.txt | - | /remote.php/dav/files/%username%/PARENT | - | /remote.php/dav/files/%username%/PARENT/parent.txt | - Then the HTTP status code of responses on all endpoints should be "200" diff --git a/tests/acceptance/features/apiBugDemonstration/apiAuthWebDav-webDavMOVEAuth.feature b/tests/acceptance/features/apiBugDemonstration/apiAuthWebDav-webDavMOVEAuth.feature index c2291fc5ed..e69de29bb2 100644 --- a/tests/acceptance/features/apiBugDemonstration/apiAuthWebDav-webDavMOVEAuth.feature +++ b/tests/acceptance/features/apiBugDemonstration/apiAuthWebDav-webDavMOVEAuth.feature @@ -1,20 +0,0 @@ -@api -Feature: MOVE file/folder - - Background: - Given user "Alice" 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 created folder "/PARENT" - And user "Alice" has created folder "/FOLDER" - And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt" - And user "Brian" has been created with default attributes and without skeleton files - - @issue-ocis-reva-14 - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario: send MOVE requests to another user's webDav endpoints as normal user - When user "Brian" requests these endpoints with "MOVE" including body "doesnotmatter" about user "Alice" - | endpoint | - | /remote.php/dav/files/%username%/textfile0.txt | - | /remote.php/dav/files/%username%/PARENT | - | /remote.php/dav/files/%username%/PARENT/parent.txt | - Then the HTTP status code of responses on all endpoints should be "400" diff --git a/tests/acceptance/features/apiBugDemonstration/apiCapabilities-capabilitiesWithNormalUser.feature b/tests/acceptance/features/apiBugDemonstration/apiCapabilities-capabilitiesWithNormalUser.feature index 3d91fceb6f..e69de29bb2 100644 --- a/tests/acceptance/features/apiBugDemonstration/apiCapabilities-capabilitiesWithNormalUser.feature +++ b/tests/acceptance/features/apiBugDemonstration/apiCapabilities-capabilitiesWithNormalUser.feature @@ -1,48 +0,0 @@ -@api @files_sharing-app-required -Feature: default capabilities for normal user - - Background: - Given using OCS API version "1" - And user "Alice" has been created with default attributes and without skeleton files - - @issue-ocis-reva-175 @issue-ocis-reva-176 - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario: getting default capabilities with normal user - When user "Alice" retrieves the capabilities using the capabilities API - Then the capabilities should contain - | capability | path_to_element | value | - | core | pollinterval | 60 | - | core | webdav-root | remote.php/webdav | - | core | status@@@edition | %edition% | - | core | status@@@productname | reva | - | core | status@@@version | 10.0.11.5 | - | core | status@@@versionstring | 10.0.11 | - | files_sharing | api_enabled | 1 | - | files_sharing | default_permissions | 22 | - | files_sharing | search_min_length | 3 | - | files_sharing | public@@@enabled | 1 | - | files_sharing | public@@@multiple | 1 | - | files_sharing | public@@@upload | 1 | - | files_sharing | public@@@supports_upload_only | 1 | - | files_sharing | public@@@send_mail | 1 | - | files_sharing | public@@@social_share | 1 | - | files_sharing | public@@@enforced | EMPTY | - | files_sharing | public@@@enforced_for@@@read_only | EMPTY | - | files_sharing | public@@@enforced_for@@@read_write | EMPTY | - | files_sharing | public@@@enforced_for@@@upload_only | EMPTY | - | files_sharing | public@@@enforced_for@@@read_write_delete | EMPTY | - | files_sharing | public@@@expire_date@@@enabled | 0 | - | files_sharing | public@@@defaultPublicLinkShareName | EMPTY | - | files_sharing | resharing | 1 | - | files_sharing | federation@@@outgoing | 1 | - | files_sharing | federation@@@incoming | 1 | - | files_sharing | group_sharing | 1 | - | files_sharing | share_with_group_members_only | 1 | - | files_sharing | share_with_membership_groups_only | 1 | - | files_sharing | auto_accept_share | 1 | - | files_sharing | user_enumeration@@@enabled | 1 | - | files_sharing | user_enumeration@@@group_members_only | 1 | - | files_sharing | user@@@send_mail | 1 | - | files | bigfilechunking | 0 | - | files | privateLinks | 0 | - | files | privateLinksDetailsParam | EMPTY | diff --git a/tests/acceptance/features/apiBugDemonstration/apiMain-main.feature b/tests/acceptance/features/apiBugDemonstration/apiMain-main.feature index 9c4ad50f95..e69de29bb2 100644 --- a/tests/acceptance/features/apiBugDemonstration/apiMain-main.feature +++ b/tests/acceptance/features/apiBugDemonstration/apiMain-main.feature @@ -1,8 +0,0 @@ -@api -Feature: Other tests related to api - - @issue-ocis-reva-100 - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario: robots.txt file should be accessible - When a user requests "/robots.txt" with "GET" and no authentication - Then the HTTP status code should be "401" or "404" diff --git a/tests/acceptance/features/apiBugDemonstration/apiShareManagementBasic-createShare.feature b/tests/acceptance/features/apiBugDemonstration/apiShareManagementBasic-createShare.feature index 66160280ec..e69de29bb2 100644 --- a/tests/acceptance/features/apiBugDemonstration/apiShareManagementBasic-createShare.feature +++ b/tests/acceptance/features/apiBugDemonstration/apiShareManagementBasic-createShare.feature @@ -1,117 +0,0 @@ -@api @files_sharing-app-required -Feature: sharing - - Background: - Given user "Alice" 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" - - @skipOnOcis-OC-Storage @skipOnOcis-OCIS-Storage @issue-ocis-reva-301 @issue-ocis-reva-302 - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario Outline: Creating a share of a file with a user and asking for various permission combinations - Given using OCS API version "" - And user "Brian" has been created with default attributes and without skeleton files - 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% | - | file_target | /textfile0.txt | - | path | /textfile0.txt | - | permissions | | - | uid_owner | %username% | - | displayname_owner | | - | item_type | file | - | mimetype | application/octet-stream | - | storage_id | ANY_VALUE | - | share_type | user | - And the fields of the last response should not include - | share_with_displayname | %displayname% | - Examples: - | 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 | - # Ask for read, share (17), create and delete. You get share plus read - | 1 | 29 | 17 | 100 | - | 2 | 29 | 17 | 200 | - # Ask for read, update, create, delete. You get read plus update. - | 1 | 15 | 3 | 100 | - | 2 | 15 | 3 | 200 | - # Ask for just update. You get exactly update (you do not get read or anything else) - | 1 | 2 | 2 | 100 | - | 2 | 2 | 2 | 200 | - - @issue-ocis-reva-243 - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario Outline: more tests to demonstrate different ocis-reva issue 243 behaviours - Given using OCS API version "" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created folder "/home" - And user "Alice" has uploaded file with content "Random data" to "/home/randomfile.txt" - When user "Alice" shares file "/home/randomfile.txt" with user "Brian" using the sharing API - And the HTTP status code should be "" or "" - And as "Brian" file "randomfile.txt" should not exist - Examples: - | ocs_api_version | http_status_code_ocs | http_status_code_eos | - | 1 | 200 | 500 | - | 2 | 200 | 500 | - - @skipOnOcis-OC-Storage @skipOnOcis-OCIS-Storage @issue-ocis-reva-301 @issue-ocis-reva-302 - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario Outline: Creating a share of a folder with a user, the default permissions are all permissions(31) - 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 "" - 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% | - | file_target | /FOLDER | - | path | /FOLDER | - | permissions | all | - | uid_owner | %username% | - | displayname_owner | | - | item_type | folder | - | mimetype | httpd/unix-directory | - | storage_id | ANY_VALUE | - | share_type | user | - And the fields of the last response should not include - | share_with_displayname | %displayname% | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - @issue-ocis-reva-372 @issue-ocis-reva-243 @skipOnOcis-OCIS-Storage - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario Outline: sharing subfolder of already shared folder, GET result is correct - Given using OCS API version "" - And these users have been created with default attributes and without skeleton files: - | username | - | Brian | - | Carol | - | David | - | Emily | - And user "Alice" has created folder "/folder1" - And user "Alice" has shared folder "/folder1" with user "Brian" - And user "Alice" has shared folder "/folder1" with user "Carol" - And user "Alice" has created folder "/folder1/folder2" - 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 "" - 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 - And folder "/folder2" should be included as path in the response - And user "Alice" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/shares?path=/folder1/folder2" - 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 - And folder "/folder2" should be included as path in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | diff --git a/tests/acceptance/features/apiBugDemonstration/apiShareOperations-gettingShares.feature b/tests/acceptance/features/apiBugDemonstration/apiShareOperations-gettingShares.feature index 5790f226cf..e69de29bb2 100644 --- a/tests/acceptance/features/apiBugDemonstration/apiShareOperations-gettingShares.feature +++ b/tests/acceptance/features/apiBugDemonstration/apiShareOperations-gettingShares.feature @@ -1,37 +0,0 @@ -@api @files_sharing-app-required -Feature: sharing - - Background: - Given these users have been created with default attributes and small skeleton files: - | username | - | Alice | - | Brian | - - @issue-ocis-reva-374 - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario Outline: Get a share with a user that didn't receive the share - Given using OCS API version "" - And user "Carol" has been created with default attributes and without skeleton files - And user "Alice" has shared file "textfile0.txt" with user "Brian" - When user "Carol" gets the info of the last share using the sharing API - Then the OCS status code should be "998" -# Then the OCS status code should be "404" - And the HTTP status code should be "" - Examples: - | ocs_api_version | http_status_code | - | 1 | 200 | - | 2 | 404 | - - @issue-ocis-reva-372 - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario Outline: getting all the shares inside the folder - Given using OCS API version "" - And user "Alice" has shared file "PARENT/parent.txt" with user "Brian" - When user "Alice" gets all the shares inside the folder "PARENT/parent.txt" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And file "parent.txt" should be included in the response - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | diff --git a/tests/acceptance/features/apiBugDemonstration/apiSharePublicLink2-copyFromPublicLink.feature b/tests/acceptance/features/apiBugDemonstration/apiSharePublicLink2-copyFromPublicLink.feature index ff889194a1..e69de29bb2 100644 --- a/tests/acceptance/features/apiBugDemonstration/apiSharePublicLink2-copyFromPublicLink.feature +++ b/tests/acceptance/features/apiBugDemonstration/apiSharePublicLink2-copyFromPublicLink.feature @@ -1,22 +0,0 @@ -@api @files_sharing-app-required @public_link_share-feature-required @issue-ocis-reva-310 -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" - And the administrator has enabled DAV tech_preview - - @issue-ocis-reva-373 @issue-core-37683 @skipOnOcis-OCIS-Storage - # after fixing all issues delete this Scenario and use the one from oC10 core - 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" diff --git a/tests/acceptance/features/apiBugDemonstration/apiShareUpdate-updateShare.feature b/tests/acceptance/features/apiBugDemonstration/apiShareUpdate-updateShare.feature index 00eda3381d..e69de29bb2 100644 --- a/tests/acceptance/features/apiBugDemonstration/apiShareUpdate-updateShare.feature +++ b/tests/acceptance/features/apiBugDemonstration/apiShareUpdate-updateShare.feature @@ -1,75 +0,0 @@ -@api @files_sharing-app-required -Feature: sharing - - Background: - Given using OCS API version "1" - And user "Alice" has been created with default attributes and without skeleton files - - @skipOnOcis-EOS-Storage @issue-ocis-reva-243 @skipOnOcis-OCIS-Storage - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario: Share ownership change after moving a shared file to another share - Given these users have been created with default attributes and without skeleton files: - | username | - | Brian | - | Carol | - And user "Alice" has created folder "/Alice-folder" - And user "Alice" has created folder "/Alice-folder/folder2" - And user "Carol" has created folder "/Carol-folder" - And user "Alice" has shared folder "/Alice-folder" with user "Brian" with permissions "all" - And user "Carol" has shared folder "/Carol-folder" with user "Brian" with permissions "all" - When user "Brian" moves folder "/Alice-folder/folder2" to "/Carol-folder/folder2" using the WebDAV API - And user "Carol" gets the info of the last share using the sharing API - # Note: in the following fields, file_parent has been removed because OCIS does not report that - Then the fields of the last response to user "Carol" sharing with user "Brian" should include - | id | A_STRING | - | item_type | folder | - | item_source | A_STRING | - | share_type | user | - | file_source | A_STRING | - | file_target | /Carol-folder | - | permissions | all | - | stime | A_NUMBER | - | storage | A_STRING | - | mail_send | 0 | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | mimetype | httpd/unix-directory | - # Really folder2 should be gone from Alice-folder and be found in Carol-folder - # like in these 2 suggested steps: - # And as "Alice" folder "/Alice-folder/folder2" should not exist - # And as "Carol" folder "/Carol-folder/folder2" should exist - # - # But this happens on OCIS: - And as "Alice" folder "/Alice-folder/folder2" should exist - And as "Carol" folder "/Carol-folder/folder2" should not exist - - @skipOnOcis-OC-Storage @issue-ocis-reva-243 @skipOnOcis-OCIS-Storage - # same as oC10 core Scenario but without displayname_owner because EOS does not report it - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario: Share ownership change after moving a shared file to another share - Given these users have been created with default attributes and without skeleton files: - | username | - | Brian | - | Carol | - And user "Alice" has created folder "/Alice-folder" - And user "Alice" has created folder "/Alice-folder/folder2" - And user "Carol" has created folder "/Carol-folder" - And user "Alice" has shared folder "/Alice-folder" with user "Brian" with permissions "all" - And user "Carol" has shared folder "/Carol-folder" with user "Brian" with permissions "all" - When user "Brian" moves folder "/Alice-folder/folder2" to "/Carol-folder/folder2" using the WebDAV API - And user "Carol" gets the info of the last share using the sharing API - Then the fields of the last response to user "Carol" sharing with user "Brian" should include - | id | A_STRING | - | item_type | folder | - | item_source | A_STRING | - | share_type | user | - | file_source | A_STRING | - | file_target | /Carol-folder | - | permissions | all | - | stime | A_NUMBER | - | storage | A_STRING | - | mail_send | 0 | - | uid_owner | %username% | - | mimetype | httpd/unix-directory | - And as "Alice" folder "/Alice-folder/folder2" should exist - And as "Carol" folder "/Carol-folder/folder2" should not exist diff --git a/tests/acceptance/features/apiBugDemonstration/apiTrashbin-trashbinDelete.feature b/tests/acceptance/features/apiBugDemonstration/apiTrashbin-trashbinDelete.feature index cab8788dd9..e69de29bb2 100644 --- a/tests/acceptance/features/apiBugDemonstration/apiTrashbin-trashbinDelete.feature +++ b/tests/acceptance/features/apiBugDemonstration/apiTrashbin-trashbinDelete.feature @@ -1,14 +0,0 @@ -@api @files_trashbin-app-required -Feature: files and folders can be deleted from the trashbin - As a user - I want to delete files and folders from the trashbin - So that I can control my trashbin space and which files are kept in that space - - 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" - And user "Alice" has uploaded file with content "to delete" to "/textfile1.txt" - And user "Alice" has created folder "PARENT" - And user "Alice" has created folder "PARENT/CHILD" - And user "Alice" has uploaded file with content "to delete" to "/PARENT/parent.txt" - And user "Alice" has uploaded file with content "to delete" to "/PARENT/CHILD/child.txt" diff --git a/tests/acceptance/features/apiBugDemonstration/apiVersions-fileVersions.feature b/tests/acceptance/features/apiBugDemonstration/apiVersions-fileVersions.feature index 32a1441f78..38768cf51e 100644 --- a/tests/acceptance/features/apiBugDemonstration/apiVersions-fileVersions.feature +++ b/tests/acceptance/features/apiBugDemonstration/apiVersions-fileVersions.feature @@ -7,95 +7,4 @@ Feature: dav-versions And using new DAV path And user "Alice" has been created with default attributes and without skeleton files - @issue-ocis-reva-17 @issue-ocis-reva-56 - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario: Upload file and no version is available using various chunking methods - When user "Alice" uploads file "filesForUpload/davtest.txt" to filenames based on "/davtest.txt" with all mechanisms using the WebDAV API - Then the version folder of file "/davtest.txt-olddav-regular" for user "Alice" should contain "0" elements - Then the version folder of file "/davtest.txt-newdav-regular" for user "Alice" should contain "0" elements - Then the version folder of file "/davtest.txt-olddav-oldchunking" for user "Alice" should contain "0" elements - And as "Alice" file "/davtest.txt-newdav-newchunking" should not exist - - @files_sharing-app-required - @issue-ocis-reva-243 - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario: sharer of a file can see the old version information when the sharee changes the content of the file - Given user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file with content "First content" to "sharefile.txt" - And user "Alice" has shared file "sharefile.txt" with user "Brian" - When user "Brian" has uploaded file with content "Second content" to "/sharefile.txt" - Then the HTTP status code should be "201" - And the version folder of file "/sharefile.txt" for user "Alice" should contain "0" element -# And the version folder of file "/sharefile.txt" for user "Alice" should contain "1" element - - @files_sharing-app-required - @issue-ocis-reva-243 - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario: sharer of a file can restore the original content of a shared file after the file has been modified by the sharee - Given user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file with content "First content" to "sharefile.txt" - And user "Alice" has shared file "sharefile.txt" with user "Brian" - And user "Brian" has uploaded file with content "Second content" to "/sharefile.txt" - When user "Alice" restores version index "0" of file "/sharefile.txt" using the WebDAV API -# When user "Alice" restores version index "1" of file "/sharefile.txt" using the WebDAV API - Then the HTTP status code should be "201" - And the content of file "/sharefile.txt" for user "Alice" should be "First content" - And the content of file "/sharefile.txt" for user "Brian" should be "Second content" -# And the content of file "/sharefile.txt" for user "Brian" should be "First content" - - @files_sharing-app-required - @issue-ocis-reva-243 @issue-ocis-reva-386 - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario Outline: Moving a file (with versions) into a shared folder as the sharee and as the sharer - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And user "Brian" has created folder "/testshare" - And user "Brian" has created a share with settings - | path | testshare | - | shareType | user | - | permissions | change | - | shareWith | Alice | - And user "Brian" has uploaded file with content "test data 1" to "/testfile.txt" - And user "Brian" has uploaded file with content "test data 2" to "/testfile.txt" - And user "Brian" has uploaded file with content "test data 3" to "/testfile.txt" - And user "Brian" moves file "/testfile.txt" to "/testshare/testfile.txt" using the WebDAV API - Then the HTTP status code should be "201" - And the content of file "/testshare/testfile.txt" for user "Alice" should be "" -# And the content of file "/testshare/testfile.txt" for user "Alice" should be "test data 3" - And the content of file "/testshare/testfile.txt" for user "Brian" should be "test data 3" - And as "Brian" file "/testfile.txt" should not exist - And as "Alice" file "/testshare/testfile.txt" should not exist - And the content of file "/testshare/testfile.txt" for user "Brian" should be "test data 3" -# And the version folder of file "/testshare/testfile.txt" for user "Alice" should contain "2" elements -# And the version folder of file "/testshare/testfile.txt" for user "Brian" should contain "2" elements - Examples: - | dav_version | - | old | - | new | - - @files_sharing-app-required - @issue-ocis-reva-243 @issue-ocis-reva-386 - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario Outline: Moving a file (with versions) out of a shared folder as the sharee and as the sharer - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And user "Brian" has created folder "/testshare" - And user "Brian" has uploaded file with content "test data 1" to "/testshare/testfile.txt" - And user "Brian" has uploaded file with content "test data 2" to "/testshare/testfile.txt" - And user "Brian" has uploaded file with content "test data 3" to "/testshare/testfile.txt" - And user "Brian" has created a share with settings - | path | testshare | - | shareType | user | - | permissions | change | - | shareWith | Alice | - When user "Brian" moves file "/testshare/testfile.txt" to "/testfile.txt" using the WebDAV API - Then the HTTP status code should be "201" - And the content of file "/testfile.txt" for user "Brian" should be "test data 3" - And as "Alice" file "/testshare/testfile.txt" should not exist - And as "Brian" file "/testshare/testfile.txt" should not exist -# And the version folder of file "/testfile.txt" for user "Brian" should contain "2" elements - Examples: - | dav_version | - | old | - | new | diff --git a/tests/acceptance/features/apiBugDemonstration/apiWebdavMove1-moveFolder.feature b/tests/acceptance/features/apiBugDemonstration/apiWebdavMove1-moveFolder.feature index c8e3608882..e69de29bb2 100644 --- a/tests/acceptance/features/apiBugDemonstration/apiWebdavMove1-moveFolder.feature +++ b/tests/acceptance/features/apiBugDemonstration/apiWebdavMove1-moveFolder.feature @@ -1,9 +0,0 @@ -@api @issue-ocis-reva-14 -Feature: move (rename) folder - As a user - I want to be able to move and rename folders - So that I can quickly manage my file system - - Background: - Given using OCS API version "1" - And user "Alice" has been created with default attributes and without skeleton files diff --git a/tests/acceptance/features/apiBugDemonstration/apiWebdavMove1-moveFolderToBlacklistedName.feature b/tests/acceptance/features/apiBugDemonstration/apiWebdavMove1-moveFolderToBlacklistedName.feature index 3d1289d8bf..e69de29bb2 100644 --- a/tests/acceptance/features/apiBugDemonstration/apiWebdavMove1-moveFolderToBlacklistedName.feature +++ b/tests/acceptance/features/apiBugDemonstration/apiWebdavMove1-moveFolderToBlacklistedName.feature @@ -1,22 +0,0 @@ -@api @issue-ocis-reva-14 -Feature: users cannot move (rename) a folder to a blacklisted name - As an administrator - I want to be able to prevent users from moving (renaming) folders to specified names - So that I can prevent unwanted folder names existing in the cloud storage - - Background: - Given using OCS API version "1" - And user "Alice" has been created with default attributes and without skeleton files - - @issue-ocis-reva-211 @skipOnOcis-EOS-Storage @issue-ocis-reva-269 @skipOnOcis-OCIS-Storage - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario Outline: Renaming a folder to a name that is banned by default is allowed - Given using DAV path - And user "Alice" has created folder "/testshare" - When user "Alice" moves folder "/testshare" to "/.htaccess" using the WebDAV API - Then the HTTP status code should be "201" - And as "Alice" folder "/.htaccess" should exist - Examples: - | dav_version | - | old | - | new | diff --git a/tests/acceptance/features/apiBugDemonstration/apiWebdavMove2-moveFile.feature b/tests/acceptance/features/apiBugDemonstration/apiWebdavMove2-moveFile.feature index 6d05666017..8b13789179 100644 --- a/tests/acceptance/features/apiBugDemonstration/apiWebdavMove2-moveFile.feature +++ b/tests/acceptance/features/apiBugDemonstration/apiWebdavMove2-moveFile.feature @@ -1,22 +1 @@ -@api @issue-ocis-reva-14 -Feature: move (rename) file - As a user - I want to be able to move and rename files - So that I can manage my file system - Background: - Given using OCS API version "1" - And user "Alice" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file with content "text file 0" to "/textfile0.txt" - - @issue-ocis-reva-211 @skipOnOcis-OCIS-Storage - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario Outline: Renaming a file to a path with extension .part is possible - Given using DAV path - When user "Alice" moves file "/textfile0.txt" to "/textfile0.part" using the WebDAV API - Then the HTTP status code should be "201" - And as "Alice" file "/textfile0.part" should exist - Examples: - | dav_version | - | old | - | new | diff --git a/tests/acceptance/features/apiBugDemonstration/apiWebdavMove2-moveFileToBlacklistedName.feature b/tests/acceptance/features/apiBugDemonstration/apiWebdavMove2-moveFileToBlacklistedName.feature index 2883062173..e69de29bb2 100644 --- a/tests/acceptance/features/apiBugDemonstration/apiWebdavMove2-moveFileToBlacklistedName.feature +++ b/tests/acceptance/features/apiBugDemonstration/apiWebdavMove2-moveFileToBlacklistedName.feature @@ -1,22 +0,0 @@ -@api @issue-ocis-reva-14 -Feature: users cannot move (rename) a file to a blacklisted name - As an administrator - I want to be able to prevent users from moving (renaming) 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 user "Alice" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file with content "text file 0" to "/textfile0.txt" - - @issue-ocis-reva-211 @skipOnOcis-OCIS-Storage - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario Outline: rename a file to a filename that is banned by default - Given using DAV path - When user "Alice" moves file "/textfile0.txt" to "/.htaccess" using the WebDAV API - Then the HTTP status code should be "201" - And as "Alice" file "/.htaccess" should exist - Examples: - | dav_version | - | old | - | new | diff --git a/tests/acceptance/features/apiBugDemonstration/apiWebdavOperations-refuseAccess.feature b/tests/acceptance/features/apiBugDemonstration/apiWebdavOperations-refuseAccess.feature index 5a1df03453..e69de29bb2 100644 --- a/tests/acceptance/features/apiBugDemonstration/apiWebdavOperations-refuseAccess.feature +++ b/tests/acceptance/features/apiBugDemonstration/apiWebdavOperations-refuseAccess.feature @@ -1,22 +0,0 @@ -@api -Feature: refuse access - As an administrator - I want to refuse access to unauthenticated and disabled users - So that I can secure the system - - Background: - Given using OCS API version "1" - - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario Outline: Unauthenticated call - Given using DAV path - When an unauthenticated client connects to the dav endpoint using the WebDAV API - Then the HTTP status code should be "401" - And there should be no duplicate headers - And the following headers should be set - | header | value | - | WWW-Authenticate | Basic realm="%base_url_without_scheme%" | - Examples: - | dav_version | - | old | - | new | diff --git a/tests/acceptance/features/apiBugDemonstration/apiWebdavProperties1-createFolder.feature b/tests/acceptance/features/apiBugDemonstration/apiWebdavProperties1-createFolder.feature index 47a0b94ff1..e69de29bb2 100644 --- a/tests/acceptance/features/apiBugDemonstration/apiWebdavProperties1-createFolder.feature +++ b/tests/acceptance/features/apiBugDemonstration/apiWebdavProperties1-createFolder.feature @@ -1,37 +0,0 @@ -@api -Feature: create folder - As a user - I want to be able to create folders - So that I can organise the files in my file system - - Background: - Given using OCS API version "1" - And user "Alice" has been created with default attributes and without skeleton files - - @issue-ocis-reva-168 @skipOnOcis-EOS-Storage @skipOnOcis-OCIS-Storage - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario Outline: try to create a folder that already exists - Given using DAV path - And user "Alice" has created folder "my-data" - When user "Alice" creates folder "my-data" using the WebDAV API - Then the HTTP status code should be "405" - And as "Alice" folder "my-data" should exist - And the body of the response should be empty - Examples: - | dav_version | - | old | - | new | - - @issue-ocis-reva-168 - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario Outline: try to create a folder with a name of an existing file - Given using DAV path - And user "Alice" has uploaded file with content "uploaded data" to "/my-data.txt" - When user "Alice" creates folder "my-data.txt" using the WebDAV API - Then the HTTP status code should be "405" - And the body of the response should be empty - And the content of file "/my-data.txt" for user "Alice" should be "uploaded data" - Examples: - | dav_version | - | old | - | new | diff --git a/tests/acceptance/features/apiBugDemonstration/apiWebdavProperties2-getFileProperties.feature b/tests/acceptance/features/apiBugDemonstration/apiWebdavProperties2-getFileProperties.feature index d64b0d4ca0..e69de29bb2 100644 --- a/tests/acceptance/features/apiBugDemonstration/apiWebdavProperties2-getFileProperties.feature +++ b/tests/acceptance/features/apiBugDemonstration/apiWebdavProperties2-getFileProperties.feature @@ -1,53 +0,0 @@ -@api -Feature: get file properties - As a user - I want to be able to get meta-information about files - So that I can know file meta-information (detailed requirement TBD) - - Background: - Given using OCS API version "1" - And user "Alice" has been created with default attributes and without skeleton files - - @issue-ocis-reva-214 @skipOnOcis-OCIS-Storage - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario Outline: Do a PROPFIND of 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 - Then the properties response should contain an etag - And the value of the item "//d:response/d:href" in the response to user "Alice" should match "/remote\.php\//" - Examples: - | dav_version | file_name | expected_href | - | old | /file #2.txt | webdav\/file%20%232\.txt | - | new | /file #2.txt | dav\/files\/%username%\/file%20%232\.txt | - - @issue-ocis-reva-214 @skipOnOcis-OCIS-Storage - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario Outline: Do a PROPFIND of 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 - Then the value of the item "//d:response[1]/d:href" in the response to user "Alice" should match "/remote\.php\/\//" - And the value of the item "//d:response[2]/d:href" in the response to user "Alice" should match "/remote\.php\/\/file1.txt/" - And the value of the item "//d:response[3]/d:href" in the response to user "Alice" should match "/remote\.php\/\/file2.txt/" - Examples: - | dav_version | folder_name | expected_href | - | old | /upload | webdav\/upload | - | old | /folder #2.txt | webdav\/folder%20%232\.txt | - | new | /upload | dav\/files\/%username%\/upload | - | new | /folder #2.txt | dav\/files\/%username%\/folder%20%232\.txt | - - @skipOnOcis-OC-Storage @issue-ocis-reva-265 @skipOnOcis-OCIS-Storage - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario Outline: Do a PROPFIND of various folder names - Given using DAV path - And user "Alice" has created folder "/folder ?2.txt" - When user "Alice" uploads to these filenames with content "uploaded content" using the webDAV API then the results should be as listed - | filename | http-code | exists | - | /folder ?2.txt/file1.txt | 500 | no | - Examples: - | dav_version | - | old | - | new | diff --git a/tests/acceptance/features/apiBugDemonstration/apiWebdavUpload1-uploadFile.feature b/tests/acceptance/features/apiBugDemonstration/apiWebdavUpload1-uploadFile.feature index b722d7b353..e69de29bb2 100644 --- a/tests/acceptance/features/apiBugDemonstration/apiWebdavUpload1-uploadFile.feature +++ b/tests/acceptance/features/apiBugDemonstration/apiWebdavUpload1-uploadFile.feature @@ -1,27 +0,0 @@ -@api -Feature: upload file - As a user - I want to be able to upload files - So that I can store and share files between multiple client systems - - Background: - Given using OCS API version "1" - And user "Alice" has been created with default attributes and without skeleton files - - @skipOnOcis-OC-Storage @issue-product-127 @skipOnOcis-OCIS-Storage - # this scenario passes/fails intermittently on OC storage, so do not run it in CI - # after fixing all issues delete this Scenario and use the one from oC10 core - Scenario Outline: uploading a file inside a folder changes its etag - Given using DAV path - And user "Alice" has created folder "/upload" - And user "Alice" has stored etag of element "/" - When user "Alice" uploads file with content "uploaded content" to "/upload/file.txt" using the WebDAV API - Then the content of file "/upload/file.txt" for user "Alice" should be "uploaded content" -# And the etag of element "/" of user "Alice" should have changed - And the etag of element "/" of user "Alice" should not have changed - Examples: - | dav_version | element | - | old | | - | old | upload | - | new | | - | new | upload | diff --git a/tests/acceptance/features/apiBugDemonstration/apiWebdavUploadTUS-optionsRequest.feature b/tests/acceptance/features/apiBugDemonstration/apiWebdavUploadTUS-optionsRequest.feature index 0a9156a6b3..e69de29bb2 100644 --- a/tests/acceptance/features/apiBugDemonstration/apiWebdavUploadTUS-optionsRequest.feature +++ b/tests/acceptance/features/apiBugDemonstration/apiWebdavUploadTUS-optionsRequest.feature @@ -1,29 +0,0 @@ -@api @issue-ocis-1012 -# after fixing all issues delete these Scenarios and use the one from oC10 core -Feature: OPTIONS request - - Background: - Given user "Alice" has been created with default attributes and without skeleton files - - Scenario: send OPTIONS request to webDav endpoints using the TUS protocol with valid username and wrong password - When user "Alice" requests these endpoints with "OPTIONS" including body "doesnotmatter" using password "invalid" about user "Alice" - | endpoint | - | /remote.php/webdav/ | - | /remote.php/dav/files/%username%/ | - Then the following headers should not be set - | header | - | Tus-Resumable | - | Tus-Version | - | Tus-Extension | - - Scenario: send OPTIONS requests to webDav endpoints using valid password and username of different user - Given user "Brian" has been created with default attributes and without skeleton files - When user "Brian" requests these endpoints with "OPTIONS" including body "doesnotmatter" using the password of user "Alice" - | endpoint | - | /remote.php/webdav/ | - | /remote.php/dav/files/%username%/ | - Then the following headers should not be set - | header | - | Tus-Resumable | - | Tus-Version | - | Tus-Extension | From 73f45deed61277d2f3e10deb1c134689505a0ad6 Mon Sep 17 00:00:00 2001 From: Swikriti Tripathi Date: Mon, 2 Aug 2021 16:31:33 +0545 Subject: [PATCH 2/2] changes made in expected to fail file --- .../expected-failures-API-on-OCIS-storage.md | 7 +++---- ...pected-failures-API-on-OWNCLOUD-storage.md | 7 +++---- .../apiAuthOcs-ocsDELETEAuth.feature | 1 - .../apiAuthOcs-ocsGETAuth.feature | 0 .../apiAuthOcs-ocsPOSTAuth.feature | 0 .../apiAuthOcs-ocsPUTAuth.feature | 0 .../apiAuthWebDav-webDavLOCKAuth.feature | 0 .../apiAuthWebDav-webDavMOVEAuth.feature | 0 ...ilities-capabilitiesWithNormalUser.feature | 0 .../apiBugDemonstration/apiMain-main.feature | 0 ...piShareManagementBasic-createShare.feature | 0 .../apiShareOperations-gettingShares.feature | 0 ...harePublicLink2-copyFromPublicLink.feature | 0 .../apiShareUpdate-updateShare.feature | 0 .../apiTrashbin-trashbinDelete.feature | 0 .../apiVersions-fileVersions.feature | 10 --------- .../apiWebdavMove1-moveFolder.feature | 0 ...vMove1-moveFolderToBlacklistedName.feature | 0 .../apiWebdavMove2-moveFile.feature | 1 - ...davMove2-moveFileToBlacklistedName.feature | 0 .../apiWebdavOperations-refuseAccess.feature | 0 .../apiWebdavProperties1-createFolder.feature | 0 ...ebdavProperties2-getFileProperties.feature | 0 .../apiWebdavUpload1-uploadFile.feature | 0 .../apiWebdavUploadTUS-optionsRequest.feature | 0 .../apiWebdavUploadTUS-uploadFile.feature | 21 ------------------- 26 files changed, 6 insertions(+), 41 deletions(-) delete mode 100644 tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsDELETEAuth.feature delete mode 100644 tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsGETAuth.feature delete mode 100644 tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsPOSTAuth.feature delete mode 100644 tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsPUTAuth.feature delete mode 100644 tests/acceptance/features/apiBugDemonstration/apiAuthWebDav-webDavLOCKAuth.feature delete mode 100644 tests/acceptance/features/apiBugDemonstration/apiAuthWebDav-webDavMOVEAuth.feature delete mode 100644 tests/acceptance/features/apiBugDemonstration/apiCapabilities-capabilitiesWithNormalUser.feature delete mode 100644 tests/acceptance/features/apiBugDemonstration/apiMain-main.feature delete mode 100644 tests/acceptance/features/apiBugDemonstration/apiShareManagementBasic-createShare.feature delete mode 100644 tests/acceptance/features/apiBugDemonstration/apiShareOperations-gettingShares.feature delete mode 100644 tests/acceptance/features/apiBugDemonstration/apiSharePublicLink2-copyFromPublicLink.feature delete mode 100644 tests/acceptance/features/apiBugDemonstration/apiShareUpdate-updateShare.feature delete mode 100644 tests/acceptance/features/apiBugDemonstration/apiTrashbin-trashbinDelete.feature delete mode 100644 tests/acceptance/features/apiBugDemonstration/apiVersions-fileVersions.feature delete mode 100644 tests/acceptance/features/apiBugDemonstration/apiWebdavMove1-moveFolder.feature delete mode 100644 tests/acceptance/features/apiBugDemonstration/apiWebdavMove1-moveFolderToBlacklistedName.feature delete mode 100644 tests/acceptance/features/apiBugDemonstration/apiWebdavMove2-moveFile.feature delete mode 100644 tests/acceptance/features/apiBugDemonstration/apiWebdavMove2-moveFileToBlacklistedName.feature delete mode 100644 tests/acceptance/features/apiBugDemonstration/apiWebdavOperations-refuseAccess.feature delete mode 100644 tests/acceptance/features/apiBugDemonstration/apiWebdavProperties1-createFolder.feature delete mode 100644 tests/acceptance/features/apiBugDemonstration/apiWebdavProperties2-getFileProperties.feature delete mode 100644 tests/acceptance/features/apiBugDemonstration/apiWebdavUpload1-uploadFile.feature delete mode 100644 tests/acceptance/features/apiBugDemonstration/apiWebdavUploadTUS-optionsRequest.feature delete mode 100644 tests/acceptance/features/apiBugDemonstration/apiWebdavUploadTUS-uploadFile.feature diff --git a/tests/acceptance/expected-failures-API-on-OCIS-storage.md b/tests/acceptance/expected-failures-API-on-OCIS-storage.md index 6903d71bbf..b08a2424f6 100644 --- a/tests/acceptance/expected-failures-API-on-OCIS-storage.md +++ b/tests/acceptance/expected-failures-API-on-OCIS-storage.md @@ -16,10 +16,6 @@ Basic file management like up and download, move, copy, properties, trash, versi #### [invalid file-names should not be created using the TUS protocol](https://github.com/owncloud/ocis/issues/1001) -#### [TUS OPTIONS requests do not reply with TUS headers when invalid password](https://github.com/owncloud/ocis/issues/1012) -- [apiWebdavUploadTUS/optionsRequest.feature:33](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L33) -- [apiWebdavUploadTUS/optionsRequest.feature:46](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L46) - #### [renaming to banned name works](https://github.com/owncloud/ocis/issues/1295) #### [Getting information about a folder overwritten by a file gives 500 error instead of 404](https://github.com/owncloud/ocis/issues/1239) @@ -1622,6 +1618,9 @@ Scenario Outline: Do a PROPFIND to a non-existing URL - [apiWebdavUploadTUS/uploadToShare.feature:249](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToShare.feature#L249) - [apiWebdavUploadTUS/uploadToShare.feature:289](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToShare.feature#L289) - [apiWebdavUploadTUS/uploadToShare.feature:290](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToShare.feature#L290) +#### [TUS OPTIONS requests do not reply with TUS headers when invalid password](https://github.com/owncloud/ocis/issues/1012) +- [apiWebdavUploadTUS/optionsRequest.feature:33](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L33) +- [apiWebdavUploadTUS/optionsRequest.feature:46](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L46) #### [Share inaccessible if folder with same name was deleted and recreated](https://github.com/owncloud/ocis/issues/1787) - [apiShareReshareToShares1/reShare.feature:269](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiShareReshareToShares1/reShare.feature#L269) diff --git a/tests/acceptance/expected-failures-API-on-OWNCLOUD-storage.md b/tests/acceptance/expected-failures-API-on-OWNCLOUD-storage.md index eb0ddbdbfe..8701f00c11 100644 --- a/tests/acceptance/expected-failures-API-on-OWNCLOUD-storage.md +++ b/tests/acceptance/expected-failures-API-on-OWNCLOUD-storage.md @@ -48,10 +48,6 @@ The following scenarios fail on OWNCLOUD storage but not on OCIS storage: - [apiWebdavUploadTUS/uploadToNonExistingFolder.feature:60](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToNonExistingFolder.feature#L60) - [apiWebdavUploadTUS/uploadToNonExistingFolder.feature:61](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToNonExistingFolder.feature#L61) -#### [TUS OPTIONS requests do not reply with TUS headers when invalid password](https://github.com/owncloud/ocis/issues/1012) -- [apiWebdavUploadTUS/optionsRequest.feature:33](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L33) -- [apiWebdavUploadTUS/optionsRequest.feature:46](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L46) - #### [renaming to banned name works](https://github.com/owncloud/ocis/issues/1295) #### [Getting information about a folder overwritten by a file gives 500 error instead of 404](https://github.com/owncloud/ocis/issues/1239) @@ -1805,6 +1801,9 @@ Scenario Outline: Do a PROPFIND to a non-existing URL - [apiWebdavUploadTUS/uploadToShare.feature:249](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToShare.feature#L249) - [apiWebdavUploadTUS/uploadToShare.feature:289](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToShare.feature#L289) - [apiWebdavUploadTUS/uploadToShare.feature:290](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToShare.feature#L290) +#### [TUS OPTIONS requests do not reply with TUS headers when invalid password](https://github.com/owncloud/ocis/issues/1012) +- [apiWebdavUploadTUS/optionsRequest.feature:33](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L33) +- [apiWebdavUploadTUS/optionsRequest.feature:46](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L46) #### [Trying to accept a share with invalid ID gives incorrect OCS and HTTP status](https://github.com/owncloud/ocis/issues/2111) - [apiShareOperationsToShares2/shareAccessByID.feature:85](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiShareOperationsToShares2/shareAccessByID.feature#L85) diff --git a/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsDELETEAuth.feature b/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsDELETEAuth.feature deleted file mode 100644 index 8b13789179..0000000000 --- a/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsDELETEAuth.feature +++ /dev/null @@ -1 +0,0 @@ - diff --git a/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsGETAuth.feature b/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsGETAuth.feature deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsPOSTAuth.feature b/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsPOSTAuth.feature deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsPUTAuth.feature b/tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsPUTAuth.feature deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/tests/acceptance/features/apiBugDemonstration/apiAuthWebDav-webDavLOCKAuth.feature b/tests/acceptance/features/apiBugDemonstration/apiAuthWebDav-webDavLOCKAuth.feature deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/tests/acceptance/features/apiBugDemonstration/apiAuthWebDav-webDavMOVEAuth.feature b/tests/acceptance/features/apiBugDemonstration/apiAuthWebDav-webDavMOVEAuth.feature deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/tests/acceptance/features/apiBugDemonstration/apiCapabilities-capabilitiesWithNormalUser.feature b/tests/acceptance/features/apiBugDemonstration/apiCapabilities-capabilitiesWithNormalUser.feature deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/tests/acceptance/features/apiBugDemonstration/apiMain-main.feature b/tests/acceptance/features/apiBugDemonstration/apiMain-main.feature deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/tests/acceptance/features/apiBugDemonstration/apiShareManagementBasic-createShare.feature b/tests/acceptance/features/apiBugDemonstration/apiShareManagementBasic-createShare.feature deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/tests/acceptance/features/apiBugDemonstration/apiShareOperations-gettingShares.feature b/tests/acceptance/features/apiBugDemonstration/apiShareOperations-gettingShares.feature deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/tests/acceptance/features/apiBugDemonstration/apiSharePublicLink2-copyFromPublicLink.feature b/tests/acceptance/features/apiBugDemonstration/apiSharePublicLink2-copyFromPublicLink.feature deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/tests/acceptance/features/apiBugDemonstration/apiShareUpdate-updateShare.feature b/tests/acceptance/features/apiBugDemonstration/apiShareUpdate-updateShare.feature deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/tests/acceptance/features/apiBugDemonstration/apiTrashbin-trashbinDelete.feature b/tests/acceptance/features/apiBugDemonstration/apiTrashbin-trashbinDelete.feature deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/tests/acceptance/features/apiBugDemonstration/apiVersions-fileVersions.feature b/tests/acceptance/features/apiBugDemonstration/apiVersions-fileVersions.feature deleted file mode 100644 index 38768cf51e..0000000000 --- a/tests/acceptance/features/apiBugDemonstration/apiVersions-fileVersions.feature +++ /dev/null @@ -1,10 +0,0 @@ -@api @files_versions-app-required @skipOnOcis-EOS-Storage @issue-ocis-reva-275 - -Feature: dav-versions - - Background: - Given using OCS API version "2" - And using new DAV path - And user "Alice" has been created with default attributes and without skeleton files - - diff --git a/tests/acceptance/features/apiBugDemonstration/apiWebdavMove1-moveFolder.feature b/tests/acceptance/features/apiBugDemonstration/apiWebdavMove1-moveFolder.feature deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/tests/acceptance/features/apiBugDemonstration/apiWebdavMove1-moveFolderToBlacklistedName.feature b/tests/acceptance/features/apiBugDemonstration/apiWebdavMove1-moveFolderToBlacklistedName.feature deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/tests/acceptance/features/apiBugDemonstration/apiWebdavMove2-moveFile.feature b/tests/acceptance/features/apiBugDemonstration/apiWebdavMove2-moveFile.feature deleted file mode 100644 index 8b13789179..0000000000 --- a/tests/acceptance/features/apiBugDemonstration/apiWebdavMove2-moveFile.feature +++ /dev/null @@ -1 +0,0 @@ - diff --git a/tests/acceptance/features/apiBugDemonstration/apiWebdavMove2-moveFileToBlacklistedName.feature b/tests/acceptance/features/apiBugDemonstration/apiWebdavMove2-moveFileToBlacklistedName.feature deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/tests/acceptance/features/apiBugDemonstration/apiWebdavOperations-refuseAccess.feature b/tests/acceptance/features/apiBugDemonstration/apiWebdavOperations-refuseAccess.feature deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/tests/acceptance/features/apiBugDemonstration/apiWebdavProperties1-createFolder.feature b/tests/acceptance/features/apiBugDemonstration/apiWebdavProperties1-createFolder.feature deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/tests/acceptance/features/apiBugDemonstration/apiWebdavProperties2-getFileProperties.feature b/tests/acceptance/features/apiBugDemonstration/apiWebdavProperties2-getFileProperties.feature deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/tests/acceptance/features/apiBugDemonstration/apiWebdavUpload1-uploadFile.feature b/tests/acceptance/features/apiBugDemonstration/apiWebdavUpload1-uploadFile.feature deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/tests/acceptance/features/apiBugDemonstration/apiWebdavUploadTUS-optionsRequest.feature b/tests/acceptance/features/apiBugDemonstration/apiWebdavUploadTUS-optionsRequest.feature deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/tests/acceptance/features/apiBugDemonstration/apiWebdavUploadTUS-uploadFile.feature b/tests/acceptance/features/apiBugDemonstration/apiWebdavUploadTUS-uploadFile.feature deleted file mode 100644 index d17cb4e61b..0000000000 --- a/tests/acceptance/features/apiBugDemonstration/apiWebdavUploadTUS-uploadFile.feature +++ /dev/null @@ -1,21 +0,0 @@ -@api @issue-ocis-1141 -# after fixing all issues delete these Scenarios and use the one from oC10 core -Feature: upload file - As a user - I want to be able to upload files - So that I can store and share files between multiple client systems - - Scenario Outline: upload a file using the resource URL of another user - Given using DAV path - And user "Alice" has been created with default attributes and without skeleton files - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created a new TUS resource on the WebDAV API with these headers: - | Upload-Length | 5 | - | Upload-Metadata | filename dGV4dEZpbGUudHh0 | - When user "Brian" sends a chunk to the last created TUS Location with offset "0" and data "12345" using the WebDAV API - Then the HTTP status code should be "204" - And as "Alice" file "/textFile.txt" should exist - Examples: - | dav_version | - | old | - | new |