diff --git a/.drone.star b/.drone.star index dc3258777ff..bae39f81046 100644 --- a/.drone.star +++ b/.drone.star @@ -848,7 +848,7 @@ def wopiValidatorTests(ctx, storage, accounts_hash_difficulty = 4): def coreApiTests(ctx, part_number = 1, number_of_parts = 1, storage = "ocis", accounts_hash_difficulty = 4): early_fail = config["apiTests"]["earlyFail"] if "earlyFail" in config["apiTests"] else False - filterTags = "~@skipOnGraph&&~@skipOnOcis&&~@notToImplementOnOCIS&&~@toImplementOnOCIS&&~comments-app-required&&~@federation-app-required&&~@notifications-app-required&&~systemtags-app-required&&~@local_storage&&~@skipOnOcis-%s-Storage&&~@caldav&&~@carddav" % ("OC" if storage == "owncloud" else "OCIS") + filterTags = "~@skipOnGraph&&~@skipOnOcis&&~@toImplementOnOCIS&&~comments-app-required&&~@federation-app-required&&~@notifications-app-required&&~systemtags-app-required&&~@local_storage&&~@skipOnOcis-%s-Storage&&~@caldav&&~@carddav" % ("OC" if storage == "owncloud" else "OCIS") expectedFailuresFile = "%s/tests/acceptance/expected-failures-API-on-%s-storage.md" % (dirs["base"], storage.upper()) return { diff --git a/tests/acceptance/config/behat-core.yml b/tests/acceptance/config/behat-core.yml index 58078199080..f0bc9ff95ec 100644 --- a/tests/acceptance/config/behat-core.yml +++ b/tests/acceptance/config/behat-core.yml @@ -304,17 +304,6 @@ default: - WebDavLockingContext: - WebDavPropertiesContext: - coreApiWebdavLocks3: - paths: - - "%paths.base%/../features/coreApiWebdavLocks3" - context: *common_ldap_suite_context - contexts: - - FeatureContext: *common_feature_context_params - - OccContext: - - PublicWebDavContext: - - WebDavLockingContext: - - WebDavPropertiesContext: - coreApiWebdavLocksUnlock: paths: - "%paths.base%/../features/coreApiWebdavLocksUnlock" diff --git a/tests/acceptance/docker/src/run-tests.sh b/tests/acceptance/docker/src/run-tests.sh index e61dfb5f1ff..b75649a179f 100644 --- a/tests/acceptance/docker/src/run-tests.sh +++ b/tests/acceptance/docker/src/run-tests.sh @@ -12,7 +12,7 @@ then if [ "$STORAGE_DRIVER" = "ocis" ] then export OCIS_REVA_DATA_ROOT='' - export BEHAT_FILTER_TAGS='~@notToImplementOnOCIS&&~@toImplementOnOCIS&&~comments-app-required&&~@federation-app-required&&~@notifications-app-required&&~systemtags-app-required&&~@local_storage&&~@skipOnOcis-OCIS-Storage' + export BEHAT_FILTER_TAGS='~@toImplementOnOCIS&&~comments-app-required&&~@federation-app-required&&~@notifications-app-required&&~systemtags-app-required&&~@local_storage&&~@skipOnOcis-OCIS-Storage' export OCIS_SKELETON_STRATEGY='upload' export EXPECTED_FAILURES_FILE='/drone/src/tests/acceptance/expected-failures-API-on-OCIS-storage.md' elif [ "$STORAGE_DRIVER" = "s3ng" ] diff --git a/tests/acceptance/features/coreApiAuth/webDavAuth.feature b/tests/acceptance/features/coreApiAuth/webDavAuth.feature index fadc2cbeee9..2ad55fed5f6 100644 --- a/tests/acceptance/features/coreApiAuth/webDavAuth.feature +++ b/tests/acceptance/features/coreApiAuth/webDavAuth.feature @@ -26,15 +26,3 @@ Feature: auth Examples: | dav_path | | /dav/spaces/%spaceid% | - - @smokeTest @notToImplementOnOCIS @issue-ocis-reva-28 - Scenario: using WebDAV with token auth - Given a new client token for "Alice" has been generated - When user "Alice" requests "/remote.php/webdav" with "PROPFIND" using basic token auth - Then the HTTP status code should be "207" - - @smokeTest @notToImplementOnOCIS - Scenario: using WebDAV with browser session - Given a new browser session for "Alice" has been started - When the user requests "/remote.php/webdav" with "PROPFIND" using the browser session - Then the HTTP status code should be "207" diff --git a/tests/acceptance/features/coreApiAuthOcs/ocsGETAuth.feature b/tests/acceptance/features/coreApiAuthOcs/ocsGETAuth.feature index 9bdba239a16..a603d28fff9 100644 --- a/tests/acceptance/features/coreApiAuthOcs/ocsGETAuth.feature +++ b/tests/acceptance/features/coreApiAuthOcs/ocsGETAuth.feature @@ -149,100 +149,3 @@ Feature: auth | /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" - - @notToImplementOnOCIS @issue-ocis-reva-30 @issue-ocis-reva-28 - Scenario: using OCS with token auth of a normal user - Given a new client token for "Alice" has been generated - When user "Alice" requests these endpoints with "GET" using basic token auth - | endpoint | - | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares | - | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending | - | /ocs/v1.php/apps/files_sharing/api/v1/shares | - | /ocs/v1.php/config | - | /ocs/v1.php/privatedata/getattribute | - 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 user "Alice" requests these endpoints with "GET" using basic token auth - | endpoint | - | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares | - | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending | - | /ocs/v2.php/apps/files_sharing/api/v1/shares | - | /ocs/v2.php/config | - | /ocs/v2.php/privatedata/getattribute | - 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" - When user "Alice" requests these endpoints with "GET" using basic token auth - | endpoint | - | /ocs/v1.php/cloud/apps | - | /ocs/v1.php/cloud/users | - | /ocs/v1.php/cloud/groups | - | /ocs/v2.php/cloud/apps | - | /ocs/v2.php/cloud/groups | - | /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 "997" - - @notToImplementOnOCIS - Scenario: using OCS with browser session of normal user - Given a new browser session for "Alice" has been started - When the user requests these endpoints with "GET" using a new browser session - | endpoint | - | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares | - | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending | - | /ocs/v1.php/apps/files_sharing/api/v1/shares | - | /ocs/v1.php/config | - | /ocs/v1.php/privatedata/getattribute | - 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 requests these endpoints with "GET" using a new browser session - | endpoint | - | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares | - | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending | - | /ocs/v2.php/apps/files_sharing/api/v1/shares | - | /ocs/v2.php/config | - | /ocs/v2.php/privatedata/getattribute | - 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" - When the user requests these endpoints with "GET" using a new browser session - | endpoint | - | /ocs/v1.php/cloud/apps | - | /ocs/v2.php/cloud/apps | - | /ocs/v1.php/cloud/groups | - | /ocs/v2.php/cloud/groups | - | /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 "997" - - @notToImplementOnOCIS - Scenario: using OCS with an app password of a normal user - Given a new browser session for "Alice" has been started - And the user has generated a new app password named "my-client" - When the user requests these endpoints with "GET" using the generated app password - | endpoint | - | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares | - | /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending | - | /ocs/v1.php/apps/files_sharing/api/v1/shares | - | /ocs/v1.php/config | - | /ocs/v1.php/privatedata/getattribute | - 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 requests these endpoints with "GET" using the generated app password - | endpoint | - | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares | - | /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending | - | /ocs/v2.php/apps/files_sharing/api/v1/shares | - | /ocs/v2.php/config | - | /ocs/v2.php/privatedata/getattribute | - 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" - When the user requests these endpoints with "GET" using the generated app password - | endpoint | - | /ocs/v1.php/cloud/apps | - | /ocs/v2.php/cloud/apps | - | /ocs/v1.php/cloud/groups | - | /ocs/v2.php/cloud/groups | - | /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 "997" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavCOPYAuth.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavCOPYAuth.feature index bb1317fbaf1..9aea7ad6570 100644 --- a/tests/acceptance/features/coreApiAuthWebDav/webDavCOPYAuth.feature +++ b/tests/acceptance/features/coreApiAuthWebDav/webDavCOPYAuth.feature @@ -133,35 +133,6 @@ Feature: COPY file/folder | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" - @notToImplementOnOCIS @issue-ocis-reva-37 - Scenario: send COPY requests to webDav endpoints using token authentication should not work - Given token auth has been enforced - And a new browser session for "Alice" has been started - And the user has generated a new app password named "my-client" - When the user requests these endpoints with "COPY" using the generated app password about user "Alice" - | endpoint | - | /remote.php/webdav/textfile0.txt | - | /remote.php/dav/files/%username%/textfile0.txt | - | /remote.php/webdav/PARENT | - | /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 "401" - - @notToImplementOnOCIS @issue-ocis-reva-37 - Scenario: send COPY requests to webDav endpoints using app password token as password - Given token auth has been enforced - And a new browser session for "Alice" has been started - And the user has generated a new app password named "my-client" - When the user "Alice" requests these endpoints with "COPY" with body "doesnotmatter" using basic auth and generated app password about user "Alice" - | endpoint | - # The token was valid and accepted but the body is invalid so it gives 403 - | /remote.php/webdav/textfile0.txt | - | /remote.php/dav/files/%username%/textfile1.txt | - | /remote.php/dav/files/%username%/PARENT/parent.txt | - | /remote.php/webdav/PARENT | - | /remote.php/dav/files/%username%/FOLDER | - Then the HTTP status code of responses on all endpoints should be "403" - @skipOnOcV10 Scenario: send COPY requests to webDav endpoints with body as normal user When user "Alice" requests these endpoints with "COPY" including body "doesnotmatter" about user "Alice" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavLOCKAuth.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavLOCKAuth.feature index 623a6b36783..56426874104 100644 --- a/tests/acceptance/features/coreApiAuthWebDav/webDavLOCKAuth.feature +++ b/tests/acceptance/features/coreApiAuthWebDav/webDavLOCKAuth.feature @@ -135,31 +135,3 @@ Feature: LOCK file/folder | /remote.php/dav/spaces/%spaceid%/PARENT | | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" - - @notToImplementOnOCIS @issue-ocis-reva-37 - Scenario: send LOCK requests to webDav endpoints using token authentication should not work - Given token auth has been enforced - And a new browser session for "Alice" has been started - And the user has generated a new app password named "my-client" - When the user requests these endpoints with "LOCK" using the generated app password about user "Alice" - | endpoint | - | /remote.php/webdav/textfile0.txt | - | /remote.php/dav/files/%username%/textfile0.txt | - | /remote.php/webdav/PARENT | - | /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 "401" - - @notToImplementOnOCIS @issue-ocis-reva-37 - Scenario: send LOCK requests to webDav endpoints using app password token as password - Given token auth has been enforced - And a new browser session for "Alice" has been started - And the user has generated a new app password named "my-client" - When the user "Alice" requests these endpoints with "LOCK" to get property "d:shared" using basic auth and generated app password about user "Alice" - | endpoint | - | /remote.php/webdav/textfile0.txt | - | /remote.php/dav/files/%username%/textfile1.txt | - | /remote.php/dav/files/%username%/PARENT/parent.txt | - | /remote.php/webdav/PARENT | - | /remote.php/dav/files/%username%/FOLDER | - Then the HTTP status code of responses on all endpoints should be "200" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavMKCOLAuth.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavMKCOLAuth.feature index 9f49fd4d650..189ebe68d94 100644 --- a/tests/acceptance/features/coreApiAuthWebDav/webDavMKCOLAuth.feature +++ b/tests/acceptance/features/coreApiAuthWebDav/webDavMKCOLAuth.feature @@ -153,31 +153,3 @@ Feature: create folder using MKCOL | /remote.php/dav/spaces/%spaceid%/PARENT | | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" - - @notToImplementOnOCIS @issue-ocis-reva-37 - Scenario: send MKCOL requests to webDav endpoints using token authentication should not work - Given token auth has been enforced - And a new browser session for "Alice" has been started - And the user has generated a new app password named "my-client" - When the user requests these endpoints with "MKCOL" using the generated app password about user "Alice" - | endpoint | - | /remote.php/webdav/textfile0.txt | - | /remote.php/dav/files/%username%/textfile0.txt | - | /remote.php/webdav/PARENT | - | /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 "401" - - @notToImplementOnOCIS @issue-ocis-reva-37 - Scenario: send MKCOL requests to webDav endpoints using app password token as password - Given token auth has been enforced - And a new browser session for "Alice" has been started - And the user has generated a new app password named "my-client" - When the user "Alice" requests these endpoints with "MKCOL" using basic auth and generated app password about user "Alice" - | endpoint | - | /remote.php/webdav/newCol | - | /remote.php/dav/files/%username%/newCol1 | - | /remote.php/dav/files/%username%/PARENT/newCol | - | /remote.php/webdav/COL | - | /remote.php/dav/files/%username%/FOLDER/newCol | - Then the HTTP status code of responses on all endpoints should be "201" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavMOVEAuth.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavMOVEAuth.feature index b2e2723b5b7..ae17e36b5fa 100644 --- a/tests/acceptance/features/coreApiAuthWebDav/webDavMOVEAuth.feature +++ b/tests/acceptance/features/coreApiAuthWebDav/webDavMOVEAuth.feature @@ -129,35 +129,6 @@ Feature: MOVE file/folder | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" - @notToImplementOnOCIS @issue-ocis-reva-37 - Scenario: send MOVE requests to webDav endpoints using token authentication should not work - Given token auth has been enforced - And a new browser session for "Alice" has been started - And the user has generated a new app password named "my-client" - When the user requests these endpoints with "MOVE" using the generated app password about user "Alice" - | endpoint | - | /remote.php/webdav/textfile0.txt | - | /remote.php/dav/files/%username%/textfile0.txt | - | /remote.php/webdav/PARENT | - | /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 "401" - - @notToImplementOnOCIS @issue-ocis-reva-37 - Scenario: send MOVE requests to webDav endpoints using app password token as password - Given token auth has been enforced - And a new browser session for "Alice" has been started - And the user has generated a new app password named "my-client" - When the user "Alice" requests these endpoints with "MOVE" with body "doesnotmatter" using basic auth and generated app password about user "Alice" - | endpoint | - # The token was valid and accepted but the body is invalid so it gives 403 - | /remote.php/webdav/textfile0.txt | - | /remote.php/dav/files/%username%/textfile1.txt | - | /remote.php/dav/files/%username%/PARENT/parent.txt | - | /remote.php/webdav/PARENT | - | /remote.php/dav/files/%username%/FOLDER | - Then the HTTP status code of responses on all endpoints should be "403" - @skipOnOcV10 Scenario: send MOVE requests to webDav endpoints with body as normal user When user "Alice" requests these endpoints with "MOVE" including body "doesnotmatter" about user "Alice" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavPOSTAuth.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavPOSTAuth.feature index 1e90596219f..b80bc5d4afb 100644 --- a/tests/acceptance/features/coreApiAuthWebDav/webDavPOSTAuth.feature +++ b/tests/acceptance/features/coreApiAuthWebDav/webDavPOSTAuth.feature @@ -129,32 +129,3 @@ Feature: get file info using POST | /remote.php/dav/spaces/%spaceid%/PARENT | | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" - - @notToImplementOnOCIS @issue-ocis-reva-37 - Scenario: send POST requests to webDav endpoints using token authentication should not work - Given token auth has been enforced - And a new browser session for "Alice" has been started - And the user has generated a new app password named "my-client" - When the user requests these endpoints with "POST" using the generated app password about user "Alice" - | endpoint | - | /remote.php/webdav/textfile0.txt | - | /remote.php/dav/files/%username%/textfile0.txt | - | /remote.php/webdav/PARENT | - | /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 "401" - - @notToImplementOnOCIS @issue-ocis-reva-37 - Scenario: send POST requests to webDav endpoints using app password token as password - Given token auth has been enforced - And a new browser session for "Alice" has been started - And the user has generated a new app password named "my-client" - When the user "Alice" requests these endpoints with "POST" with body "doesnotmatter" using basic auth and generated app password about user "Alice" - | endpoint | - # this method is not available so gives 501 - | /remote.php/webdav/textfile0.txt | - | /remote.php/dav/files/%username%/textfile1.txt | - | /remote.php/dav/files/%username%/PARENT/parent.txt | - | /remote.php/webdav/PARENT | - | /remote.php/dav/files/%username%/FOLDER | - Then the HTTP status code of responses on all endpoints should be "501" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavPROPFINDAuth.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavPROPFINDAuth.feature index d1bfee252d5..84fc5df03df 100644 --- a/tests/acceptance/features/coreApiAuthWebDav/webDavPROPFINDAuth.feature +++ b/tests/acceptance/features/coreApiAuthWebDav/webDavPROPFINDAuth.feature @@ -128,31 +128,3 @@ Feature: get file info using PROPFIND | /remote.php/dav/spaces/%spaceid%/PARENT | | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" - - @notToImplementOnOCIS @issue-ocis-reva-37 - Scenario: send PROPFIND requests to webDav endpoints using token authentication should not work - Given token auth has been enforced - And a new browser session for "Alice" has been started - And the user has generated a new app password named "my-client" - When the user requests these endpoints with "PROPFIND" using the generated app password about user "Alice" - | endpoint | - | /remote.php/webdav/textfile0.txt | - | /remote.php/dav/files/%username%/textfile0.txt | - | /remote.php/webdav/PARENT | - | /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 "401" - - @notToImplementOnOCIS @issue-ocis-reva-37 - Scenario: send PROPFIND requests to webDav endpoints using app password token as password - Given token auth has been enforced - And a new browser session for "Alice" has been started - And the user has generated a new app password named "my-client" - When the user "Alice" requests these endpoints with "PROPFIND" to get property "d:getetag" using basic auth and generated app password 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 | - | /remote.php/webdav/PARENT | - | /remote.php/webdav/textfile0.txt | - Then the HTTP status code of responses on all endpoints should be "207" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavPROPPATCHAuth.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavPROPPATCHAuth.feature index 3c1b893b9cc..673db664dac 100644 --- a/tests/acceptance/features/coreApiAuthWebDav/webDavPROPPATCHAuth.feature +++ b/tests/acceptance/features/coreApiAuthWebDav/webDavPROPPATCHAuth.feature @@ -129,31 +129,3 @@ Feature: PROPPATCH file/folder | /remote.php/dav/spaces/%spaceid%/PARENT | | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" - - @notToImplementOnOCIS @issue-ocis-reva-37 - Scenario: send PROPPATCH requests to webDav endpoints using token authentication should not work - Given token auth has been enforced - And a new browser session for "Alice" has been started - And the user has generated a new app password named "my-client" - When the user requests these endpoints with "PROPPATCH" using the generated app password about user "Alice" - | endpoint | - | /remote.php/webdav/textfile0.txt | - | /remote.php/dav/files/%username%/textfile0.txt | - | /remote.php/webdav/PARENT | - | /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 "401" - - @notToImplementOnOCIS @issue-ocis-reva-37 - Scenario: send PROPPATCH requests to webDav endpoints using app password token as password - Given token auth has been enforced - And a new browser session for "Alice" has been started - And the user has generated a new app password named "my-client" - When the user "Alice" requests these endpoints with "PROPPATCH" to set property "favorite" using basic auth and generated app password about user "Alice" - | endpoint | - | /remote.php/webdav/textfile0.txt | - | /remote.php/dav/files/%username%/textfile1.txt | - | /remote.php/dav/files/%username%/PARENT/parent.txt | - | /remote.php/webdav/PARENT | - | /remote.php/dav/files/%username%/FOLDER | - Then the HTTP status code of responses on all endpoints should be "207" diff --git a/tests/acceptance/features/coreApiAuthWebDav/webDavPUTAuth.feature b/tests/acceptance/features/coreApiAuthWebDav/webDavPUTAuth.feature index b12dba719e0..e04c537d1b8 100644 --- a/tests/acceptance/features/coreApiAuthWebDav/webDavPUTAuth.feature +++ b/tests/acceptance/features/coreApiAuthWebDav/webDavPUTAuth.feature @@ -135,40 +135,3 @@ Feature: get file info using PUT | /remote.php/dav/spaces/%spaceid%/PARENT | | /remote.php/dav/spaces/%spaceid%/PARENT/parent.txt | Then the HTTP status code of responses on all endpoints should be "401" - - @notToImplementOnOCIS @issue-ocis-reva-37 - Scenario: send PUT requests to webDav endpoints using token authentication should not work - Given token auth has been enforced - And a new browser session for "Alice" has been started - And the user has generated a new app password named "my-client" - When the user requests these endpoints with "PUT" using the generated app password about user "Alice" - | endpoint | - | /remote.php/webdav/textfile0.txt | - | /remote.php/dav/files/%username%/textfile0.txt | - | /remote.php/webdav/PARENT | - | /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 "401" - - @notToImplementOnOCIS @issue-ocis-reva-37 - Scenario: send PUT requests to webDav endpoints using app password token as password - Given token auth has been enforced - And a new browser session for "Alice" has been started - And the user has generated a new app password named "my-client" - When the user "Alice" requests these endpoints with "PUT" with body "doesnotmatter" using basic auth and generated app password about user "Alice" - | endpoint | - | /remote.php/webdav/textfile0.txt | - | /remote.php/dav/files/%username%/textfile1.txt | - | /remote.php/dav/files/%username%/PARENT/parent.txt | - Then the HTTP status code of responses on all endpoints should be "204" - When the user "Alice" requests these endpoints with "PUT" with body "doesnotmatter" using basic auth and generated app password about user "Alice" - | endpoint | - # this folder is created, so gives 201 - CREATED - | /remote.php/webdav/PARENS | - | /remote.php/dav/files/%username%/FOLDERS | - Then the HTTP status code of responses on all endpoints should be "201" - When the user "Alice" requests these endpoints with "PUT" with body "doesnotmatter" using basic auth and generated app password about user "Alice" - | endpoint | - # this folder already exists so gives 409 - CONFLICT - | /remote.php/dav/files/%username%/FOLDER | - Then the HTTP status code of responses on all endpoints should be "409" diff --git a/tests/acceptance/features/coreApiFavorites/favorites.feature b/tests/acceptance/features/coreApiFavorites/favorites.feature index 553c4c1af85..7f0aeab97f7 100644 --- a/tests/acceptance/features/coreApiFavorites/favorites.feature +++ b/tests/acceptance/features/coreApiFavorites/favorites.feature @@ -147,22 +147,6 @@ Feature: favorite | dav_version | | spaces | - @files_sharing-app-required @notToImplementOnOCIS - Scenario Outline: moving a favorite file out of a share keeps favorite state - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created folder "/shared" - And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" - And user "Alice" has shared folder "/shared" with user "Brian" - And user "Brian" has favorited element "/shared/shared_file.txt" - When user "Brian" moves file "/shared/shared_file.txt" to "/taken_out.txt" using the WebDAV API - Then user "Brian" should have favorited the following elements - | /taken_out.txt | - Examples: - | dav_version | - | old | - | new | - @issue-33840 @skipOnOcV10 Scenario Outline: Get favorited elements and limit count of entries Given using DAV path @@ -221,35 +205,6 @@ Feature: favorite | dav_version | | spaces | - @files_sharing-app-required @notToImplementOnOCIS - Scenario Outline: sharer file favorite state should not change the favorite state of sharee - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has moved file "/textfile0.txt" to "/favoriteFile.txt" - And user "Alice" has shared file "/favoriteFile.txt" with user "Brian" - When user "Alice" favorites element "/favoriteFile.txt" using the WebDAV API - Then the HTTP status code should be "207" - And as user "Alice" file "/favoriteFile.txt" should be favorited - And as user "Brian" file "/favoriteFile.txt" should not be favorited - Examples: - | dav_version | - | old | - | new | - - @files_sharing-app-required @notToImplementOnOCIS - Scenario Outline: sharee file favorite state should not change the favorite state of sharer - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has moved file "/textfile0.txt" to "/favoriteFile.txt" - And user "Alice" has shared file "/favoriteFile.txt" with user "Brian" - When user "Brian" favorites element "/favoriteFile.txt" using the WebDAV API - Then the HTTP status code should be "207" - And as user "Alice" file "/favoriteFile.txt" should not be favorited - Examples: - | dav_version | - | old | - | new | - Scenario Outline: favoriting a folder does not change the favorite state of elements inside the folder Given using DAV path @@ -268,40 +223,3 @@ Feature: favorite Examples: | dav_version | | spaces | - - @files_sharing-app-required @notToImplementOnOCIS - Scenario Outline: favorite a file inside of a received share - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has shared folder "/PARENT" with user "Brian" - When user "Brian" favorites element "/PARENT/parent.txt" using the WebDAV API - Then as user "Brian" file "/PARENT/parent.txt" should be favorited - Examples: - | dav_version | - | old | - | new | - - @files_sharing-app-required @notToImplementOnOCIS - Scenario Outline: favorite a folder inside of a received share - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created folder "/PARENT/sub-folder" - And user "Alice" has shared folder "/PARENT" with user "Brian" - When user "Brian" favorites element "/PARENT/sub-folder" using the WebDAV API - Then as user "Brian" folder "/PARENT/sub-folder" should be favorited - Examples: - | dav_version | - | old | - | new | - - @files_sharing-app-required @notToImplementOnOCIS - Scenario Outline: favorite a received share itself - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has shared folder "/PARENT" with user "Brian" - When user "Brian" favorites element "/PARENT" using the WebDAV API - Then as user "Brian" folder "/PARENT" should be favorited - Examples: - | dav_version | - | old | - | new | diff --git a/tests/acceptance/features/coreApiMain/checksums.feature b/tests/acceptance/features/coreApiMain/checksums.feature index 89fca532536..54df5217b37 100644 --- a/tests/acceptance/features/coreApiMain/checksums.feature +++ b/tests/acceptance/features/coreApiMain/checksums.feature @@ -122,22 +122,6 @@ Feature: checksums | dav_version | | spaces | - @local_storage @files_external-app-required @notToImplementOnOCIS - Scenario Outline: Downloading a file from local storage has correct checksum - Given using DAV path - # Create the file directly in local storage, bypassing ownCloud - And file "prueba_cksum.txt" with text "Test file for checksums" has been created in local storage on the server - # Do a first download, which will trigger ownCloud to calculate a checksum for the file - When user "Alice" downloads file "/local_storage/prueba_cksum.txt" using the WebDAV API - # Now do a download that is expected to have a checksum with it - And user "Alice" downloads file "/local_storage/prueba_cksum.txt" using the WebDAV API - Then the HTTP status code should be "200" - And the header checksum should match "SHA1:a35b7605c8f586d735435535c337adc066c2ccb6" - Examples: - | dav_version | - | old | - | new | - @issue-ocis-reva-14 Scenario Outline: Moving file with checksum should return the checksum in the download header Given using DAV path @@ -220,77 +204,6 @@ Feature: checksums | dav_version | checksum | | new | SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399 MD5:56e57920c3c8c727bfe7a5288cdf61c4 ADLER32:1048035a | - @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 - Scenario: Upload new DAV chunked file where checksum matches - Given using new DAV path - And user "Alice" has created a new chunking upload with id "chunking-42" - When user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" to "/myChunkedFile.txt" with checksum "SHA1:5d84d61b03fdacf813640f5242d309721e0629b1" using the WebDAV API - Then the HTTP status code of responses on all endpoints should be "201" - - @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 - Scenario: Upload new DAV chunked file where checksum does not match - Given using new DAV path - And user "Alice" has created a new chunking upload with id "chunking-42" - When user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" to "/myChunkedFile.txt" with checksum "SHA1:f005ba11" using the WebDAV API - Then the HTTP status code of responses on each endpoint should be "201, 201, 400" respectively - And user "Alice" should not see the following elements - | /myChunkedFile.txt | - - @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 - Scenario: Upload new DAV chunked file using async MOVE where checksum matches - Given using new DAV path - And the administrator has enabled async operations - And user "Alice" has created a new chunking upload with id "chunking-42" - When user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" with checksum "SHA1:5d84d61b03fdacf813640f5242d309721e0629b1" using the WebDAV API - Then the HTTP status code of responses on each endpoint should be "201, 201, 202" respectively - And the following headers should match these regular expressions for user "Alice" - | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | - And the oc job status values of last request for user "Alice" should match these regular expressions - | status | /^finished$/ | - | fileId | /^[0-9a-z]{20,}$/ | - And the content of file "/myChunkedFile.txt" for user "Alice" should be "BBBBBCCCCC" - - @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 - Scenario: Upload new DAV chunked file using async MOVE where checksum does not match - Given using new DAV path - And the administrator has enabled async operations - And user "Alice" has created a new chunking upload with id "chunking-42" - When user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" with checksum "SHA1:f005ba11" using the WebDAV API - Then the HTTP status code of responses on each endpoint should be "201, 201, 202" respectively - And the following headers should match these regular expressions for user "Alice" - | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | - And the oc job status values of last request for user "Alice" should match these regular expressions - | status | /^error$/ | - | errorCode | /^400$/ | - | errorMessage | /^The computed checksum does not match the one received from the client.$/ | - And user "Alice" should not see the following elements - | /myChunkedFile.txt | - - @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 - Scenario: Upload new DAV chunked file using async MOVE where checksum does not match - retry with correct checksum - Given using new DAV path - And the administrator has enabled async operations - And user "Alice" has created a new chunking upload with id "chunking-42" - When user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" with checksum "SHA1:f005ba11" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" with checksum "SHA1:5d84d61b03fdacf813640f5242d309721e0629b1" using the WebDAV API - Then the HTTP status code of responses on each endpoint should be "201, 201, 202, 202" respectively - And the following headers should match these regular expressions for user "Alice" - | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | - And the oc job status values of last request for user "Alice" should match these regular expressions - | status | /^finished$/ | - | fileId | /^[0-9a-z]{20,}$/ | - And the content of file "/myChunkedFile.txt" for user "Alice" should be "BBBBBCCCCC" - @issue-ocis-reva-99 Scenario Outline: Upload a file where checksum does not match Given using DAV path @@ -342,20 +255,6 @@ Feature: checksums | dav_version | | spaces | - @local_storage @files_external-app-required @notToImplementOnOCIS @skipOnEncryptionType:user-keys @encryption-issue-42 - Scenario Outline: Uploaded file to external storage should have the same checksum when downloaded - Given using DAV path - And user "Alice" has uploaded file with checksum "SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399" and content "Some Text" to "/local_storage/chksumtst.txt" - When user "Alice" downloads file "/local_storage/chksumtst.txt" using the WebDAV API - Then the HTTP status code should be "200" - And the following headers should be set - | header | value | - | OC-Checksum | SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399 | - Examples: - | dav_version | - | old | - | new | - ## Validation Plugin or Old Endpoint Specific @issue-ocis-reva-17 Scenario Outline: Uploading an old method chunked file with checksum should fail using new DAV path @@ -438,28 +337,6 @@ Feature: checksums | dav_version | | spaces | - @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 - Scenario: Upload overwriting a file with new chunking and correct checksum - Given using new DAV path - And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" - And user "Alice" has created a new chunking upload with id "chunking-42" - When user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" to "/textfile0.txt" with checksum "SHA1:5d84d61b03fdacf813640f5242d309721e0629b1" using the WebDAV API - Then the HTTP status code of responses on each endpoint should be "201, 201, 204" respectively - And the content of file "/textfile0.txt" for user "Alice" should be "BBBBBCCCCC" - - @skipOnStorage:ceph @skipOnStorage:scality @files_primary_s3-issue-224 @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 - Scenario: Upload overwriting a file with new chunking and invalid checksum - Given using new DAV path - And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" - And user "Alice" has created a new chunking upload with id "chunking-42" - When user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" to "/textfile0.txt" with checksum "SHA1:f005ba11" using the WebDAV API - Then the HTTP status code of responses on each endpoint should be "201, 201, 400" respectively - And the content of file "/textfile0.txt" for user "Alice" should be "ownCloud test text file 0" - @issue-ocis-reva-214 Scenario Outline: Uploading a file with checksum should work for file with special characters Given using DAV path diff --git a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareGroupCaseSensitive.feature b/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareGroupCaseSensitive.feature deleted file mode 100644 index 08ddb5a53ad..00000000000 --- a/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareGroupCaseSensitive.feature +++ /dev/null @@ -1,90 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: share with groups, group names are case-sensitive - - Background: - Given the administrator has set the default folder for received shares to "Shares" - And auto-accept shares has been disabled - And user "Alice" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file with content "ownCloud test text file 1" to "/textfile1.txt" - And user "Alice" has uploaded file with content "ownCloud test text file 2" to "/textfile2.txt" - And user "Alice" has uploaded file with content "ownCloud test text file 3" to "/textfile3.txt" - - @skipOnLDAP @issue-ldap-250 - Scenario Outline: group names are case-sensitive, sharing with groups with different upper and lower case names - Given using OCS API version "" - And group "" has been created - And group "" has been created - And group "" has been created - And these users have been created with default attributes and without skeleton files: - | username | - | Brian | - | Carol | - | David | - And user "Brian" has been added to group "" - And user "Carol" has been added to group "" - And user "David" has been added to group "" - When user "Alice" shares file "textfile1.txt" with group "" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - When user "Brian" accepts share "/textfile1.txt" offered by user "Alice" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the content of file "/Shares/textfile1.txt" for user "Brian" should be "ownCloud test text file 1" - When user "Alice" shares file "textfile2.txt" with group "" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - When user "Carol" accepts share "/textfile2.txt" offered by user "Alice" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the content of file "/Shares/textfile2.txt" for user "Carol" should be "ownCloud test text file 2" - When user "Alice" shares file "textfile3.txt" with group "" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - When user "David" accepts share "/textfile3.txt" offered by user "Alice" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the content of file "/Shares/textfile3.txt" for user "David" should be "ownCloud test text file 3" - Examples: - | ocs_api_version | group_id1 | group_id2 | group_id3 | ocs_status_code | - | 1 | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | 100 | - | 1 | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | 100 | - | 1 | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | 100 | - | 2 | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | 200 | - | 2 | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | 200 | - | 2 | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | 200 | - - @skipOnLDAP @issue-ldap-250 - Scenario Outline: group names are case-sensitive, sharing with nonexistent groups with different upper and lower case names - Given using OCS API version "" - And these users have been created with default attributes and without skeleton files: - | username | - | Brian | - And group "" has been created - And user "Brian" has been added to group "" - When user "Alice" shares file "textfile1.txt" with group "" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - When user "Brian" accepts share "/textfile1.txt" offered by user "Alice" 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 - | share_with | | - | file_target | /Shares/textfile1.txt | - | path | /Shares/textfile1.txt | - | permissions | share,read,update | - | uid_owner | %username% | - And the content of file "/Shares/textfile1.txt" for user "Brian" should be "ownCloud test text file 1" - When user "Alice" shares file "textfile2.txt" with group "" using the sharing API - Then the OCS status code should be "404" - And the HTTP status code should be "" - When user "Alice" shares file "textfile3.txt" with group "" using the sharing API - Then the OCS status code should be "404" - And the HTTP status code should be "" - Examples: - | ocs_api_version | group_id1 | group_id2 | group_id3 | ocs_status_code | http_status_code | - | 1 | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | 100 | 200 | - | 1 | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | 100 | 200 | - | 1 | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | 100 | 200 | - | 2 | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | 200 | 404 | - | 2 | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | 200 | 404 | - | 2 | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | 200 | 404 | diff --git a/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareFromLocalStorageToSharesFolder.feature b/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareFromLocalStorageToSharesFolder.feature deleted file mode 100644 index d649a328ce3..00000000000 --- a/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareFromLocalStorageToSharesFolder.feature +++ /dev/null @@ -1,114 +0,0 @@ -@api @local_storage @files_external-app-required @notToImplementOnOCIS @files_sharing-app-required -Feature: local-storage - - 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 | - - @skipOnEncryptionType:user-keys @encryption-issue-181 - Scenario Outline: Share a file inside a local external storage - Given using OCS API version "" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/local_storage/filetoshare.txt" - When user "Alice" shares file "/local_storage/filetoshare.txt" 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% | - | share_with_displayname | %displayname% | - | file_target | /Shares/filetoshare.txt | - | path | /local_storage/filetoshare.txt | - | permissions | share,read,update | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | item_type | file | - | mimetype | text/plain | - | storage_id | ANY_VALUE | - | share_type | user | - When user "Brian" accepts share "" offered by user "Alice" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And as "Brian" file "/Shares/filetoshare.txt" should exist - Examples: - | ocs_api_version | ocs_status_code | pending_share_path | - | 1 | 100 | /filetoshare.txt | - | 2 | 200 | /filetoshare.txt | - - - Scenario Outline: Share a folder inside a local external storage - Given using OCS API version "" - And user "Alice" has created folder "/local_storage/foo" - When user "Alice" shares folder "/local_storage/foo" 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% | - | share_with_displayname | %displayname% | - | file_target | /Shares/foo | - | path | /local_storage/foo | - | permissions | all | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | item_type | folder | - | mimetype | httpd/unix-directory | - | storage_id | ANY_VALUE | - | share_type | user | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - @skipOnEncryptionType:user-keys @encryption-issue-181 - Scenario Outline: Share a file inside a local external storage to a group - Given using OCS API version "" - And group "grp1" has been created - And user "Alice" has been added to group "grp1" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/local_storage/filetoshare.txt" - When user "Alice" shares file "/local_storage/filetoshare.txt" with group "grp1" 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 group "grp1" should include - | share_with | grp1 | - | share_with_displayname | grp1 | - | file_target | /Shares/filetoshare.txt | - | path | /local_storage/filetoshare.txt | - | permissions | share,read,update | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | item_type | file | - | mimetype | text/plain | - | storage_id | ANY_VALUE | - | share_type | group | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - - - Scenario Outline: Share a folder inside a local external storage to a group - Given using OCS API version "" - And group "grp1" has been created - And user "Alice" has been added to group "grp1" - And user "Alice" has created folder "/local_storage/foo" - When user "Alice" shares folder "/local_storage/foo" with group "grp1" 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 group "grp1" should include - | share_with | grp1 | - | share_with_displayname | grp1 | - | file_target | /Shares/foo | - | path | /local_storage/foo | - | permissions | all | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | item_type | folder | - | mimetype | httpd/unix-directory | - | storage_id | ANY_VALUE | - | share_type | group | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | diff --git a/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature b/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature index 5c48f73ce70..2f08edf2b37 100644 --- a/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature +++ b/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature @@ -127,55 +127,7 @@ Feature: accept/decline shares coming from internal users | /Shares/PARENT | | /Shares/textfile0.txt | - @notToImplementOnOCIS - Scenario Outline: accept a pending share when there is a default folder for received shares - Given the administrator has set the default folder for received shares to "" - And user "Alice" has shared folder "/PARENT" with user "Brian" - And user "Alice" has shared file "/textfile0.txt" with user "Brian" - When user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API - And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API - Then the OCS status code of responses on all endpoints should be "100" - And the HTTP status code of responses on all endpoints should be "200" - And the fields of the last response to user "Alice" sharing with user "Brian" should include - | id | A_STRING | - | share_type | user | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | permissions | share,read,update | - | uid_file_owner | %username% | - | displayname_file_owner | %displayname% | - | state | 0 | - | path | / | - | item_type | file | - | mimetype | text/plain | - | storage_id | shared::/ | - | storage | A_STRING | - | item_source | A_STRING | - | file_source | A_STRING | - | file_target | / | - | share_with | %username% | - | share_with_displayname | %displayname% | - | mail_send | 0 | - And user "Brian" should see the following elements - | /FOLDER/ | - | /PARENT/ | - | // | - | //parent.txt | - | /textfile0.txt | - | / | - And the sharing API should report to user "Brian" that these shares are in the accepted state - | path | - | // | - | / | - Examples: - | share_folder | top_folder | received_parent_name | received_textfile_name | - | | | PARENT (2) | textfile0 (2).txt | - | / | | PARENT (2) | textfile0 (2).txt | - | /ReceivedShares | /ReceivedShares | PARENT | textfile0.txt | - | ReceivedShares | /ReceivedShares | PARENT | textfile0.txt | - | /My/Received/Shares | /My/Received/Shares | PARENT | textfile0.txt | - - + Scenario: accept an accepted share Given user "Alice" has created folder "/shared" And user "Alice" has shared folder "/shared" with user "Brian" @@ -328,7 +280,7 @@ Feature: accept/decline shares coming from internal users | /Shares/testfile (2) (2).txt | And the content of file "/Shares/testfile.txt" for user "Carol" should be "Third file" And the content of file "/Shares/testfile (2).txt" for user "Carol" should be "Second file" - And the content of file "/Shares/testfile (2) (2).txt" for user "Carol" should be "First file" + And the content of file "/Shares/testfile (2) (2).txt" for user "Carol" should be "First file" Examples: | accepted_share_path | | /testfile (2).txt | @@ -363,7 +315,7 @@ Feature: accept/decline shares coming from internal users | accepted_share_path_1 | accepted_share_path_2 | | /PARENT (2) | /PARENT (2) (2) | - + Scenario: user shares folder with matching folder-name for both user involved in sharing Given user "Alice" has uploaded file with content "uploaded content" to "/PARENT/abc.txt" And user "Alice" has uploaded file with content "uploaded content" to "/FOLDER/abc.txt" @@ -386,7 +338,7 @@ Feature: accept/decline shares coming from internal users And the content of file "/Shares/PARENT/abc.txt" for user "Brian" should be "uploaded content" And the content of file "/Shares/FOLDER/abc.txt" for user "Brian" should be "uploaded content" - + Scenario: user shares folder in a group with matching folder-name for every users involved Given user "Alice" has uploaded file with content "uploaded content" to "/PARENT/abc.txt" And user "Alice" has uploaded file with content "uploaded content" to "/FOLDER/abc.txt" @@ -425,7 +377,7 @@ Feature: accept/decline shares coming from internal users And the content of file "/Shares/PARENT/abc.txt" for user "Carol" should be "uploaded content" And the content of file "/Shares/FOLDER/abc.txt" for user "Carol" should be "uploaded content" - + Scenario: user shares files in a group with matching file-names for every users involved in sharing Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt" And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt" @@ -450,7 +402,7 @@ Feature: accept/decline shares coming from internal users | /Shares/textfile0.txt | | /Shares/textfile1.txt | - + Scenario: user shares resource with matching resource-name with another user when auto accept is disabled When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API And user "Alice" shares file "/textfile0.txt" with user "Brian" using the sharing API @@ -472,7 +424,7 @@ Feature: accept/decline shares coming from internal users | /Shares/PARENT/ | | /Shares/textfile0.txt | - + Scenario: user shares file in a group with matching filename when auto accept is disabled Given user "Carol" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" When user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API diff --git a/tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShare.feature b/tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShare.feature index 6f31015a0ba..6ed246b06b6 100644 --- a/tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShare.feature +++ b/tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShare.feature @@ -11,23 +11,6 @@ Feature: sharing | Brian | | Carol | - @issue-ocis-2141 @notToImplementOnOCIS - Scenario: Keep usergroup shares (#22143) - Given group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Carol" has been added to group "grp1" - And user "Alice" has created folder "/TMP" - When user "Alice" shares folder "TMP" with group "grp1" using the sharing API - And user "Brian" accepts share "/TMP" offered by user "Alice" using the sharing API - And user "Carol" accepts share "/TMP" offered by user "Alice" using the sharing API - And user "Brian" creates folder "/myFOLDER" using the WebDAV API - And user "Brian" moves folder "/Shares/TMP" to "/myFOLDER/myTMP" using the WebDAV API - And the administrator deletes user "Carol" using the provisioning API - Then the OCS status code of responses on all endpoints should be "100" - And the HTTP status code of responses on all endpoints should be "200" - And user "Brian" should see the following elements - | /myFOLDER/myTMP/ | - Scenario: Keep usergroup shares when the user renames the share within the Shares folder(#22143) Given group "grp1" has been created @@ -44,19 +27,6 @@ Feature: sharing And user "Brian" should see the following elements | /Shares/new/| - @issue-ocis-2141 @notToImplementOnOCIS - Scenario: keep user shared file name same after one of recipient has renamed the file - Given user "Alice" has uploaded file with content "foo" to "/sharefile.txt" - And user "Alice" has shared file "/sharefile.txt" with user "Brian" - And user "Alice" has shared file "/sharefile.txt" with user "Carol" - And user "Brian" has accepted share "/sharefile.txt" offered by user "Alice" - And user "Carol" has accepted share "/sharefile.txt" offered by user "Alice" - When user "Carol" moves file "/Shares/sharefile.txt" to "/renamedsharefile.txt" using the WebDAV API - Then the HTTP status code should be "201" - And as "Carol" file "/renamedsharefile.txt" should exist - And as "Alice" file "/sharefile.txt" should exist - And as "Brian" file "/Shares/sharefile.txt" should exist - Scenario: keep user shared file name same after one of recipient has renamed the file inside the Shares folder Given user "Alice" has uploaded file with content "foo" to "/sharefile.txt" @@ -70,61 +40,6 @@ Feature: sharing And as "Alice" file "/sharefile.txt" should exist And as "Brian" file "/Shares/sharefile.txt" should exist - @issue-ocis-2141 @notToImplementOnOCIS - Scenario: keep user shared file directory same in respect to respective user if one of the recipient has moved the file - Given user "Alice" has uploaded file with content "foo" to "/sharefile.txt" - And user "Alice" has shared file "/sharefile.txt" with user "Brian" - And user "Alice" has shared file "/sharefile.txt" with user "Carol" - And user "Brian" has accepted share "/sharefile.txt" offered by user "Alice" - And user "Carol" has accepted share "/sharefile.txt" offered by user "Alice" - And user "Carol" has created folder "newfolder" - When user "Carol" moves file "/Shares/sharefile.txt" to "/newfolder/sharefile.txt" using the WebDAV API - Then the HTTP status code should be "201" - And as "Carol" file "/newfolder/sharefile.txt" should exist - And as "Alice" file "/sharefile.txt" should exist - And as "Brian" file "/Shares/sharefile.txt" should exist - - @issue-ocis-2146 @notToImplementOnOCIS - Scenario Outline: move folder inside received folder with special characters - Given group "grp1" has been created - And user "Carol" has been added to group "grp1" - And user "Alice" has created folder "" - And user "Alice" has created folder "" - And user "Brian" has created folder "" - And user "Carol" has created folder "" - And user "Alice" has shared folder "" with user "Brian" - And user "Brian" has accepted share "/" offered by user "Alice" - When user "Brian" moves folder "" to "/Shares//" using the WebDAV API - And user "Alice" shares folder "" with group "grp1" using the sharing API - And user "Carol" accepts share "/" offered by user "Alice" using the sharing API - And user "Carol" moves folder "/" to "/Shares//" using the WebDAV API - Then the OCS status code of responses on all endpoints should be "100" - And the HTTP status code of responses on each endpoint should be "201, 200, 200, 201" respectively - And as "Alice" folder "/" should exist - And as "Brian" folder "/Shares//" should exist - And as "Alice" folder "/" should exist - And as "Carol" folder "/Shares//" should exist - Examples: - | sharer_folder | group_folder | receiver_folder | - | ?abc=oc # | ?abc=oc g%rp# | # oc?test=oc&a | - | @a#8a=b?c=d | @a#8a=b?c=d grp | ?a#8 a=b?c=d | - - @issue-ocis-2141 @notToImplementOnOCIS - Scenario: receiver renames a received share with share, read, change permissions - Given user "Alice" has created folder "folderToShare" - And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "/folderToShare/fileInside" - And user "Alice" has shared folder "folderToShare" with user "Brian" with permissions "share,read,change" - And user "Brian" has accepted share "/folderToShare" offered by user "Alice" - When user "Brian" moves folder "/Shares/folderToShare" to "myFolder" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" folder "myFolder" should exist - But as "Alice" folder "myFolder" should not exist - When user "Brian" moves file "/myFolder/fileInside" to "/myFolder/renamedFile" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" file "/myFolder/renamedFile" should exist - And as "Alice" file "/folderToShare/renamedFile" should exist - But as "Alice" file "/folderToShare/fileInside" should not exist - Scenario: receiver renames a received share with share, read, change permissions inside the Shares folder Given user "Alice" has created folder "folderToShare" @@ -141,21 +56,6 @@ Feature: sharing And as "Alice" file "/folderToShare/renamedFile" should exist But as "Alice" file "/folderToShare/fileInside" should not exist - @issue-ocis-2141 @notToImplementOnOCIS - Scenario: receiver tries to rename a received share with share, read permissions - Given user "Alice" has created folder "folderToShare" - And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "/folderToShare/fileInside" - And user "Alice" has shared folder "folderToShare" with user "Brian" with permissions "share,read" - And user "Brian" has accepted share "/folderToShare" offered by user "Alice" - When user "Brian" moves folder "/Shares/folderToShare" to "/myFolder" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" folder "myFolder" should exist - But as "Alice" folder "myFolder" should not exist - When user "Brian" moves file "/myFolder/fileInside" to "/myFolder/renamedFile" using the WebDAV API - Then the HTTP status code should be "403" - And as "Brian" file "/myFolder/renamedFile" should not exist - But as "Brian" file "/myFolder/fileInside" should exist - Scenario: receiver tries to rename a received share with share, read permissions inside the Shares folder Given user "Alice" has created folder "folderToShare" @@ -215,18 +115,6 @@ Feature: sharing And as "Brian" folder "/Shares/myFolder" should exist But as "Alice" folder "myFolder" should not exist - @issue-ocis-2141 @notToImplementOnOCIS - Scenario: receiver renames a received file share with read,update,share permissions in group sharing - Given group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" - And user "Alice" has shared file "fileToShare.txt" with group "grp1" with permissions "read,update,share" - And user "Brian" has accepted share "/fileToShare.txt" offered by user "Alice" - When user "Brian" moves folder "/Shares/fileToShare.txt" to "newFile.txt" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" file "newFile.txt" should exist - But as "Alice" file "newFile.txt" should not exist - Scenario: receiver renames a received file share with read,update,share permissions inside the Shares folder in group sharing Given group "grp1" has been created @@ -239,18 +127,6 @@ Feature: sharing And as "Brian" file "/Shares/newFile.txt" should exist But as "Alice" file "/Shares/newFile.txt" should not exist - @issue-ocis-2141 @notToImplementOnOCIS - Scenario: receiver renames a received folder share with share, read, change permissions in group sharing - Given group "grp1" has been created - And user "Alice" has created folder "PARENT" - And user "Brian" has been added to group "grp1" - And user "Alice" has shared folder "PARENT" with group "grp1" with permissions "share,read,change" - And user "Brian" has accepted share "/PARENT" offered by user "Alice" - When user "Brian" moves folder "/Shares/PARENT" to "myFolder" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" folder "myFolder" should exist - But as "Alice" folder "myFolder" should not exist - Scenario: receiver renames a received folder share with share, read, change permissions inside the Shares folder in group sharing Given group "grp1" has been created @@ -263,18 +139,6 @@ Feature: sharing And as "Brian" folder "/Shares/myFolder" should exist But as "Alice" folder "/Shares/myFolder" should not exist - @issue-ocis-2141 @notToImplementOnOCIS - Scenario: receiver renames a received file share with share, read permissions in group sharing - Given group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt" - And user "Alice" has shared file "fileToShare.txt" with group "grp1" with permissions "share,read" - And user "Brian" has accepted share "/fileToShare.txt" offered by user "Alice" - When user "Brian" moves file "/Shares/fileToShare.txt" to "/newFile.txt" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" file "newFile.txt" should exist - But as "Alice" file "newFile.txt" should not exist - Scenario: receiver renames a received file share with share, read permissions inside the Shares folder in group sharing) Given group "grp1" has been created @@ -287,18 +151,6 @@ Feature: sharing And as "Brian" file "/Shares/newFile.txt" should exist But as "Alice" file "/Shares/newFile.txt" should not exist - @issue-ocis-2141 @notToImplementOnOCIS - Scenario: receiver renames a received folder share with share, read permissions in group sharing - Given group "grp1" has been created - And user "Alice" has created folder "PARENT" - And user "Brian" has been added to group "grp1" - And user "Alice" has shared folder "PARENT" with group "grp1" with permissions "share,read" - And user "Brian" has accepted share "/PARENT" offered by user "Alice" - When user "Brian" moves folder "/Shares/PARENT" to "/myFolder" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" folder "myFolder" should exist - But as "Alice" folder "myFolder" should not exist - Scenario: receiver renames a received folder share with share, read permissions inside the Shares folder in group sharing Given group "grp1" has been created @@ -358,19 +210,3 @@ Feature: sharing | sharer_folder | group_folder | receiver_file | | ?abc=oc # | ?abc=oc g%rp# | # oc?test=oc&a | | @a#8a=b?c=d | @a#8a=b?c=d grp | ?a#8 a=b?c=d | - - @issue-ocis-2141 @notToImplementOnOCIS - Scenario: receiver moves file within a received folder to new folder - Given user "Alice" has created folder "folderToShare" - And user "Brian" has created folder "FOLDER" - And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "/folderToShare/fileToShare1.txt" - And user "Alice" has uploaded file with content "thisIsAnotherFileInsideTheSharedFolder" to "/folderToShare/fileToShare2.txt" - And user "Alice" has shared folder "folderToShare" with user "Brian" with permissions "share,read,change" - And user "Brian" has accepted share "/folderToShare" offered by user "Alice" - When user "Brian" moves file "/Shares/folderToShare/fileToShare1.txt" to "/FOLDER/fileToShare1.txt" using the WebDAV API - And user "Brian" moves file "/Shares/folderToShare/fileToShare2.txt" to "/FOLDER/fileToShare2.txt" using the WebDAV API - Then the HTTP status code of responses on all endpoints should be "201" - And as "Brian" file "/FOLDER/fileToShare1.txt" should exist - And as "Brian" file "/FOLDER/fileToShare2.txt" should exist - But as "Alice" file "/folderToShare/fileToShare1.txt" should not exist - And as "Alice" file "/folderToShare/fileToShare2.txt" should not exist diff --git a/tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShareFromLocalStorage.feature b/tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShareFromLocalStorage.feature deleted file mode 100644 index 59207f03c29..00000000000 --- a/tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShareFromLocalStorage.feature +++ /dev/null @@ -1,90 +0,0 @@ -@api @local_storage @files_external-app-required @notToImplementOnOCIS -Feature: local-storage - - 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 | - - @skipOnEncryptionType:user-keys @encryption-issue-181 - Scenario Outline: receiver renames a received file share from local storage - Given using OCS API version "" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/local_storage/filetoshare.txt" - And user "Alice" has shared file "/local_storage/filetoshare.txt" with user "Brian" - And user "Brian" has accepted share "" offered by user "Alice" - When user "Brian" moves file "/Shares/filetoshare.txt" to "/Shares/newFile.txt" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" file "/Shares/newFile.txt" should exist - But as "Brian" file "/Shares/filetoshare.txt" should not exist - And as "Alice" file "/local_storage/filetoshare.txt" should exist - But as "Alice" file "/local_storage/newFile.txt" should not exist - Examples: - | ocs_api_version | pending_share_path | - | 1 | /filetoshare.txt | - | 2 | /filetoshare.txt | - - - Scenario Outline: receiver renames a received folder share from local storage - Given using OCS API version "" - And user "Alice" has created folder "/local_storage/foo" - And user "Alice" has shared folder "/local_storage/foo" with user "Brian" - And user "Brian" has accepted share "" offered by user "Alice" - When user "Brian" moves folder "/Shares/foo" to "/Shares/newFolder" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" folder "/Shares/newFolder" should exist - But as "Brian" folder "/Shares/foo" should not exist - And as "Alice" folder "/local_storage/foo" should exist - But as "Alice" folder "/local_storage/newFolder" should not exist - Examples: - | ocs_api_version | pending_share_path | - | 1 | /foo | - | 2 | /foo | - - @skipOnEncryptionType:user-keys @encryption-issue-181 - Scenario Outline: sub-folders,file inside a renamed received folder shared from local storage are accessible - Given using OCS API version "" - And user "Alice" has created folder "/local_storage/foo" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/local_storage/foo/filetoshare.txt" - And user "Alice" has created folder "/local_storage/foo/folder1" - And user "Alice" has created folder "/local_storage/foo/folder2" - And user "Alice" has created folder "/local_storage/foo/folder2/subfolder" - And user "Alice" has shared folder "/local_storage/foo" with user "Brian" - And user "Brian" has accepted share "" offered by user "Alice" - When user "Brian" moves folder "/Shares/foo" to "/Shares/newFolder" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" folder "/Shares/newFolder" should exist - And as "Brian" file "/Shares/newFolder/filetoshare.txt" should exist - And as "Brian" folder "/Shares/newFolder/folder1" should exist - And as "Brian" folder "/Shares/newFolder/folder2" should exist - And as "Brian" folder "/Shares/newFolder/folder2/subfolder" should exist - But as "Brian" folder "/Shares/foo" should not exist - And as "Alice" folder "/local_storage/foo" should exist - But as "Alice" folder "/local_storage/newFolder" should not exist - Examples: - | ocs_api_version | pending_share_path | - | 1 | /foo | - | 2 | /foo | - - @skipOnEncryptionType:user-keys @encryption-issue-181 - Scenario Outline: receiver renames a received file share from local storage in group sharing - Given using OCS API version "" - And group "grp1" has been created - And user "Alice" has been added to group "grp1" - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/local_storage/filetoshare.txt" - And user "Alice" has shared file "/local_storage/filetoshare.txt" with group "grp1" - And user "Brian" has accepted share "" offered by user "Alice" - When user "Brian" moves file "/Shares/filetoshare.txt" to "/Shares/newFile.txt" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" file "/Shares/newFile.txt" should exist - But as "Brian" file "/Shares/filetoshare.txt" should not exist - And as "Alice" file "/local_storage/filetoshare.txt" should exist - But as "Alice" file "/local_storage/newFile.txt" should not exist - Examples: - | ocs_api_version | pending_share_path | - | 1 | /filetoshare.txt | - | 2 | /filetoshare.txt | - \ No newline at end of file diff --git a/tests/acceptance/features/coreApiShareManagementToShares/moveShareInsideAnotherShare.feature b/tests/acceptance/features/coreApiShareManagementToShares/moveShareInsideAnotherShare.feature index 1a9528e3b63..1156c7f2aab 100644 --- a/tests/acceptance/features/coreApiShareManagementToShares/moveShareInsideAnotherShare.feature +++ b/tests/acceptance/features/coreApiShareManagementToShares/moveShareInsideAnotherShare.feature @@ -41,47 +41,6 @@ Feature: moving a share inside another share And as "Brian" file "/Shares/folderA/folderB/fileB.txt" should exist And as "Brian" file "/Shares/folderB/fileB.txt" should exist - @notToImplementOnOCIS - Scenario: share receiver moves a whole share inside a local folder - Given user "Brian" has created folder "localFolder" - And user "Brian" has uploaded file with content "local text" to "/localFolder/localFile.txt" - When user "Brian" moves folder "Shares/folderB" to "localFolder/folderB" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" folder "/localFolder/folderB" should exist - And as "Brian" file "/localFolder/folderB/fileB.txt" should exist - And as "Brian" file "/localFolder/localFile.txt" should exist - But as "Brian" file "/Shares/folderB/fileB.txt" should not exist - - @notToImplementOnOCIS - Scenario: share receiver moves a whole share inside a local folder then moves the local folder inside a received share - Given user "Brian" has created folder "localFolder" - And user "Brian" has uploaded file with content "local text" to "/localFolder/localFile.txt" - When user "Brian" moves folder "Shares/folderB" to "localFolder/folderB" using the WebDAV API - And user "Brian" moves folder "localFolder" to "Shares/folderA/localFolder" using the WebDAV API - Then the HTTP status code of responses on all endpoints should be "201" - And as "Alice" folder "/folderA/localFolder" should exist - And as "Brian" folder "/Shares/folderA/localFolder" should exist - And as "Alice" file "/folderA/localFolder/localFile.txt" should exist - And as "Brian" file "/Shares/folderA/localFolder/localFile.txt" should exist - # folderB now exists separately, and is no longer inside localFolder - And as "Alice" file "/folderB/fileB.txt" should exist - And as "Brian" file "/Shares/folderB/fileB.txt" should exist - But as "Alice" folder "/folderA/localFolder/folderB" should not exist - And as "Brian" folder "/Shares/folderA/localFolder/folderB" should not exist - - @notToImplementOnOCIS - Scenario: share receiver moves a whole share inside a local folder then tries to move the share inside a received share - Given user "Brian" has created folder "localFolder" - And user "Brian" has uploaded file with content "local text" to "/localFolder/localFile.txt" - When user "Brian" moves folder "Shares/folderB" to "localFolder/folderB" using the WebDAV API - And user "Brian" moves folder "localFolder/folderB" to "Shares/folderA/folderB" using the WebDAV API - Then the HTTP status code of responses on each endpoint should be "201, 403" respectively - And as "Alice" file "/folderB/fileB.txt" should exist - And as "Brian" folder "/localFolder/folderB" should exist - And as "Brian" file "/localFolder/folderB/fileB.txt" should exist - But as "Alice" folder "/folderA/folderB" should not exist - And as "Brian" folder "/Shares/folderA/folderB" should not exist - Scenario: share receiver moves a local folder inside a received share (local folder does not have a share in it) Given user "Brian" has created folder "localFolder" diff --git a/tests/acceptance/features/coreApiShareOperationsToShares1/accessToSharesFolder.feature b/tests/acceptance/features/coreApiShareOperationsToShares1/accessToSharesFolder.feature deleted file mode 100644 index a6f4da75122..00000000000 --- a/tests/acceptance/features/coreApiShareOperationsToShares1/accessToSharesFolder.feature +++ /dev/null @@ -1,119 +0,0 @@ -@api @files_sharing-app-required @notToImplementOnOCIS -Feature: write directly into the folder for received shares - On ownCloud10 with the folder for received shares set, for example, to "Shares" - A user should see a "Shares" folder when they have received a share. - A user should be able to add their own resources into the "Shares" folder - and those resources will act like any resource that is local to the user. - Even if the user has no more received shares, the "Shares" folder is still there. - - 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: the Shares folder does not exist before the first share is received - Then as "Alice" folder "/Shares" should not exist - And as "Brian" folder "/Shares" should not exist - - - Scenario: the Shares folder does not exist if no share has been accepted - Given user "Alice" has created folder "/shared" - When user "Alice" shares folder "/shared" with user "Brian" using the sharing API - Then the OCS status code should be "100" - And the HTTP status code should be "200" - And as "Brian" folder "/Shares" should not exist - And as "Alice" folder "/Shares" should not exist - - - Scenario: the Shares folder exists for the sharee after a share is accepted - Given user "Alice" has created folder "/shared" - And user "Alice" has shared folder "/shared" with user "Brian" - When user "Brian" accepts share "/shared" offered by user "Alice" using the sharing API - Then the OCS status code should be "100" - And the HTTP status code should be "200" - And as "Brian" folder "/Shares" should exist - But as "Alice" folder "/Shares" should not exist - - - Scenario: the Shares folder exists after a share is received, accepted and deleted - Given user "Alice" has created folder "/shared" - And user "Alice" has shared folder "/shared" with user "Brian" - And user "Brian" has accepted share "/shared" offered by user "Alice" - When user "Alice" deletes the last share using the sharing API - Then the OCS status code should be "100" - And the HTTP status code should be "200" - And as "Brian" folder "/Shares" should exist - But as "Alice" folder "/Shares" should not exist - - - Scenario: the Shares folder can be created first by the user - Given user "Alice" has created folder "/shared" - When user "Brian" creates folder "/Shares" using the WebDAV API - And user "Brian" creates folder "/Shares/aFolder" using the WebDAV API - And user "Alice" shares folder "/shared" with user "Brian" using the sharing API - And user "Brian" accepts share "/shared" offered by user "Alice" using the sharing API - # OCS status code is available only for the Sharing API request - Then the OCS status code of responses on all endpoints should be "100" - And the HTTP status code of responses on each endpoint should be "201, 201, 200, 200" respectively - And as "Brian" folder "/Shares" should exist - And as "Brian" folder "/Shares/shared" should exist - - - Scenario: the user can have created a matching resource in Shares before receiving a share - Given user "Alice" has created folder "/shared" - And user "Alice" has uploaded file with content "shared data" to "/shared/aFile.txt" - And user "Brian" has created folder "/Shares" - And user "Brian" has created folder "/Shares/shared" - And user "Brian" has uploaded file with content "data of Brian" to "/Shares/shared/aFile.txt" - When user "Alice" shares folder "/shared" with user "Brian" using the sharing API - And user "Brian" accepts share "/shared" offered by user "Alice" using the sharing API - Then the OCS status code of responses on all endpoints should be "100" - And the HTTP status code of responses on all endpoints should be "200" - And as "Brian" folder "/Shares" should exist - And as "Brian" folder "/Shares/shared" should exist - And as "Brian" folder "/Shares/shared (2)" should exist - And the content of file "/Shares/shared/aFile.txt" for user "Brian" should be "data of Brian" - And the content of file "/Shares/shared (2)/aFile.txt" for user "Brian" should be "shared data" - - - Scenario: the user can write directly into the Shares folder - Given user "Alice" has created folder "/shared" - And user "Alice" has shared folder "/shared" with user "Brian" - And user "Brian" has accepted share "/shared" offered by user "Alice" - When user "Brian" uploads file with content "some data" to "/Shares/textfile.txt" using the WebDAV API - And user "Brian" creates folder "/Shares/aFolder" using the WebDAV API - And user "Brian" uploads file with content "more data" to "/Shares/aFolder/aFile.txt" using the WebDAV API - Then the HTTP status code of responses on all endpoints should be "201" - And as "Brian" file "/Shares/textfile.txt" should exist - And the content of file "/Shares/textfile.txt" for user "Brian" should be "some data" - And as "Brian" file "/Shares/aFolder/aFile.txt" should exist - And the content of file "Shares/aFolder/aFile.txt" for user "Brian" should be "more data" - - - Scenario: the user can move files directly into the Shares folder - Given user "Alice" has created folder "/shared" - And user "Alice" has shared folder "/shared" with user "Brian" - And user "Brian" has accepted share "/shared" offered by user "Alice" - And user "Brian" has uploaded file with content "some data" to "/textfile.txt" - When user "Brian" moves file "/textfile.txt" to "/Shares/textfile.txt" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" file "/Shares/textfile.txt" should exist - And the content of file "Shares/textfile.txt" for user "Brian" should be "some data" - - - Scenario: the user can delete files that they wrote into the Shares folder - Given user "Alice" has created folder "/shared" - And user "Alice" has shared folder "/shared" with user "Brian" - And user "Brian" has accepted share "/shared" offered by user "Alice" - And user "Brian" has uploaded file with content "some data" to "/Shares/textfile.txt" - And user "Brian" has created folder "/Shares/aFolder" - When user "Brian" deletes file "/Shares/textfile.txt" using the WebDAV API - And user "Brian" deletes folder "/Shares/aFolder" using the WebDAV API - Then the HTTP status code of responses on all endpoints should be "204" - And as "Brian" folder "/Shares" should exist - But as "Brian" file "/Shares/textfile.txt" should not exist - And as "Brian" folder "/Shares/aFolder" should not exist diff --git a/tests/acceptance/features/coreApiShareOperationsToShares1/changingFilesShare.feature b/tests/acceptance/features/coreApiShareOperationsToShares1/changingFilesShare.feature index 032f308d657..a0b6a5192e3 100644 --- a/tests/acceptance/features/coreApiShareOperationsToShares1/changingFilesShare.feature +++ b/tests/acceptance/features/coreApiShareOperationsToShares1/changingFilesShare.feature @@ -25,46 +25,6 @@ Feature: sharing | old | | new | - @smokeTest @files_trashbin-app-required @notToImplementOnOCIS - Scenario Outline: moving a file out of a share as recipient creates a backup for the owner - Given using DAV path - And user "Alice" has created folder "/shared" - And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" - And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" - And user "Alice" has shared file "/shared" with user "Brian" - And user "Brian" has accepted share "/shared" offered by user "Alice" - And user "Brian" has moved folder "/Shares/shared" to "/shared_renamed" - When user "Brian" moves file "/shared_renamed/shared_file.txt" to "/taken_out.txt" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" file "/taken_out.txt" should exist - And as "Alice" file "/shared/shared_file.txt" should not exist - And as "Alice" file "/shared_file.txt" should exist in the trashbin - Examples: - | dav_version | - | old | - | new | - - @files_trashbin-app-required @notToImplementOnOCIS - Scenario Outline: moving a folder out of a share as recipient creates a backup for the owner - Given using DAV path - And user "Alice" has created folder "/shared" - And user "Alice" has created folder "/shared/sub" - And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" - And user "Alice" has moved file "/textfile0.txt" to "/shared/sub/shared_file.txt" - And user "Alice" has shared file "/shared" with user "Brian" - And user "Brian" has accepted share "/shared" offered by user "Alice" - And user "Brian" has moved folder "/Shares/shared" to "/shared_renamed" - When user "Brian" moves folder "/shared_renamed/sub" to "/taken_out" using the WebDAV API - Then the HTTP status code should be "201" - And as "Brian" folder "/taken_out" should exist - And as "Alice" folder "/shared/sub" should not exist - And as "Alice" folder "/sub" should exist in the trashbin - And as "Alice" file "/sub/shared_file.txt" should exist in the trashbin - Examples: - | dav_version | - | old | - | new | - Scenario Outline: Move files between shares by same user Given using DAV path diff --git a/tests/acceptance/features/coreApiShareOperationsToShares2/uploadToShare.feature b/tests/acceptance/features/coreApiShareOperationsToShares2/uploadToShare.feature index 4e48ddc3d5a..6772f51873c 100644 --- a/tests/acceptance/features/coreApiShareOperationsToShares2/uploadToShare.feature +++ b/tests/acceptance/features/coreApiShareOperationsToShares2/uploadToShare.feature @@ -188,7 +188,7 @@ Feature: sharing | old | | new | - + Scenario Outline: Uploading to a group shared folder with read/write permission when the sharer has unsufficient quota does not work Given using DAV path And user "Brian" has been created with default attributes and without skeleton files @@ -252,24 +252,6 @@ Feature: sharing | old | | new | - @notToImplementOnOCIS @newChunking @issue-ocis-1321 - Scenario: Uploading a file in to a shared folder without edit permissions - Given using new DAV path - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created folder "/READ_ONLY" - And user "Alice" has created a share with settings - | path | /READ_ONLY | - | shareType | user | - | permissions | read | - | shareWith | Brian | - And user "Brian" has accepted share "/READ_ONLY" offered by user "Alice" - When user "Brian" uploads the following chunks to "/Shares/READ_ONLY/myfile.txt" with new chunking and using the WebDAV API - | number | content | - | 1 | hallo | - | 2 | welt | - Then the HTTP status code should be "403" - And as "Alice" file "/FOLDER/myfile.txt" should not exist - Scenario Outline: Sharer can download file uploaded with different permission by sharee to a shared folder Given using DAV path @@ -304,4 +286,4 @@ Feature: sharing Examples: | dav_version | | old | - | new | \ No newline at end of file + | new | diff --git a/tests/acceptance/features/coreApiSharePublicLink3/allowGroupToCreatePublicLinks.feature b/tests/acceptance/features/coreApiSharePublicLink3/allowGroupToCreatePublicLinks.feature new file mode 100644 index 00000000000..e69de29bb2d diff --git a/tests/acceptance/features/coreApiShareReshareToShares2/reShareChain.feature b/tests/acceptance/features/coreApiShareReshareToShares2/reShareChain.feature index 62cbc474a7a..56aa335275f 100644 --- a/tests/acceptance/features/coreApiShareReshareToShares2/reShareChain.feature +++ b/tests/acceptance/features/coreApiShareReshareToShares2/reShareChain.feature @@ -11,25 +11,6 @@ Feature: resharing can be done on a reshared resource | Carol | | David | - @notToImplementOnOCIS - Scenario Outline: Reshared files can be still accessed if a user in the middle removes it. - Given user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" - And user "Alice" has shared file "textfile0.txt" with user "Brian" - And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" - And user "Brian" has moved file "/Shares/textfile0.txt" to "/textfile0_shared.txt" - And user "Brian" has shared file "/textfile0_shared.txt" with user "Carol" - And user "Carol" has accepted share "" offered by user "Brian" - And user "Carol" has shared file "/Shares/textfile0_shared.txt" with user "David" - And user "David" has accepted share "" offered by user "Carol" - When user "Brian" deletes file "/textfile0_shared.txt" using the WebDAV API - Then the HTTP status code should be "204" - And the content of file "/Shares/textfile0_shared.txt" for user "Carol" should be "ownCloud test text file 0" - And the content of file "/Shares/textfile0_shared.txt" for user "David" should be "ownCloud test text file 0" - Examples: - | pending_share_path | - | /textfile0_shared.txt | - | /textfile0_shared.txt | - @skipOnOcV10 Scenario: Reshared files can be still accessed if a user in the middle removes it. Given user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" diff --git a/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature b/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature index 94d9360a3c4..a0e49f8f5a1 100644 --- a/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature +++ b/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature @@ -30,40 +30,6 @@ Feature: sharing | 1 | 100 | | 2 | 200 | - @issue-ocis-1289 @notToImplementOnOCIS - Scenario Outline: keep group permissions in sync when the share is moved to another folder by the receiver and then the sharer updates the permissions - Given using OCS API version "" - And user "Brian" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - And user "Alice" has shared file "textfile0.txt" with group "grp1" - And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice" - And user "Brian" has created folder "/FOLDER" - And user "Brian" has moved file "/Shares/textfile0.txt" to "/FOLDER/textfile0.txt" - When user "Alice" updates the last share using the sharing API with - | permissions | read | - Then the OCS status code should be "" - And the HTTP status code should be "200" - And the fields of the last response to user "Alice" sharing with group "grp1" should include - | id | A_STRING | - | item_type | file | - | item_source | A_STRING | - | share_type | group | - | file_source | A_STRING | - | file_target | /Shares/textfile0.txt | - | permissions | read | - | stime | A_NUMBER | - | storage | A_STRING | - | mail_send | 0 | - | uid_owner | %username% | - | displayname_owner | %displayname% | - | mimetype | text/plain | - Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | - @issue-ocis-1289 Scenario Outline: keep group permissions in sync when the share is renamed by the receiver and then the permissions are updated by sharer Given using OCS API version "" diff --git a/tests/acceptance/features/coreApiSharees/sharees.feature b/tests/acceptance/features/coreApiSharees/sharees.feature index e86128c1707..9972b75e672 100644 --- a/tests/acceptance/features/coreApiSharees/sharees.feature +++ b/tests/acceptance/features/coreApiSharees/sharees.feature @@ -54,28 +54,6 @@ Feature: sharees | 1 | 100 | 200 | | 2 | 200 | 200 | - @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 - Scenario Outline: Search only with group members - denied - Given using OCS API version "" - And parameter "shareapi_only_share_with_group_members" of app "core" has been set to "yes" - When user "Alice" gets the sharees using the sharing API with parameters - | search | sharee | - | itemType | file | - Then the OCS status code should be "" - And the HTTP status code should be "" - And the "exact users" sharees returned should be empty - And the "users" sharees returned should be empty - And the "exact groups" sharees returned should be empty - And the "groups" sharees returned should be - | ShareeGroup | 1 | ShareeGroup | - | ShareeGroup2 | 1 | ShareeGroup2 | - And the "exact remotes" sharees returned should be empty - And the "remotes" sharees returned should be empty - Examples: - | ocs-api-version | ocs-status | http-status | - | 1 | 100 | 200 | - | 2 | 200 | 200 | - @skipOnLDAP Scenario Outline: Search only with group members - allowed Given using OCS API version "" @@ -100,236 +78,6 @@ Feature: sharees | 1 | 100 | 200 | | 2 | 200 | 200 | - @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 - Scenario Outline: Search only with group members - no group as non-member - Given using OCS API version "" - And parameter "shareapi_only_share_with_group_members" of app "core" has been set to "yes" - And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" - When user "Sharee1" gets the sharees using the sharing API with parameters - | search | sharee | - | itemType | file | - Then the OCS status code should be "" - And the HTTP status code should be "" - And the "exact users" sharees returned should be empty - And the "users" sharees returned should be empty - And the "exact groups" sharees returned should be empty - And the "groups" sharees returned should be empty - And the "exact remotes" sharees returned should be empty - And the "remotes" sharees returned should be empty - Examples: - | ocs-api-version | ocs-status | http-status | - | 1 | 100 | 200 | - | 2 | 200 | 200 | - - @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 - Scenario Outline: Search only with membership groups - denied - Given using OCS API version "" - And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" - When user "Sharee1" gets the sharees using the sharing API with parameters - | search | ShareeGroup | - | itemType | file | - Then the OCS status code should be "" - And the HTTP status code should be "" - And the "exact users" sharees returned should be empty - And the "users" sharees returned should be empty - And the "exact groups" sharees returned should be empty - And the "groups" sharees returned should be empty - And the "exact remotes" sharees returned should be empty - And the "remotes" sharees returned should be empty - Examples: - | ocs-api-version | ocs-status | http-status | - | 1 | 100 | 200 | - | 2 | 200 | 200 | - - @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 - Scenario Outline: Search only with membership groups - denied but users match - Given using OCS API version "" - And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" - When user "Sharee1" gets the sharees using the sharing API with parameters - | search | sharee | - | itemType | file | - Then the OCS status code should be "" - And the HTTP status code should be "" - And the "exact users" sharees returned should be empty - And the "users" sharees returned should be - | Sharee One | 0 | sharee1 | - And the "exact groups" sharees returned should be empty - And the "groups" sharees returned should be empty - And the "exact remotes" sharees returned should be empty - And the "remotes" sharees returned should be empty - Examples: - | ocs-api-version | ocs-status | http-status | - | 1 | 100 | 200 | - | 2 | 200 | 200 | - - @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 - Scenario Outline: Search only with membership groups - allowed - Given using OCS API version "" - And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" - When user "Alice" gets the sharees using the sharing API with parameters - | search | ShareeGroup | - | itemType | file | - Then the OCS status code should be "" - And the HTTP status code should be "" - And the "exact users" sharees returned should be empty - And the "users" sharees returned should be empty - And the "exact groups" sharees returned should be empty - And the "groups" sharees returned should be - | ShareeGroup2 | 1 | ShareeGroup2 | - And the "exact remotes" sharees returned should be empty - And the "remotes" sharees returned should be empty - Examples: - | ocs-api-version | ocs-status | http-status | - | 1 | 100 | 200 | - | 2 | 200 | 200 | - - @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 - Scenario Outline: Search only with membership groups - allowed including users - Given using OCS API version "" - And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes" - When user "Alice" gets the sharees using the sharing API with parameters - | search | Sharee | - | itemType | file | - Then the OCS status code should be "" - And the HTTP status code should be "" - And the "exact users" sharees returned should be empty - And the "users" sharees returned should be - | Sharee One | 0 | sharee1 | - And the "exact groups" sharees returned should be empty - And the "groups" sharees returned should be - | ShareeGroup2 | 1 | ShareeGroup2 | - And the "exact remotes" sharees returned should be empty - And the "remotes" sharees returned should be empty - Examples: - | ocs-api-version | ocs-status | http-status | - | 1 | 100 | 200 | - | 2 | 200 | 200 | - - @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 - Scenario Outline: Search without exact match no iteration allowed - Given using OCS API version "" - And parameter "shareapi_allow_share_dialog_user_enumeration" of app "core" has been set to "no" - When user "Alice" gets the sharees using the sharing API with parameters - | search | Sharee | - | itemType | file | - Then the OCS status code should be "" - And the HTTP status code should be "" - And the "exact users" sharees returned should be empty - And the "users" sharees returned should be empty - And the "exact groups" sharees returned should be empty - And the "groups" sharees returned should be empty - And the "exact remotes" sharees returned should be empty - And the "remotes" sharees returned should be empty - Examples: - | ocs-api-version | ocs-status | http-status | - | 1 | 100 | 200 | - | 2 | 200 | 200 | - - @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 - Scenario Outline: Search with exact match no iteration allowed - Given using OCS API version "" - And parameter "shareapi_allow_share_dialog_user_enumeration" of app "core" has been set to "no" - When user "Alice" gets the sharees using the sharing API with parameters - | search | Sharee1 | - | itemType | file | - Then the OCS status code should be "" - And the HTTP status code should be "" - And the "exact users" sharees returned should be - | Sharee One | 0 | sharee1 | - And the "users" sharees returned should be empty - And the "exact groups" sharees returned should be empty - And the "groups" sharees returned should be empty - And the "exact remotes" sharees returned should be empty - And the "remotes" sharees returned should be empty - Examples: - | ocs-api-version | ocs-status | http-status | - | 1 | 100 | 200 | - | 2 | 200 | 200 | - - @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 - Scenario Outline: Search with exact match group no iteration allowed - Given using OCS API version "" - And parameter "shareapi_allow_share_dialog_user_enumeration" of app "core" has been set to "no" - When user "Alice" gets the sharees using the sharing API with parameters - | search | ShareeGroup | - | itemType | file | - Then the OCS status code should be "" - And the HTTP status code should be "" - And the "exact users" sharees returned should be empty - And the "users" sharees returned should be empty - And the "exact groups" sharees returned should be - | ShareeGroup | 1 | ShareeGroup | - And the "groups" sharees returned should be empty - And the "exact remotes" sharees returned should be empty - And the "remotes" sharees returned should be empty - Examples: - | ocs-api-version | ocs-status | http-status | - | 1 | 100 | 200 | - | 2 | 200 | 200 | - - @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 - Scenario Outline: Try to search for users and groups when in a group that is excluded from sharing (could match both users and groups) - Given using OCS API version "" - And parameter "shareapi_exclude_groups" of app "core" has been set to "yes" - And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["ShareeGroup2"]' - When user "Alice" gets the sharees using the sharing API with parameters - | search | sharee | - | itemType | file | - Then the OCS status code should be "" - And the HTTP status code should be "" - And the "exact users" sharees returned should be empty - And the "users" sharees returned should be empty - And the "exact groups" sharees returned should be empty - And the "groups" sharees returned should be empty - And the "exact remotes" sharees returned should be empty - And the "remotes" sharees returned should be empty - Examples: - | ocs-api-version | ocs-status | http-status | - | 1 | 100 | 200 | - | 2 | 200 | 200 | - - @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 - Scenario Outline: Try to search for users and groups when in a group that is excluded from sharing (exact match to a user) - Given using OCS API version "" - And parameter "shareapi_exclude_groups" of app "core" has been set to "yes" - And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["ShareeGroup2"]' - When user "Alice" gets the sharees using the sharing API with parameters - | search | sharee1 | - | itemType | file | - Then the OCS status code should be "" - And the HTTP status code should be "" - And the "exact users" sharees returned should be empty - And the "users" sharees returned should be empty - And the "exact groups" sharees returned should be empty - And the "groups" sharees returned should be empty - And the "exact remotes" sharees returned should be empty - And the "remotes" sharees returned should be empty - Examples: - | ocs-api-version | ocs-status | http-status | - | 1 | 100 | 200 | - | 2 | 200 | 200 | - - @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 - Scenario Outline: Try to search for users and groups when in a group that is excluded from sharing (exact match to a group) - Given using OCS API version "" - And parameter "shareapi_exclude_groups" of app "core" has been set to "yes" - And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["ShareeGroup2"]' - When user "Alice" gets the sharees using the sharing API with parameters - | search | ShareeGroup | - | itemType | file | - Then the OCS status code should be "" - And the HTTP status code should be "" - And the "exact users" sharees returned should be empty - And the "users" sharees returned should be empty - And the "exact groups" sharees returned should be empty - And the "groups" sharees returned should be empty - And the "exact remotes" sharees returned should be empty - And the "remotes" sharees returned should be empty - Examples: - | ocs-api-version | ocs-status | http-status | - | 1 | 100 | 200 | - | 2 | 200 | 200 | - Scenario Outline: Search with exact match Given using OCS API version "" @@ -449,27 +197,6 @@ Feature: sharees | 1 | 100 | 200 | | 2 | 200 | 200 | - @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 - Scenario Outline: Group sharees not returned when group sharing is disabled - Given using OCS API version "" - And parameter "shareapi_allow_group_sharing" of app "core" has been set to "no" - When user "Alice" gets the sharees using the sharing API with parameters - | search | sharee | - | itemType | file | - Then the OCS status code should be "" - And the HTTP status code should be "" - And the "exact users" sharees returned should be empty - And the "users" sharees returned should be - | Sharee One | 0 | sharee1 | - And the "exact groups" sharees returned should be empty - And the "groups" sharees returned should be empty - And the "exact remotes" sharees returned should be empty - And the "remotes" sharees returned should be empty - Examples: - | ocs-api-version | ocs-status | http-status | - | 1 | 100 | 200 | - | 2 | 200 | 200 | - @skipOnLDAP Scenario Outline: Enumerate only group members - only show partial results from member of groups Given using OCS API version "" @@ -495,70 +222,6 @@ Feature: sharees | 1 | 100 | 200 | | 2 | 200 | 200 | - @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 - Scenario Outline: Enumerate only group members - accept exact match from non-member groups - Given using OCS API version "" - And parameter "shareapi_share_dialog_user_enumeration_group_members" of app "core" has been set to "yes" - When user "Alice" gets the sharees using the sharing API with parameters - | search | Sharee1 | - | itemType | file | - Then the OCS status code should be "" - And the HTTP status code should be "" - And the "exact users" sharees returned should be - | Sharee One | 0 | sharee1 | - And the "users" sharees returned should be empty - And the "exact groups" sharees returned should be empty - And the "groups" sharees returned should be empty - And the "exact remotes" sharees returned should be empty - And the "remotes" sharees returned should be empty - Examples: - | ocs-api-version | ocs-status | http-status | - | 1 | 100 | 200 | - | 2 | 200 | 200 | - - @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 - Scenario Outline: Enumerate only group members - only show partial results from member groups - Given using OCS API version "" - And parameter "shareapi_share_dialog_user_enumeration_group_members" of app "core" has been set to "yes" - When user "Alice" gets the sharees using the sharing API with parameters - | search | ShareeG | - | itemType | file | - Then the OCS status code should be "" - And the HTTP status code should be "" - And the "exact users" sharees returned should be empty - And the "users" sharees returned should be empty - And the "exact groups" sharees returned should be empty - And the "groups" sharees returned should be - | ShareeGroup2 | 1 | ShareeGroup2 | - And the "exact remotes" sharees returned should be empty - And the "remotes" sharees returned should be empty - Examples: - | ocs-api-version | ocs-status | http-status | - | 1 | 100 | 200 | - | 2 | 200 | 200 | - - @skipOnLDAP @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 - Scenario Outline: Enumerate only group members - only accept exact group match from non-memberships - Given using OCS API version "" - And group "ShareeGroupNonMember" has been created - And parameter "shareapi_share_dialog_user_enumeration_group_members" of app "core" has been set to "yes" - When user "Alice" gets the sharees using the sharing API with parameters - | search | ShareeGroupNonMember | - | itemType | file | - Then the OCS status code should be "" - And the HTTP status code should be "" - And the "exact users" sharees returned should be empty - And the "users" sharees returned should be empty - And the "exact groups" sharees returned should be - | ShareeGroupNonMember | 1 | ShareeGroupNonMember | - And the "groups" sharees returned should be empty - And the "exact remotes" sharees returned should be empty - And the "remotes" sharees returned should be empty - Examples: - | ocs-api-version | ocs-status | http-status | - | 1 | 100 | 200 | - | 2 | 200 | 200 | - Scenario Outline: Search without exact match such that the search string matches the user getting the sharees Given user "sharee2" has been created with default attributes and without skeleton files @@ -583,53 +246,6 @@ Feature: sharees | 1 | 100 | 200 | | 2 | 200 | 200 | - @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 - Scenario Outline: empty search for sharees when search min length is set to 0 - Given the administrator has updated system config key "user.search_min_length" with value "0" - And user "sharee2" has been created with default attributes and without skeleton files - And using OCS API version "" - When user "sharee1" gets the sharees using the sharing API with parameters - | search | | - | itemType | file | - Then the OCS status code should be "" - And the HTTP status code should be "" - And the "exact users" sharees returned should be empty - And the "users" sharees returned should include - | Alice Hansen | 0 | Alice | - | Sharee One | 0 | sharee1 | - | Sharee Two | 0 | sharee2 | - And the "exact groups" sharees returned should be empty - And the "groups" sharees returned should include - | ShareeGroup | 1 | ShareeGroup | - | ShareeGroup2 | 1 | ShareeGroup2 | - And the "exact remotes" sharees returned should be empty - And the "remotes" sharees returned should be empty - Examples: - | ocs-api-version | ocs-status | http-status | - | 1 | 100 | 200 | - | 2 | 200 | 200 | - - @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 - Scenario Outline: empty search for sharees when search min length is set to 2 - Given the administrator has updated system config key "user.search_min_length" with value "2" - And user "sharee2" has been created with default attributes and without skeleton files - And using OCS API version "" - When user "sharee1" gets the sharees using the sharing API with parameters - | search | | - | itemType | file | - Then the OCS status code should be "" - And the HTTP status code should be "" - And the "exact users" sharees returned should be empty - And the "users" sharees returned should be empty - And the "exact groups" sharees returned should be empty - And the "groups" sharees returned should be empty - And the "exact remotes" sharees returned should be empty - And the "remotes" sharees returned should be empty - Examples: - | ocs-api-version | ocs-status | http-status | - | 1 | 100 | 200 | - | 2 | 200 | 200 | - Scenario Outline: search for sharees when search min length is set to 2 Given the administrator has updated system config key "user.search_min_length" with value "2" @@ -679,48 +295,3 @@ Feature: sharees | ocs-api-version | ocs-status | http-status | | 1 | 100 | 200 | | 2 | 200 | 200 | - - @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 - Scenario Outline: search for sharees without search when min length is set to 0 - Given the administrator has updated system config key "user.search_min_length" with value "0" - And user "sharee2" has been created with default attributes and without skeleton files - And using OCS API version "" - When user "sharee1" gets the sharees using the sharing API with parameters - | itemType | file | - Then the OCS status code should be "" - And the HTTP status code should be "" - And the "exact users" sharees returned should be empty - And the "users" sharees returned should include - | Alice Hansen | 0 | Alice | - | Sharee One | 0 | sharee1 | - | Sharee Two | 0 | sharee2 | - And the "exact groups" sharees returned should be empty - And the "groups" sharees returned should include - | ShareeGroup | 1 | ShareeGroup | - | ShareeGroup2 | 1 | ShareeGroup2 | - And the "exact remotes" sharees returned should be empty - And the "remotes" sharees returned should be empty - Examples: - | ocs-api-version | ocs-status | http-status | - | 1 | 100 | 200 | - | 2 | 200 | 200 | - - @notToImplementOnOCIS @issue-ocis-1317 @issue-ocis-1328 - Scenario Outline: search for sharees without search when min length is set to 2 - Given the administrator has updated system config key "user.search_min_length" with value "2" - And user "sharee2" has been created with default attributes and without skeleton files - And using OCS API version "" - When user "sharee1" gets the sharees using the sharing API with parameters - | itemType | file | - Then the OCS status code should be "" - And the HTTP status code should be "" - And the "exact users" sharees returned should be empty - And the "users" sharees returned should be empty - And the "exact groups" sharees returned should be empty - And the "groups" sharees returned should be empty - And the "exact remotes" sharees returned should be empty - And the "remotes" sharees returned should be empty - Examples: - | ocs-api-version | ocs-status | http-status | - | 1 | 100 | 200 | - | 2 | 200 | 200 | diff --git a/tests/acceptance/features/coreApiTrashbin/trashbinSharingToRoot.feature b/tests/acceptance/features/coreApiTrashbin/trashbinSharingToRoot.feature deleted file mode 100644 index a078f13e318..00000000000 --- a/tests/acceptance/features/coreApiTrashbin/trashbinSharingToRoot.feature +++ /dev/null @@ -1,178 +0,0 @@ -@api @files_trashbin-app-required @files_sharing-app-required @notToImplementOnOCIS -Feature: using trashbin together with sharing - - 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" - - @smokeTest - Scenario Outline: deleting a received folder doesn't move it to trashbin - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created folder "/shared" - And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" - And user "Alice" has shared folder "/shared" with user "Brian" - And user "Brian" has moved folder "/shared" to "/renamed_shared" - When user "Brian" deletes folder "/renamed_shared" using the WebDAV API - Then the HTTP status code should be "204" - And as "Brian" the folder with original path "/renamed_shared" should not exist in the trashbin - Examples: - | dav-path | - | new | - - - Scenario Outline: deleting a file in a received folder moves it to the trashbin of both users - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created folder "/shared" - And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" - And user "Alice" has shared folder "/shared" with user "Brian" - And user "Brian" has moved file "/shared" to "/renamed_shared" - When user "Brian" deletes file "/renamed_shared/shared_file.txt" using the WebDAV API - Then the HTTP status code should be "204" - And as "Brian" the file with original path "/renamed_shared/shared_file.txt" should exist in the trashbin - And as "Alice" the file with original path "/shared/shared_file.txt" should exist in the trashbin - Examples: - | dav-path | - | new | - - - Scenario Outline: sharee deleting a file in a group-shared folder moves it to the trashbin of sharee and sharer only - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And user "Carol" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Carol" has been added to group "grp1" - And user "Alice" has created folder "/shared" - And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" - And user "Alice" has shared folder "/shared" with group "grp1" - When user "Brian" deletes file "/shared/shared_file.txt" using the WebDAV API - Then the HTTP status code should be "204" - And as "Brian" the file with original path "/shared/shared_file.txt" should exist in the trashbin - And as "Alice" the file with original path "/shared/shared_file.txt" should exist in the trashbin - And as "Carol" the file with original path "/shared/shared_file.txt" should not exist in the trashbin - Examples: - | dav-path | - | new | - - - Scenario Outline: sharer deleting a file in a group-shared folder moves it to the trashbin of sharer only - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And user "Carol" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Carol" has been added to group "grp1" - And user "Alice" has created folder "/shared" - And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt" - And user "Alice" has shared folder "/shared" with group "grp1" - When user "Alice" deletes file "/shared/shared_file.txt" using the WebDAV API - Then the HTTP status code should be "204" - And as "Alice" the file with original path "/shared/shared_file.txt" should exist in the trashbin - And as "Brian" the file with original path "/shared/shared_file.txt" should not exist in the trashbin - And as "Carol" the file with original path "/shared/shared_file.txt" should not exist in the trashbin - Examples: - | dav-path | - | new | - - - Scenario Outline: sharee deleting a folder in a group-shared folder moves it to the trashbin of sharee and sharer only - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And user "Carol" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Carol" has been added to group "grp1" - And user "Alice" has created folder "/shared" - And user "Alice" has created folder "/shared/sub" - And user "Alice" has moved file "/textfile0.txt" to "/shared/sub/shared_file.txt" - And user "Alice" has shared folder "/shared" with group "grp1" - When user "Brian" deletes folder "/shared/sub" using the WebDAV API - Then the HTTP status code should be "204" - And as "Brian" the file with original path "/shared/sub/shared_file.txt" should exist in the trashbin - And as "Alice" the file with original path "/shared/sub/shared_file.txt" should exist in the trashbin - And as "Carol" the file with original path "/shared/sub/shared_file.txt" should not exist in the trashbin - Examples: - | dav-path | - | new | - - - Scenario Outline: sharer deleting a folder in a group-shared folder moves it to the trashbin of sharer only - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And user "Carol" has been created with default attributes and without skeleton files - And group "grp1" has been created - And user "Brian" has been added to group "grp1" - And user "Carol" has been added to group "grp1" - And user "Alice" has created folder "/shared" - And user "Alice" has created folder "/shared/sub" - And user "Alice" has moved file "/textfile0.txt" to "/shared/sub/shared_file.txt" - And user "Alice" has shared folder "/shared" with group "grp1" - When user "Alice" deletes folder "/shared/sub" using the WebDAV API - Then the HTTP status code should be "204" - And as "Alice" the file with original path "/shared/sub/shared_file.txt" should exist in the trashbin - And as "Brian" the file with original path "/shared/sub/shared_file.txt" should not exist in the trashbin - And as "Carol" the file with original path "/shared/sub/shared_file.txt" should not exist in the trashbin - Examples: - | dav-path | - | new | - - - Scenario Outline: deleting a file in a received folder when restored it comes back to the original path - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created folder "/shared" - And user "Alice" has uploaded file with content "to delete" to "/shared/shared_file.txt" - And user "Alice" has shared folder "/shared" with user "Brian" - And user "Brian" has moved file "/shared" to "/renamed_shared" - And user "Brian" has deleted file "/renamed_shared/shared_file.txt" - When user "Brian" restores the file with original path "/renamed_shared/shared_file.txt" using the trashbin API - Then the HTTP status code should be "201" - And the following headers should match these regular expressions for user "Brian" - | ETag | /^"[a-f0-9:\.]{1,32}"$/ | - And as "Brian" the file with original path "/renamed_shared/shared_file.txt" should not exist in the trashbin - And user "Brian" should see the following elements - | /renamed_shared/ | - | /renamed_shared/shared_file.txt | - And the content of file "/renamed_shared/shared_file.txt" for user "Brian" should be "to delete" - Examples: - | dav-path | - | new | - - - Scenario Outline: restoring a file to a read-only folder is not allowed - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And user "Brian" has created folder "shareFolderParent" - And user "Brian" has shared folder "shareFolderParent" with user "Alice" with permissions "read" - And as "Alice" folder "/shareFolderParent" should exist - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - And user "Alice" has deleted file "/textfile0.txt" - When user "Alice" restores the file with original path "/textfile0.txt" to "/shareFolderParent/textfile0.txt" using the trashbin API - Then the HTTP status code should be "403" - And as "Alice" the file with original path "/textfile0.txt" should exist in the trashbin - And as "Alice" file "/shareFolderParent/textfile0.txt" should not exist - And as "Brian" file "/shareFolderParent/textfile0.txt" should not exist - Examples: - | dav-path | - | new | - - - Scenario Outline: restoring a file to a read-only sub-folder is not allowed - Given using DAV path - And user "Brian" has been created with default attributes and without skeleton files - And user "Brian" has created folder "shareFolderParent" - And user "Brian" has created folder "shareFolderParent/shareFolderChild" - And user "Brian" has shared folder "shareFolderParent" with user "Alice" with permissions "read" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - And as "Alice" folder "/shareFolderParent/shareFolderChild" should exist - And user "Alice" has deleted file "/textfile0.txt" - When user "Alice" restores the file with original path "/textfile0.txt" to "/shareFolderParent/shareFolderChild/textfile0.txt" using the trashbin API - Then the HTTP status code should be "403" - And as "Alice" the file with original path "/textfile0.txt" should exist in the trashbin - And as "Alice" file "/shareFolderParent/shareFolderChild/textfile0.txt" should not exist - And as "Brian" file "/shareFolderParent/shareFolderChild/textfile0.txt" should not exist - Examples: - | dav-path | - | new | diff --git a/tests/acceptance/features/coreApiTrashbin/trashbinSkip.feature b/tests/acceptance/features/coreApiTrashbin/trashbinSkip.feature deleted file mode 100644 index 4fe1104b4fa..00000000000 --- a/tests/acceptance/features/coreApiTrashbin/trashbinSkip.feature +++ /dev/null @@ -1,323 +0,0 @@ -@api @files_trashbin-app-required @notToImplementOnOCIS -Feature: files and folders can be deleted completely skipping the trashbin - As an admin - I want to configure some files to be deleted without 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 created folder "PARENT" - And user "Alice" has created folder "simple-folder" - And user "Alice" has created folder "lorem-folder" - - - Scenario Outline: Skip trashbin based on extensions - Given the administrator has set the following file extensions to be skipped from the trashbin - | extension | - | dat | - | php | - | go | - And using DAV path - And user "Alice" has uploaded file with content "sample delete file 1" to "sample.txt" - And user "Alice" has uploaded file with content "sample delete file 2" to "sample.dat" - And user "Alice" has uploaded file with content "sample delete file 3" to "sample.php" - And user "Alice" has uploaded file with content "sample delete file 4" to "sample.go" - And user "Alice" has uploaded file with content "sample delete file 5" to "sample.py" - When user "Alice" deletes the following files - | path | - | sample.txt | - | sample.dat | - | sample.php | - | sample.go | - | sample.py | - Then the HTTP status code of responses on all endpoints should be "204" - And as "Alice" file "sample.txt" should exist in the trashbin - And as "Alice" file "sample.py" should exist in the trashbin - But as "Alice" the file with original path "/sample.dat" should not exist in the trashbin - And as "Alice" the file with original path "/sample.php" should not exist in the trashbin - And as "Alice" the file with original path "/sample.go" should not exist in the trashbin - Examples: - | dav-path | - | new | - - - Scenario Outline: Skip trashbin based on extensions - file in a folder - Given the administrator has set the following file extensions to be skipped from the trashbin - | extension | - | dat | - | php | - | go | - And using DAV path - And user "Alice" has uploaded file with content "sample delete file 1" to "PARENT/sample.txt" - And user "Alice" has uploaded file with content "sample delete file 2" to "PARENT/sample.dat" - And user "Alice" has uploaded file with content "sample delete file 3" to "PARENT/sample.php" - And user "Alice" has uploaded file with content "sample delete file 4" to "PARENT/sample.go" - And user "Alice" has uploaded file with content "sample delete file 5" to "PARENT/sample.py" - When user "Alice" deletes the following files - | path | - | PARENT/sample.txt | - | PARENT/sample.dat | - | PARENT/sample.php | - | PARENT/sample.go | - | PARENT/sample.py | - Then the HTTP status code of responses on all endpoints should be "204" - And as "Alice" the file with original path "/PARENT/sample.txt" should exist in the trashbin - And as "Alice" the file with original path "/PARENT/sample.py" should exist in the trashbin - But as "Alice" the file with original path "/PARENT/sample.dat" should not exist in the trashbin - And as "Alice" the file with original path "/PARENT/sample.php" should not exist in the trashbin - And as "Alice" the file with original path "/PARENT/sample.go" should not exist in the trashbin - Examples: - | dav-path | - | new | - - - Scenario Outline: Skip trashbin based on extensions - match is case-insensitive - Given the administrator has set the following file extensions to be skipped from the trashbin - | extension | - | dat | - | php | - | go | - And using DAV path - And user "Alice" has uploaded file with content "sample delete file 1" to "sample.TXT" - And user "Alice" has uploaded file with content "sample delete file 1" to "sample.txt" - And user "Alice" has uploaded file with content "sample delete file 2" to "sample.DAT" - And user "Alice" has uploaded file with content "sample delete file 2" to "sample.dat" - And user "Alice" has uploaded file with content "sample delete file 3" to "sample.PHP" - And user "Alice" has uploaded file with content "sample delete file 3" to "sample.php" - And user "Alice" has uploaded file with content "sample delete file 4" to "sample.GO" - And user "Alice" has uploaded file with content "sample delete file 4" to "sample.go" - And user "Alice" has uploaded file with content "sample delete file 5" to "sample.PY" - And user "Alice" has uploaded file with content "sample delete file 5" to "sample.py" - When user "Alice" deletes the following files - | path | - | sample.TXT | - | sample.txt | - | sample.DAT | - | sample.dat | - | sample.PHP | - | sample.php | - | sample.GO | - | sample.go | - | sample.PY | - | sample.py | - Then the HTTP status code of responses on all endpoints should be "204" - And as "Alice" the file with original path "/sample.TXT" should exist in the trashbin - And as "Alice" the file with original path "/sample.txt" should exist in the trashbin - And as "Alice" the file with original path "/sample.PY" should exist in the trashbin - And as "Alice" the file with original path "/sample.py" should exist in the trashbin - But as "Alice" the file with original path "/sample.DAT" should not exist in the trashbin - And as "Alice" the file with original path "/sample.dat" should not exist in the trashbin - And as "Alice" the file with original path "/sample.PHP" should not exist in the trashbin - And as "Alice" the file with original path "/sample.php" should not exist in the trashbin - And as "Alice" the file with original path "/sample.GO" should not exist in the trashbin - And as "Alice" the file with original path "/sample.go" should not exist in the trashbin - Examples: - | dav-path | - | new | - - - Scenario Outline: Skip trashbin based on extensions when deleting the parent folder - skip-by-extension rules should not be applied - Given the administrator has set the following file extensions to be skipped from the trashbin - | extension | - | dat | - | php | - | go | - And using DAV path - And user "Alice" has uploaded file with content "sample delete file 1" to "PARENT/sample.txt" - And user "Alice" has uploaded file with content "sample delete file 2" to "PARENT/sample.dat" - And user "Alice" has uploaded file with content "sample delete file 3" to "PARENT/sample.php" - And user "Alice" has uploaded file with content "sample delete file 4" to "PARENT/sample.go" - And user "Alice" has uploaded file with content "sample delete file 5" to "PARENT/sample.py" - When user "Alice" deletes folder "PARENT" using the WebDAV API - Then the HTTP status code should be "204" - And as "Alice" the file with original path "PARENT/sample.txt" should exist in the trashbin - And as "Alice" the file with original path "PARENT/sample.py" should exist in the trashbin - And as "Alice" the file with original path "PARENT/sample.dat" should exist in the trashbin - And as "Alice" the file with original path "PARENT/sample.php" should exist in the trashbin - And as "Alice" the file with original path "PARENT/sample.go" should exist in the trashbin - Examples: - | dav-path | - | new | - - - Scenario Outline: Skip trashbin based on directory - Given the administrator has set the following directories to be skipped from the trashbin - | directory | - | PARENT | - | simple-folder | - And using DAV path - And user "Alice" has uploaded file with content "sample delete file 1" to "sample.txt" - And user "Alice" has uploaded file with content "sample delete file 2" to "PARENT/sample.dat" - And user "Alice" has uploaded file with content "sample delete file 3" to "simple-folder/sample.php" - And user "Alice" has uploaded file with content "sample delete file 4" to "simple-folder/sample.go" - And user "Alice" has uploaded file with content "sample delete file 5" to "lorem-folder/sample.py" - When user "Alice" deletes the following files - | path | - | sample.txt | - | PARENT/sample.dat | - | simple-folder/sample.php | - | simple-folder/sample.go | - | lorem-folder/sample.py | - Then the HTTP status code of responses on all endpoints should be "204" - And as "Alice" the file with original path "sample.txt" should exist in the trashbin - And as "Alice" the file with original path "lorem-folder/sample.py" should exist in the trashbin - And as "Alice" the file with original path "PARENT/sample.dat" should not exist in the trashbin - But as "Alice" the file with original path "simple-folder/sample.php" should not exist in the trashbin - And as "Alice" the file with original path "simple-folder/sample.go" should not exist in the trashbin - Examples: - | dav-path | - | new | - - - Scenario Outline: Skip trashbin based on directory should match only the root folder name - Given the administrator has set the following directories to be skipped from the trashbin - | directory | - | simple-folder | - And using DAV path - And user "Alice" has created folder "PARENT/simple-folder" - And user "Alice" has uploaded file with content "sample delete file 1" to "PARENT/p.txt" - And user "Alice" has uploaded file with content "sample delete file 2" to "PARENT/simple-folder/sub.txt" - And user "Alice" has uploaded file with content "sample delete file 3" to "simple-folder/s.txt" - When user "Alice" deletes folder "PARENT" using the WebDAV API - And user "Alice" deletes folder "simple-folder" using the WebDAV API - Then the HTTP status code of responses on all endpoints should be "204" - And as "Alice" the file with original path "PARENT/p.txt" should exist in the trashbin - And as "Alice" the file with original path "PARENT/simple-folder/sub.txt" should exist in the trashbin - But as "Alice" the file with original path "simple-folder/s.txt" should not exist in the trashbin - Examples: - | dav-path | - | new | - - - Scenario Outline: Delete a file in a folder skipped from trashbin - Given the administrator has set the following directories to be skipped from the trashbin - | directory | - | PARENT | - And using DAV path - And user "Alice" has uploaded file with content "sample delete file 2" to "PARENT/sample.dat" - When user "Alice" deletes file "PARENT/sample.dat" using the WebDAV API - Then the HTTP status code should be "204" - And as "Alice" the file with original path "/PARENT" should not exist in the trashbin - And as "Alice" the file with original path "/PARENT/sample.dat" should not exist in the trashbin - Examples: - | dav-path | - | new | - - - Scenario Outline: Delete a file with same name as folder skipped from trashbin - Given the administrator has set the following directories to be skipped from the trashbin - | directory | - | skipFile | - And using DAV path - And user "Alice" has uploaded file with content "sample delete file 2" to "skipFile" - When user "Alice" deletes file "skipFile" using the WebDAV API - Then the HTTP status code should be "204" - And as "Alice" the file with original path "skipFile" should exist in the trashbin - Examples: - | dav-path | - | new | - - - Scenario Outline: Delete a file from a folder skipped from trashbin but different case - Given the administrator has set the following directories to be skipped from the trashbin - | directory | - | parent | - And using DAV path - And user "Alice" has uploaded file with content "sample delete file 2" to "PARENT/lorem.txt" - When user "Alice" deletes file "PARENT/lorem.txt" using the WebDAV API - Then the HTTP status code should be "204" - And as "Alice" the file with original path "PARENT/lorem.txt" should exist in the trashbin - Examples: - | dav-path | - | new | - - - Scenario Outline: Skip file from trashbin based on size threshold - Given the administrator has set the trashbin skip size threshold to "10" - And using DAV path - And user "Alice" has uploaded file with content "sample" to "lorem.txt" - And user "Alice" has uploaded file with content "sample delete file" to "lorem.dat" - When user "Alice" deletes file "/lorem.txt" using the WebDAV API - And user "Alice" deletes file "/lorem.dat" using the WebDAV API - Then the HTTP status code of responses on all endpoints should be "204" - And as "Alice" the file with original path "lorem.txt" should exist in the trashbin - But as "Alice" the file with original path "lorem.dat" should not exist in the trashbin - Examples: - | dav-path | - | new | - - - Scenario Outline: Skip file from trashbin based on size threshold - file in a folder - Given the administrator has set the trashbin skip size threshold to "10" - And using DAV path - And user "Alice" has uploaded file with content "sample" to "PARENT/lorem.txt" - And user "Alice" has uploaded file with content "sample delete file" to "PARENT/lorem.dat" - When user "Alice" deletes file "PARENT/lorem.txt" using the WebDAV API - And user "Alice" deletes file "PARENT/lorem.dat" using the WebDAV API - Then the HTTP status code of responses on all endpoints should be "204" - And as "Alice" the file with original path "PARENT/lorem.txt" should exist in the trashbin - But as "Alice" the file with original path "PARENT/lorem.dat" should not exist in the trashbin - Examples: - | dav-path | - | new | - - - Scenario Outline: Skip file from trashbin based on size threshold when deleting the parent folder - skip-by-size rules should not be applied - Given the administrator has set the trashbin skip size threshold to "10" - And using DAV path - And user "Alice" has uploaded file with content "sample" to "PARENT/lorem.txt" - And user "Alice" has uploaded file with content "sample delete file" to "PARENT/lorem.dat" - When user "Alice" deletes folder "PARENT" using the WebDAV API - Then the HTTP status code should be "204" - And as "Alice" the file with original path "PARENT/lorem.txt" should exist in the trashbin - And as "Alice" the file with original path "PARENT/lorem.dat" should exist in the trashbin - Examples: - | dav-path | - | new | - - - Scenario Outline: Delete files when multiple skip trashbin rules are set - Given the administrator has set the following directories to be skipped from the trashbin - | directory | - | PARENT | - And the administrator has set the following file extensions to be skipped from the trashbin - | extension | - | dat | - And the administrator has set the trashbin skip size threshold to "20" - And using DAV path - # files that match none of the skip trashbin rules - And user "Alice" has uploaded file with content "sample" to "sample.txt" - And user "Alice" has uploaded file with content "sample" to "lorem-folder/sample.go" - # files that match just the "extension" skip trashbin rule - And user "Alice" has uploaded file with content "sample delete 1" to "sample.dat" - And user "Alice" has uploaded file with content "sample delete 3" to "lorem-folder/sample.dat" - # files that match just the "directory" skip trashbin rule - And user "Alice" has uploaded file with content "sample delete 2" to "PARENT/sample.txt" - # files that match just the "size threshold" skip trashbin rule - And user "Alice" has uploaded file with content "sample delete file long 2" to "simple-folder/sample.php" - # files that match 2 skip trashbin rules - And user "Alice" has uploaded file with content "sample delete file long 1" to "PARENT/sample.lis" - # files that match all 3 skip trashbin rules - And user "Alice" has uploaded file with content "sample delete file long 1" to "PARENT/sample.dat" - When user "Alice" deletes the following files - | path | - | sample.txt | - | lorem-folder/sample.go | - | sample.dat | - | lorem-folder/sample.dat | - | PARENT/sample.txt | - | simple-folder/sample.php | - | PARENT/sample.lis | - | PARENT/sample.dat | - Then the HTTP status code of responses on all endpoints should be "204" - And as "Alice" the file with original path "sample.txt" should exist in the trashbin - And as "Alice" the file with original path "lorem-folder/sample.go" should exist in the trashbin - But as "Alice" the file with original path "sample.dat" should not exist in the trashbin - And as "Alice" the file with original path "lorem-folder/sample.dat" should not exist in the trashbin - And as "Alice" the file with original path "PARENT/sample.txt" should not exist in the trashbin - And as "Alice" the file with original path "simple-folder/sample.php" should not exist in the trashbin - And as "Alice" the file with original path "PARENT/sample.lis" should not exist in the trashbin - And as "Alice" the file with original path "PARENT/sample.dat" should not 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 7294a27a468..f516c5c13f7 100644 --- a/tests/acceptance/features/coreApiTrashbinRestore/trashbinRestore.feature +++ b/tests/acceptance/features/coreApiTrashbinRestore/trashbinRestore.feature @@ -167,22 +167,6 @@ Feature: Restore deleted files/folders And as "Alice" the folder with original path "/local_storage/tmp/textfile0.txt" should not exist in the trashbin And the content of file "/local_storage/tmp/textfile0.txt" for user "Alice" should be "AA" - @local_storage @files_external-app-required @skipOnEncryptionType:user-keys @encryption-issue-42 @skip_on_objectstore @notToImplementOnOCIS @newChunking @issue-ocis-1321 - Scenario: Deleting an updated file into external storage moves it to the trashbin and can be restored with new chunking - Given using new DAV path - And the administrator has invoked occ command "files:scan --all" - And user "Alice" has created folder "/local_storage/tmp" - And user "Alice" has moved file "/textfile0.txt" to "/local_storage/tmp/textfile0.txt" - And user "Alice" has uploaded the following chunks to "/local_storage/tmp/textfile0.txt" with new chunking - | number | content | - | 1 | AA | - And user "Alice" has deleted file "/local_storage/tmp/textfile0.txt" - And as "Alice" the folder with original path "/local_storage/tmp/textfile0.txt" should exist in the trashbin - When user "Alice" restores the folder with original path "/local_storage/tmp/textfile0.txt" using the trashbin API - Then the HTTP status code should be "201" - And as "Alice" the folder with original path "/local_storage/tmp/textfile0.txt" should not exist in the trashbin - And the content of file "/local_storage/tmp/textfile0.txt" for user "Alice" should be "AA" - @smokeTest Scenario Outline: A deleted file cannot be restored by a different user Given using DAV path diff --git a/tests/acceptance/features/coreApiWebdavDelete/deleteFolder.feature b/tests/acceptance/features/coreApiWebdavDelete/deleteFolder.feature index 65e088bf36f..bbeaea5d718 100644 --- a/tests/acceptance/features/coreApiWebdavDelete/deleteFolder.feature +++ b/tests/acceptance/features/coreApiWebdavDelete/deleteFolder.feature @@ -62,50 +62,6 @@ Feature: delete folder | dav_version | | spaces | - @files_sharing-app-required @notToImplementOnOCIS - Scenario Outline: delete a folder when there is a default folder for received shares - Given using DAV path - And the administrator has set the default folder for received shares to "" - And user "Brian" has been created with default attributes and without skeleton files - And user "Brian" has created folder "/Received" - And user "Brian" has created folder "/Top" - And user "Brian" has created folder "/Top/ReceivedShares" - And user "Alice" has shared folder "/PARENT" with user "Brian" - When user "Brian" deletes folder "" using the WebDAV API - Then the HTTP status code should be "403" - And as "Brian" folder "/PARENT" should exist - And user "Brian" should be able to delete folder "/Received" - And user "Brian" should be able to delete folder "/Top/ReceivedShares" - And user "Brian" should be able to delete folder "/Top" - Examples: - | dav_version | share_folder | - | old | ReceivedShares | - | old | /ReceivedShares | - | new | ReceivedShares | - | new | /ReceivedShares | - - @files_sharing-app-required @notToImplementOnOCIS - Scenario Outline: delete a folder when there is a default folder for received shares that is a multi-level path - Given using DAV path - And the administrator has set the default folder for received shares to "/My/Received/Shares" - And user "Brian" has been created with default attributes and without skeleton files - And user "Brian" has created folder "/M" - And user "Brian" has created folder "/Received" - And user "Brian" has created folder "/Received/Shares" - And user "Alice" has shared folder "/PARENT" with user "Brian" - When user "Brian" deletes folder "/My/Received/Shares" using the WebDAV API - Then the HTTP status code should be "403" - And user "Brian" should not be able to delete folder "/My/Received" - And user "Brian" should not be able to delete folder "/My" - And as "Brian" folder "/My/Received/Shares/PARENT" should exist - But user "Brian" should be able to delete folder "/M" - And user "Brian" should be able to delete folder "/Received/Shares" - And user "Brian" should be able to delete folder "/Received" - Examples: - | dav_version | - | old | - | new | - Scenario Outline: deleting folder with dot in the name Given using DAV path diff --git a/tests/acceptance/features/coreApiWebdavLocks/exclusiveLocks.feature b/tests/acceptance/features/coreApiWebdavLocks/exclusiveLocks.feature index e4acb8096e5..48597aaf90b 100644 --- a/tests/acceptance/features/coreApiWebdavLocks/exclusiveLocks.feature +++ b/tests/acceptance/features/coreApiWebdavLocks/exclusiveLocks.feature @@ -27,84 +27,6 @@ Feature: there can be only one exclusive lock on a resource | spaces | shared | | spaces | exclusive | - @notToImplementOnOCIS - Scenario Outline: if a parent resource is exclusively locked a child resource cannot be locked again - Given using DAV path - 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 user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | exclusive | - When user "Alice" locks folder "PARENT/CHILD" using the WebDAV API setting the following properties - | lockscope | | - Then the HTTP status code should be "423" - And 1 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 | - - @notToImplementOnOCIS - Scenario Outline: if a parent resource is exclusively locked with depth 0 a child resource can be locked again - Given using DAV path - 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 user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | exclusive | - | depth | 0 | - When user "Alice" locks folder "PARENT/CHILD" using the WebDAV API setting the following properties - | lockscope | | - Then the HTTP status code should be "200" - And 1 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 | - - @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" - And user "Alice" has created folder "PARENT/CHILD" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/CHILD/child.txt" - 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 "423" - And 1 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 | - - @notToImplementOnOCIS - Scenario Outline: if a child resource is exclusively locked a parent resource can be locked with depth 0 - Given using DAV path - 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 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 | | - | depth | 0 | - Then the HTTP status code should be "200" - And 1 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 | - @files_sharing-app-required Scenario Outline: a share receiver cannot lock a resource exclusively locked by itself Given using DAV path diff --git a/tests/acceptance/features/coreApiWebdavLocks/folder.feature b/tests/acceptance/features/coreApiWebdavLocks/folder.feature deleted file mode 100644 index d87871b046d..00000000000 --- a/tests/acceptance/features/coreApiWebdavLocks/folder.feature +++ /dev/null @@ -1,128 +0,0 @@ -@api @issue-ocis-reva-172 -Feature: lock folders - - Background: - Given user "Alice" has been created with default attributes and without skeleton files - - @smokeTest @notToImplementOnOCIS - Scenario Outline: upload to a locked folder - Given using DAV path - And user "Alice" has created folder "FOLDER" - And user "Alice" has locked folder "FOLDER" setting the following properties - | lockscope | | - When user "Alice" uploads file "filesForUpload/textfile.txt" to "/FOLDER/textfile.txt" using the WebDAV API - Then the HTTP status code should be "423" - And as "Alice" file "/FOLDER/textfile.txt" should not exist - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - @notToImplementOnOCIS - Scenario Outline: upload to a subfolder of a locked folder - Given using DAV path - And user "Alice" has created folder "PARENT" - And user "Alice" has created folder "PARENT/CHILD" - And user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - When user "Alice" uploads file "filesForUpload/textfile.txt" to "/PARENT/CHILD/textfile.txt" using the WebDAV API - Then the HTTP status code should be "423" - And as "Alice" file "/PARENT/CHILD/textfile.txt" should not exist - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - @smokeTest @notToImplementOnOCIS - Scenario Outline: create folder in a locked folder - Given using DAV path - And user "Alice" has created folder "FOLDER" - And user "Alice" has locked folder "FOLDER" setting the following properties - | lockscope | | - When user "Alice" creates folder "/FOLDER/new-folder" using the WebDAV API - Then the HTTP status code should be "423" - And as "Alice" folder "/FOLDER/new-folder" should not exist - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - @notToImplementOnOCIS - Scenario Outline: create folder in a subfolder of a locked folder - Given using DAV path - And user "Alice" has created folder "PARENT" - And user "Alice" has created folder "PARENT/CHILD" - And user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - When user "Alice" creates folder "/PARENT/CHILD/new-folder" using the WebDAV API - Then the HTTP status code should be "423" - And as "Alice" folder "/PARENT/CHILD/new-folder" should not exist - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - @notToImplementOnOCIS - Scenario Outline: Move file out of a locked folder - Given 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 locked folder "PARENT" setting the following properties - | lockscope | | - When user "Alice" moves file "/PARENT/parent.txt" to "/parent.txt" using the WebDAV API - Then the HTTP status code should be "423" - And as "Alice" file "/parent.txt" should not exist - But as "Alice" file "/PARENT/parent.txt" should exist - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - @notToImplementOnOCIS - Scenario Outline: Move file out of a locked sub folder one level higher into locked parent folder - Given using DAV path - 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 user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - When user "Alice" moves file "/PARENT/CHILD/child.txt" to "/PARENT/child.txt" using the WebDAV API - Then the HTTP status code should be "423" - And as "Alice" file "/PARENT/child.txt" should not exist - But as "Alice" file "/PARENT/CHILD/child.txt" should exist - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - @notToImplementOnOCIS - Scenario Outline: lockdiscovery of a locked folder - Given using DAV path - And user "Alice" has created folder "PARENT" - And user "Alice" has created a public link share of folder "PARENT" with change permission - And user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - When user "Alice" gets the following properties of folder "PARENT" using the WebDAV API - | propertyName | - | d:lockdiscovery | - Then the HTTP status code should be "200" - And the value of the item "//d:lockroot/d:href" in the response to user "Alice" should match "" - And the value of the item "//d:locktoken/d:href" in the response to user "Alice" should match "/^opaquelocktoken:[a-z0-9-]+$/" - Examples: - | dav-path | lock-scope | lock-root | - | old | shared | /%base_path%\/remote.php\/webdav\/PARENT$/ | - | old | exclusive | /%base_path%\/remote.php\/webdav\/PARENT$/ | - | new | shared | /%base_path%\/remote.php\/dav\/files\/%username%\/PARENT$/ | - | new | exclusive | /%base_path%\/remote.php\/dav\/files\/%username%\/PARENT$/ | \ No newline at end of file diff --git a/tests/acceptance/features/coreApiWebdavLocks/publicLink.feature b/tests/acceptance/features/coreApiWebdavLocks/publicLink.feature deleted file mode 100644 index bf020e32b22..00000000000 --- a/tests/acceptance/features/coreApiWebdavLocks/publicLink.feature +++ /dev/null @@ -1,100 +0,0 @@ -@api @smokeTest @public_link_share-feature-required @files_sharing-app-required @issue-ocis-reva-172 @notToImplementOnOCIS -Feature: persistent-locking in case of a public link - - Background: - 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/parent.txt" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/CHILD/child.txt" - - @smokeTest - Scenario Outline: Uploading a file into a locked public folder - Given using DAV path - And user "Alice" has created folder "FOLDER" - And user "Alice" has created a public link share of folder "FOLDER" with change permission - And user "Alice" has locked folder "FOLDER" setting the following properties - | lockscope | | - When the public uploads file "/test.txt" with content "test" using the public WebDAV API - Then the HTTP status code should be "423" - And as "Alice" file "/FOLDER/test.txt" should not exist - Examples: - | dav-path | lock-scope | public-webdav-api-version | - | old | shared | old | - | old | exclusive | old | - | new | shared | old | - | new | exclusive | old | - | old | shared | new | - | old | exclusive | new | - | new | shared | new | - | new | exclusive | new | - - - Scenario Outline: Uploading a file into a locked subfolder of a public folder - Given user "Alice" has created a public link share of folder "PARENT" with change permission - And user "Alice" has locked folder "PARENT/CHILD" setting the following properties - | lockscope | | - And the public has uploaded file "test.txt" with content "test" - When the public uploads file "CHILD/test.txt" with content "test" using the public WebDAV API - Then the HTTP status code should be "423" - And as "Alice" file "/PARENT/CHILD/test.txt" should not exist - But the content of file "/PARENT/test.txt" for user "Alice" should be "test" - Examples: - | public-webdav-api-version | lock-scope | - | new | shared | - | new | exclusive | - - @smokeTest - Scenario Outline: Overwrite a file inside a locked public folder - Given user "Alice" has created a public link share of folder "PARENT" with change permission - And user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - When the public uploads file "parent.txt" with content "test" using the public WebDAV API - Then the HTTP status code should be "423" - And the content of file "/PARENT/parent.txt" for user "Alice" should be: - """ - This is a testfile. - - Cheers. - """ - Examples: - | public-webdav-api-version | lock-scope | - | new | shared | - | new | exclusive | - - - Scenario Outline: Overwrite a file inside a locked subfolder of a public folder - Given user "Alice" has created a public link share of folder "PARENT" with change permission - And user "Alice" has locked folder "PARENT/CHILD" setting the following properties - | lockscope | | - And the public has uploaded file "parent.txt" with content "changed text" - When the public uploads file "CHILD/child.txt" with content "test" using the public WebDAV API - Then the HTTP status code should be "423" - And the content of file "/PARENT/parent.txt" for user "Alice" should be "changed text" - But the content of file "/PARENT/CHILD/child.txt" for user "Alice" should be: - """ - This is a testfile. - - Cheers. - """ - Examples: - | public-webdav-api-version | lock-scope | - | new | shared | - | new | exclusive | - - @smokeTest - Scenario Outline: Public locking is not supported - Given user "Alice" has created a public link share of folder "PARENT" with change permission - When the public locks "/CHILD" in the last public link shared folder using the public WebDAV API setting the following properties - | lockscope | | - Then the HTTP status code should be "405" - And the value of the item "//s:message" in the response should be "Locking not allowed from public endpoint" - Examples: - | public-webdav-api-version | lock-scope | - | old | shared | - | old | exclusive | - - Examples: - | public-webdav-api-version | lock-scope | - | new | shared | - | new | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavLocks/publicLinkLockdiscovery.feature b/tests/acceptance/features/coreApiWebdavLocks/publicLinkLockdiscovery.feature deleted file mode 100644 index da02828a22a..00000000000 --- a/tests/acceptance/features/coreApiWebdavLocks/publicLinkLockdiscovery.feature +++ /dev/null @@ -1,127 +0,0 @@ -@api @smokeTest @public_link_share-feature-required @files_sharing-app-required @issue-ocis-reva-172 @notToImplementOnOCIS -Feature: LOCKDISCOVERY for public links - - Background: - 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" - - - Scenario Outline: lockdiscovery root of public link when root is locked - Given user "Alice" has created a public link share of folder "PARENT" with change permission - And user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - When the public gets the following properties of entry "/" in the last created public link using the WebDAV API - | propertyName | - | d:lockdiscovery | - Then the HTTP status code should be "200" - And the value of the item "//d:lockroot/d:href" in the response should match "/%base_path%\/public.php\/webdav\/$/" - And the item "//d:locktoken/d:href" in the response should not exist - And the value of the item "//d:timeout" in the response should match "/Second-\d+/" - Examples: - | lock-scope | - | shared | - | exclusive | - - - Scenario Outline: lockdiscovery subfolder of a locked public link when root is locked - Given user "Alice" has created a public link share of folder "PARENT" with change permission - And user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - When the public gets the following properties of entry "/CHILD" in the last created public link using the WebDAV API - | propertyName | - | d:lockdiscovery | - Then the HTTP status code should be "200" - And the value of the item "//d:lockroot/d:href" in the response should match "/%base_path%\/public.php\/webdav\/$/" - And the item "//d:locktoken/d:href" in the response should not exist - And the value of the item "//d:timeout" in the response should match "/Second-\d+/" - Examples: - | lock-scope | - | shared | - | exclusive | - - - Scenario Outline: lockdiscovery subfolder of a public link when subfolder is locked - Given user "Alice" has created a public link share of folder "PARENT" with change permission - And user "Alice" has locked folder "PARENT/CHILD" setting the following properties - | lockscope | | - When the public gets the following properties of entry "/CHILD" in the last created public link using the WebDAV API - | propertyName | - | d:lockdiscovery | - Then the HTTP status code should be "200" - And the value of the item "//d:lockroot/d:href" in the response should match "/%base_path%\/public.php\/webdav\/CHILD$/" - And the item "//d:locktoken/d:href" in the response should not exist - And the value of the item "//d:timeout" in the response should match "/Second-\d+/" - Examples: - | lock-scope | - | shared | - | exclusive | - - - Scenario Outline: lockdiscovery file in a subfolder of a public link when subfolder is locked - Given user "Alice" has created a public link share of folder "PARENT" with change permission - And user "Alice" has locked folder "PARENT/CHILD" setting the following properties - | lockscope | | - When the public gets the following properties of entry "/CHILD/child.txt" in the last created public link using the WebDAV API - | propertyName | - | d:lockdiscovery | - Then the HTTP status code should be "200" - And the value of the item "//d:lockroot/d:href" in the response should match "/%base_path%\/public.php\/webdav\/CHILD$/" - And the item "//d:locktoken/d:href" in the response should not exist - And the value of the item "//d:timeout" in the response should match "/Second-\d+/" - Examples: - | lock-scope | - | shared | - | exclusive | - - - Scenario Outline: lockdiscovery file in a subfolder of a public link when root is locked - Given user "Alice" has created a public link share of folder "PARENT" with change permission - And user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - When the public gets the following properties of entry "/CHILD/child.txt" in the last created public link using the WebDAV API - | propertyName | - | d:lockdiscovery | - Then the HTTP status code should be "200" - And the value of the item "//d:lockroot/d:href" in the response should match "/%base_path%\/public.php\/webdav\/$/" - And the item "//d:locktoken/d:href" in the response should not exist - And the value of the item "//d:timeout" in the response should match "/Second-\d+/" - Examples: - | lock-scope | - | shared | - | exclusive | - - - Scenario Outline: lockdiscovery file in a subfolder of a public link when the file is locked - Given user "Alice" has created a public link share of folder "PARENT" with change permission - And user "Alice" has locked folder "PARENT/CHILD/child.txt" setting the following properties - | lockscope | | - When the public gets the following properties of entry "/CHILD/child.txt" in the last created public link using the WebDAV API - | propertyName | - | d:lockdiscovery | - Then the HTTP status code should be "200" - And the value of the item "//d:lockroot/d:href" in the response should match "/%base_path%\/public.php\/webdav\/CHILD\/child.txt$/" - And the item "//d:locktoken/d:href" in the response should not exist - And the value of the item "//d:timeout" in the response should match "/Second-\d+/" - Examples: - | lock-scope | - | shared | - | exclusive | - - - Scenario Outline: lockdiscovery file in a subfolder of a public link when the folder above the public link is locked - Given user "Alice" has created a public link share of folder "PARENT/CHILD" with change permission - And user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - When the public gets the following properties of entry "/child.txt" in the last created public link using the WebDAV API - | propertyName | - | d:lockdiscovery | - Then the HTTP status code should be "200" - And the value of the item "//d:lockroot/d:href" in the response should match "/%base_path%\/public.php\/webdav\/$/" - And the item "//d:locktoken/d:href" in the response should not exist - And the value of the item "//d:timeout" in the response should match "/Second-\d+/" - Examples: - | lock-scope | - | shared | - | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavLocks/requestsWithToken.feature b/tests/acceptance/features/coreApiWebdavLocks/requestsWithToken.feature index 47d6de925cc..17e1d623e13 100644 --- a/tests/acceptance/features/coreApiWebdavLocks/requestsWithToken.feature +++ b/tests/acceptance/features/coreApiWebdavLocks/requestsWithToken.feature @@ -4,103 +4,6 @@ Feature: actions on a locked item are possible if the token is sent with the req Background: Given user "Alice" has been created with default attributes and without skeleton files - @smokeTest @notToImplementOnOCIS - Scenario Outline: rename a file in a locked folder - Given 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 locked folder "PARENT" setting the following properties - | lockscope | | - When user "Alice" moves file "/PARENT/parent.txt" to "/PARENT/renamed-file.txt" sending the locktoken of folder "PARENT" 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 | - - @smokeTest @notToImplementOnOCIS - Scenario Outline: move a file into a locked folder - Given using DAV path - And user "Alice" has created folder "FOLDER" - And user "Alice" has created folder "PARENT" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" - And user "Alice" has locked folder "FOLDER" setting the following properties - | lockscope | | - When user "Alice" moves file "/PARENT/parent.txt" to "/FOLDER/moved-file.txt" sending the locktoken of folder "FOLDER" 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 "/FOLDER/moved-file.txt" should exist - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - @smokeTest @notToImplementOnOCIS - Scenario Outline: move a file into a locked folder is impossible when using the wrong token - Given using DAV path - And user "Alice" has created folder "FOLDER" - And user "Alice" has created folder "PARENT" - And user "Alice" has created folder "PARENT/CHILD" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" - And user "Alice" has locked folder "FOLDER" setting the following properties - | lockscope | | - And user "Alice" has locked folder "PARENT/CHILD" setting the following properties - | lockscope | | - When user "Alice" moves file "/PARENT/parent.txt" to "/FOLDER/moved-file.txt" sending the locktoken of folder "PARENT/CHILD" using the WebDAV API - Then the HTTP status code should be "423" - And as "Alice" file "/PARENT/parent.txt" should exist - But as "Alice" file "/FOLDER/moved-file.txt" should not exist - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - @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" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/PARENT/parent.txt" - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has shared folder "/PARENT" with user "Brian" - And user "Brian" has accepted share "/PARENT" offered by user "Alice" - And user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - When user "Brian" moves file "Shares/PARENT/parent.txt" to "Shares/PARENT/renamed-file.txt" sending the locktoken of file "PARENT" of user "Alice" using the WebDAV API - Then the HTTP status code should be "423" - And as "Alice" file "/PARENT/parent.txt" should exist - But as "Alice" file "/PARENT/renamed-file.txt" should not exist - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - @files_sharing-app-required @notToImplementOnOCIS - Scenario Outline: public cannot overwrite a file in a folder locked by the owner even when sending the locktoken - Given user "Alice" has created folder "PARENT" - And user "Alice" has uploaded file with content "ownCloud test text file parent" to "PARENT/parent.txt" - And user "Alice" has created a public link share of folder "PARENT" with change permission - And user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - When the public uploads file "parent.txt" with content "test" sending the locktoken of file "PARENT" of user "Alice" using the public WebDAV API - Then the HTTP status code should be "" - And the content of file "/PARENT/parent.txt" for user "Alice" should be "ownCloud test text file parent" - Examples: - | lock-scope | webdav_api_version | http_status_code | - | shared | old | 423 | - | exclusive | old | 423 | - | shared | new | 423 | - | exclusive | new | 423 | - @files_sharing-app-required Scenario Outline: two users having both a shared lock can use the resource Given using DAV path diff --git a/tests/acceptance/features/coreApiWebdavLocks3/independentLocks.feature b/tests/acceptance/features/coreApiWebdavLocks2/independentLocks.feature similarity index 61% rename from tests/acceptance/features/coreApiWebdavLocks3/independentLocks.feature rename to tests/acceptance/features/coreApiWebdavLocks2/independentLocks.feature index 5766a1592c5..90ff09ab352 100644 --- a/tests/acceptance/features/coreApiWebdavLocks3/independentLocks.feature +++ b/tests/acceptance/features/coreApiWebdavLocks2/independentLocks.feature @@ -5,48 +5,6 @@ Feature: independent locks Background: Given user "Alice" has been created with default attributes and without skeleton files - @notToImplementOnOCIS - Scenario Outline: locking a folder does not lock other items with the same name in other parts of the file system - Given using DAV path - And user "Alice" has created folder "locked" - And user "Alice" has created folder "locked/PARENT" - And user "Alice" has created folder "notlocked" - And user "Alice" has created folder "notlocked/PARENT" - And user "Alice" has created folder "alsonotlocked" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/alsonotlocked/PARENT" - When user "Alice" locks folder "locked/PARENT" using the WebDAV API setting the following properties - | lockscope | | - Then the HTTP status code should be "200" - And user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/notlocked/PARENT/file.txt" - And user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/alsonotlocked/PARENT" - But user "Alice" should not be able to upload file "filesForUpload/lorem.txt" to "/locked/PARENT/textfile0.txt" - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - @notToImplementOnOCIS - Scenario Outline: locking a folder on the root level does not lock other folders with the same name in other parts of the file system - Given using DAV path - And user "Alice" has created folder "notlocked" - And user "Alice" has created folder "notlocked/PARENT" - And user "Alice" has created folder "alsonotlocked" - And user "Alice" has created folder "alsonotlocked/PARENT" - When user "Alice" locks folder "PARENT" using the WebDAV API setting the following properties - | lockscope | | - Then the HTTP status code should be "201" - And user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/notlocked/PARENT/file.txt" - And user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/alsonotlocked/PARENT/file.txt" - But user "Alice" should not be able to upload file "filesForUpload/lorem.txt" to "/PARENT/textfile0.txt" - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - Scenario Outline: locking a file does not lock other items with the same name in other parts of the file system Given using DAV path diff --git a/tests/acceptance/features/coreApiWebdavLocks3/independentLocksShareToShares.feature b/tests/acceptance/features/coreApiWebdavLocks2/independentLocksShareToShares.feature similarity index 58% rename from tests/acceptance/features/coreApiWebdavLocks3/independentLocksShareToShares.feature rename to tests/acceptance/features/coreApiWebdavLocks2/independentLocksShareToShares.feature index bff1b5077c1..10c4528e1dc 100644 --- a/tests/acceptance/features/coreApiWebdavLocks3/independentLocksShareToShares.feature +++ b/tests/acceptance/features/coreApiWebdavLocks2/independentLocksShareToShares.feature @@ -8,51 +8,6 @@ Feature: independent locks 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 - @notToImplementOnOCIS - Scenario Outline: locking a received share does not lock other shares that had the same name on the sharer side (shares from different users) - Given using DAV path - And user "Carol" has been created with default attributes and without skeleton files - And user "Alice" has created folder "toShare" - And user "Brian" has created folder "toShare" - And user "Alice" has shared folder "toShare" with user "Carol" - And user "Brian" has shared folder "toShare" with user "Carol" - And user "Carol" has accepted share "/toShare" offered by user "Alice" - And user "Carol" has accepted share "/toShare" offered by user "Brian" - When user "Carol" locks folder "/Shares/toShare" using the WebDAV API setting the following properties - | lockscope | | - Then the HTTP status code should be "200" - And user "Carol" should be able to upload file "filesForUpload/lorem.txt" to "/Shares/toShare (2)/file.txt" - But user "Carol" should not be able to upload file "filesForUpload/lorem.txt" to "/Shares/toShare/file.txt" - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - @notToImplementOnOCIS - Scenario Outline: locking a received share does not lock other shares that had the same name on the sharer side (shares from the same user) - Given using DAV path - And user "Alice" has created folder "locked/" - And user "Alice" has created folder "locked/toShare" - And user "Alice" has created folder "notlocked/" - And user "Alice" has created folder "notlocked/toShare" - And user "Alice" has shared folder "locked/toShare" with user "Brian" - And user "Alice" has shared folder "notlocked/toShare" with user "Brian" - And user "Brian" has accepted the first pending share "/toShare" offered by user "Alice" - And user "Brian" has accepted the next pending share "/toShare" offered by user "Alice" - When user "Brian" locks folder "/Shares/toShare" using the WebDAV API setting the following properties - | lockscope | | - Then the HTTP status code should be "200" - And user "Brian" should be able to upload file "filesForUpload/lorem.txt" to "/Shares/toShare (2)/file.txt" - But user "Brian" should not be able to upload file "filesForUpload/lorem.txt" to "/Shares/toShare/file.txt" - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - Scenario Outline: locking a file in a received share does not lock other items with the same name in other received shares (shares from different users) Given using DAV path diff --git a/tests/acceptance/features/coreApiWebdavLocks2/resharedSharesToRoot.feature b/tests/acceptance/features/coreApiWebdavLocks2/resharedSharesToRoot.feature deleted file mode 100644 index 1303b620ef3..00000000000 --- a/tests/acceptance/features/coreApiWebdavLocks2/resharedSharesToRoot.feature +++ /dev/null @@ -1,110 +0,0 @@ -@api @files_sharing-app-required @issue-ocis-reva-172 @issue-ocis-reva-11 @notToImplementOnOCIS -Feature: lock should propagate correctly if a share is reshared - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - | Carol | - And user "Alice" has created folder "PARENT" - And user "Brian" has created folder "PARENT" - And user "Carol" has created folder "PARENT" - - - Scenario Outline: upload to a share that was locked by owner - Given using DAV path - And user "Alice" has shared folder "PARENT" with user "Brian" - And user "Brian" has shared folder "PARENT (2)" with user "Carol" - And user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - When user "Carol" uploads file "filesForUpload/textfile.txt" to "/PARENT (2)/textfile.txt" using the WebDAV API - And user "Brian" uploads file "filesForUpload/textfile.txt" to "/PARENT (2)/textfile.txt" using the WebDAV API - And user "Alice" uploads file "filesForUpload/textfile.txt" to "/PARENT/textfile.txt" using the WebDAV API - Then the HTTP status code of responses on all endpoints should be "423" - And as "Alice" file "/PARENT/textfile.txt" should not exist - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: upload overwriting to a share that was locked by owner - Given using DAV path - And user "Alice" has uploaded file with content "ownCloud test text file parent" to "PARENT/parent.txt" - And user "Brian" has uploaded file with content "ownCloud test text file parent" to "PARENT/parent.txt" - And user "Carol" has uploaded file with content "ownCloud test text file parent" to "PARENT/parent.txt" - And user "Alice" has shared folder "PARENT" with user "Brian" - And user "Brian" has shared folder "PARENT (2)" with user "Carol" - And user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - When user "Carol" uploads file "filesForUpload/textfile.txt" to "/PARENT (2)/parent.txt" using the WebDAV API - And user "Brian" uploads file "filesForUpload/textfile.txt" to "/PARENT (2)/parent.txt" using the WebDAV API - And user "Alice" uploads file "filesForUpload/textfile.txt" to "/PARENT/parent.txt" using the WebDAV API - Then the HTTP status code of responses on all endpoints should be "423" - And the content of file "/PARENT/parent.txt" for user "Alice" should be "ownCloud test text file parent" - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: public uploads to a reshared share that was locked by original owner - Given using DAV path - And user "Alice" has shared folder "PARENT" with user "Brian" - And user "Brian" has shared folder "PARENT (2)" with user "Carol" - And user "Carol" has created a public link share of folder "PARENT (2)" with change permission - And user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - When the public uploads file "test.txt" with content "test" using the new public WebDAV API - Then the HTTP status code should be "423" - And as "Alice" file "/PARENT/test.txt" should not exist - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: upload to a share that was locked by owner but renamed before - Given using DAV path - And user "Alice" has shared folder "PARENT" with user "Brian" - And user "Brian" has shared folder "PARENT (2)" with user "Carol" - And user "Brian" has moved folder "/PARENT (2)" to "/PARENT-renamed" - And user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - When user "Carol" uploads file "filesForUpload/textfile.txt" to "/PARENT (2)/textfile.txt" using the WebDAV API - And user "Brian" uploads file "filesForUpload/textfile.txt" to "/PARENT-renamed/textfile.txt" using the WebDAV API - And user "Alice" uploads file "filesForUpload/textfile.txt" to "/PARENT/textfile.txt" using the WebDAV API - Then the HTTP status code of responses on all endpoints should be "423" - And as "Alice" file "/PARENT/textfile.txt" should not exist - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: upload to a share that was locked by the resharing user - Given using DAV path - And user "Alice" has shared folder "PARENT" with user "Brian" - And user "Brian" has shared folder "PARENT (2)" with user "Carol" - And user "Brian" has locked folder "PARENT (2)" setting the following properties - | lockscope | | - When user "Carol" uploads file "filesForUpload/textfile.txt" to "/PARENT (2)/textfile.txt" using the WebDAV API - And user "Brian" uploads file "filesForUpload/textfile.txt" to "/PARENT (2)/textfile.txt" using the WebDAV API - And user "Alice" uploads file "filesForUpload/textfile.txt" to "/PARENT/textfile.txt" using the WebDAV API - Then the HTTP status code of responses on all endpoints should be "423" - And as "Alice" file "/PARENT/textfile.txt" should not exist - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavLocks2/resharedSharesToShares.feature b/tests/acceptance/features/coreApiWebdavLocks2/resharedSharesToShares.feature deleted file mode 100644 index 32ee430b52d..00000000000 --- a/tests/acceptance/features/coreApiWebdavLocks2/resharedSharesToShares.feature +++ /dev/null @@ -1,122 +0,0 @@ -@api @files_sharing-app-required @issue-ocis-reva-172 @issue-ocis-reva-11 @notToImplementOnOCIS -Feature: lock should propagate correctly if a share is reshared - - 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 | - | Carol | - And user "Alice" has created folder "PARENT" - And user "Brian" has created folder "PARENT" - And user "Carol" has created folder "PARENT" - - - Scenario Outline: upload to a share that was locked by owner - Given using DAV path - And user "Alice" has shared folder "PARENT" with user "Brian" - And user "Brian" has accepted share "/PARENT" offered by user "Alice" - And user "Brian" has shared folder "Shares/PARENT" with user "Carol" - And user "Carol" has accepted share "/PARENT" offered by user "Brian" - And user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - When user "Carol" uploads file "filesForUpload/textfile.txt" to "/Shares/PARENT/textfile.txt" using the WebDAV API - And user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/PARENT/textfile.txt" using the WebDAV API - And user "Alice" uploads file "filesForUpload/textfile.txt" to "/PARENT/textfile.txt" using the WebDAV API - Then the HTTP status code of responses on all endpoints should be "423" - And as "Alice" file "/PARENT/textfile.txt" should not exist - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: upload overwriting to a share that was locked by owner - Given using DAV path - And user "Alice" has uploaded file with content "ownCloud test text file parent" to "PARENT/parent.txt" - And user "Brian" has uploaded file with content "ownCloud test text file parent" to "PARENT/parent.txt" - And user "Carol" has uploaded file with content "ownCloud test text file parent" to "PARENT/parent.txt" - And user "Alice" has shared folder "PARENT" with user "Brian" - And user "Brian" has accepted share "/PARENT" offered by user "Alice" - And user "Brian" has shared folder "Shares/PARENT" with user "Carol" - And user "Carol" has accepted share "/PARENT" offered by user "Brian" - And user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - When user "Carol" uploads file "filesForUpload/textfile.txt" to "/Shares/PARENT/parent.txt" using the WebDAV API - And user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/PARENT/parent.txt" using the WebDAV API - And user "Alice" uploads file "filesForUpload/textfile.txt" to "/PARENT/parent.txt" using the WebDAV API - Then the HTTP status code of responses on all endpoints should be "423" - And the content of file "/PARENT/parent.txt" for user "Alice" should be "ownCloud test text file parent" - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: public uploads to a reshared share that was locked by original owner - Given using DAV path - And user "Alice" has shared folder "PARENT" with user "Brian" - And user "Brian" has accepted share "/PARENT" offered by user "Alice" - And user "Brian" has shared folder "Shares/PARENT" with user "Carol" - And user "Carol" has accepted share "/PARENT" offered by user "Brian" - And user "Carol" has created a public link share of folder "Shares/PARENT" with change permission - And user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - When the public uploads file "test.txt" with content "test" using the new public WebDAV API - Then the HTTP status code should be "423" - And as "Alice" file "/PARENT/test.txt" should not exist - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: upload to a share that was locked by owner but renamed before - Given using DAV path - And user "Alice" has shared folder "PARENT" with user "Brian" - And user "Brian" has accepted share "/PARENT" offered by user "Alice" - And user "Brian" has shared folder "Shares/PARENT" with user "Carol" - And user "Carol" has accepted share "/PARENT" offered by user "Brian" - And user "Brian" has moved folder "/Shares/PARENT" to "/PARENT-renamed" - And user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - When user "Carol" uploads file "filesForUpload/textfile.txt" to "/Shares/PARENT/textfile.txt" using the WebDAV API - And user "Brian" uploads file "filesForUpload/textfile.txt" to "/PARENT-renamed/textfile.txt" using the WebDAV API - And user "Alice" uploads file "filesForUpload/textfile.txt" to "/PARENT/textfile.txt" using the WebDAV API - Then the HTTP status code of responses on all endpoints should be "423" - And as "Alice" file "/PARENT/textfile.txt" should not exist - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: upload to a share that was locked by the resharing user - Given using DAV path - And user "Alice" has shared folder "PARENT" with user "Brian" - And user "Brian" has accepted share "/PARENT" offered by user "Alice" - And user "Brian" has shared folder "Shares/PARENT" with user "Carol" - And user "Carol" has accepted share "/PARENT" offered by user "Brian" - And user "Brian" has locked folder "Shares/PARENT" setting the following properties - | lockscope | | - When user "Carol" uploads file "filesForUpload/textfile.txt" to "/Shares/PARENT/textfile.txt" using the WebDAV API - And user "Brian" uploads file "filesForUpload/textfile.txt" to "/Shares/PARENT/textfile.txt" using the WebDAV API - And user "Alice" uploads file "filesForUpload/textfile.txt" to "/PARENT/textfile.txt" using the WebDAV API - Then the HTTP status code of responses on all endpoints should be "423" - And as "Alice" file "/PARENT/textfile.txt" should not exist - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavLocks2/setTimeout.feature b/tests/acceptance/features/coreApiWebdavLocks2/setTimeout.feature deleted file mode 100644 index b0c09f773ad..00000000000 --- a/tests/acceptance/features/coreApiWebdavLocks2/setTimeout.feature +++ /dev/null @@ -1,126 +0,0 @@ -@api @smokeTest @public_link_share-feature-required @issue-ocis-reva-172 @notToImplementOnOCIS -Feature: set timeouts of LOCKS - - Background: - 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/parent.txt" - - - Scenario Outline: do not set timeout on folder and check the default timeout - Given using DAV path - And parameter "lock_timeout_default" of app "core" has been set to "" - And parameter "lock_timeout_max" of app "core" has been set to "" - When user "Alice" locks folder "PARENT" using the WebDAV API setting the following properties - | lockscope | exclusive | - Then the HTTP status code should be "200" - And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT" should match "" - And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/CHILD" should match "" - And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/parent.txt" should match "" - # consider a drift of up to 9 seconds between setting the lock and retrieving it - Examples: - | dav-path | default-timeout | max-timeout | result | - | old | 120 | 3600 | /Second-(120\|11[1-9])$/ | - | old | 99999 | 3600 | /Second-(3600\|359[1-9])$/ | - | new | 120 | 3600 | /Second-(120\|11[1-9])$/ | - | new | 99999 | 3600 | /Second-(3600\|359[1-9])$/ | - - @personalSpace @skipOnOcV10 - Examples: - | dav-path | default-timeout | max-timeout | result | - | spaces | 120 | 3600 | /Second-(120\|11[1-9])$/ | - | spaces | 99999 | 3600 | /Second-(3600\|359[1-9])$/ | - - - Scenario Outline: set timeout on folder - Given using DAV path - When user "Alice" locks folder "PARENT" using the WebDAV API setting the following properties - | lockscope | shared | - | timeout | | - Then the HTTP status code should be "200" - And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT" should match "" - And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/CHILD" should match "" - And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/parent.txt" should match "" - Examples: - | dav-path | timeout | result | - | old | second-999 | /Second-\d{3}$/ | - | old | second-99999999 | /Second-\d{5}$/ | - | old | infinite | /Second-\d{5}$/ | - | old | second--1 | /Second-\d{5}$/ | - | old | second-0 | /Second-\d{4}$/ | - | new | second-999 | /Second-\d{3}$/ | - | new | second-99999999 | /Second-\d{5}$/ | - | new | infinite | /Second-\d{5}$/ | - | new | second--1 | /Second-\d{5}$/ | - | new | second-0 | /Second-\d{4}$/ | - - @personalSpace @skipOnOcV10 - Examples: - | dav-path | timeout | result | - | spaces | second-999 | /Second-\d{3}$/ | - | spaces | second-99999999 | /Second-\d{5}$/ | - | spaces | infinite | /Second-\d{5}$/ | - | spaces | second--1 | /Second-\d{5}$/ | - | spaces | second-0 | /Second-\d{4}$/ | - - - Scenario Outline: set timeout over the maximum on folder - Given using DAV path - And parameter "lock_timeout_default" of app "core" has been set to "" - And parameter "lock_timeout_max" of app "core" has been set to "" - When user "Alice" locks folder "PARENT" using the WebDAV API setting the following properties - | lockscope | shared | - | timeout | | - Then the HTTP status code should be "200" - And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT" should match "" - And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/CHILD" should match "" - And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/parent.txt" should match "" - Examples: - | dav-path | timeout | default-timeout | max-timeout | result | - | old | second-600 | 120 | 3600 | /Second-(600\|59[1-9])$/ | - | old | second-600 | 99999 | 3600 | /Second-(600\|59[1-9])$/ | - | old | second-10000 | 120 | 3600 | /Second-(3600\|359[1-9])$/ | - | old | second-10000 | 99999 | 3600 | /Second-(3600\|359[1-9])$/ | - | old | infinite | 120 | 3600 | /Second-(3600\|359[1-9])$/ | - | old | infinite | 99999 | 3600 | /Second-(3600\|359[1-9])$/ | - | new | second-600 | 120 | 3600 | /Second-(600\|59[1-9])$/ | - | new | second-600 | 99999 | 3600 | /Second-(600\|59[1-9])$/ | - | new | second-10000 | 120 | 3600 | /Second-(3600\|359[1-9])$/ | - | new | second-10000 | 99999 | 3600 | /Second-(3600\|359[1-9])$/ | - | new | infinite | 120 | 3600 | /Second-(3600\|359[1-9])$/ | - | new | infinite | 99999 | 3600 | /Second-(3600\|359[1-9])$/ | - - @personalSpace @skipOnOcV10 - Examples: - | dav-path | timeout | default-timeout | max-timeout | result | - | spaces | second-600 | 120 | 3600 | /Second-(600\|59[1-9])$/ | - | spaces | second-600 | 99999 | 3600 | /Second-(600\|59[1-9])$/ | - | spaces | second-10000 | 120 | 3600 | /Second-(3600\|359[1-9])$/ | - | spaces | second-10000 | 99999 | 3600 | /Second-(3600\|359[1-9])$/ | - | spaces | infinite | 120 | 3600 | /Second-(3600\|359[1-9])$/ | - | spaces | infinite | 99999 | 3600 | /Second-(3600\|359[1-9])$/ | - - @files_sharing-app-required - Scenario Outline: as owner set timeout on folder as public check it - Given using DAV path - And user "Alice" has created a public link share of folder "PARENT" - When user "Alice" locks folder "PARENT" using the WebDAV API setting the following properties - | lockscope | shared | - | timeout | | - Then the HTTP status code should be "200" - And as a public the lock discovery property "//d:timeout" of the folder "/" should match "" - And as a public the lock discovery property "//d:timeout" of the folder "/CHILD" should match "" - And as a public the lock discovery property "//d:timeout" of the folder "/parent.txt" should match "" - Examples: - | dav-path | timeout | result | - | old | second-999 | /Second-\d{3}$/ | - | old | second-99999999 | /Second-\d{5}$/ | - | old | infinite | /Second-\d{5}$/ | - | old | second--1 | /Second-\d{5}$/ | - | old | second-0 | /Second-\d{4}$/ | - | new | second-999 | /Second-\d{3}$/ | - | new | second-99999999 | /Second-\d{5}$/ | - | new | infinite | /Second-\d{5}$/ | - | new | second--1 | /Second-\d{5}$/ | - | new | second-0 | /Second-\d{4}$/ | diff --git a/tests/acceptance/features/coreApiWebdavLocks2/setTimeoutSharesToRoot.feature b/tests/acceptance/features/coreApiWebdavLocks2/setTimeoutSharesToRoot.feature deleted file mode 100644 index 81b9602b4a2..00000000000 --- a/tests/acceptance/features/coreApiWebdavLocks2/setTimeoutSharesToRoot.feature +++ /dev/null @@ -1,62 +0,0 @@ -@api @smokeTest @public_link_share-feature-required @files_sharing-app-required @issue-ocis-reva-172 @notToImplementOnOCIS -Feature: set timeouts of LOCKS on shares - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - And user "Alice" has created folder "PARENT" - And user "Alice" has created folder "PARENT/CHILD" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" - And user "Brian" has created folder "PARENT" - And user "Brian" has created folder "PARENT/CHILD" - And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" - - - Scenario Outline: as owner set timeout on folder as receiver check it - Given using DAV path - And user "Alice" has shared folder "PARENT" with user "Brian" - When user "Alice" locks folder "PARENT" using the WebDAV API setting the following properties - | lockscope | shared | - | timeout | | - Then the HTTP status code should be "200" - And as user "Brian" the lock discovery property "//d:timeout" of the folder "PARENT (2)" should match "" - And as user "Brian" the lock discovery property "//d:timeout" of the folder "PARENT (2)/CHILD" should match "" - And as user "Brian" the lock discovery property "//d:timeout" of the folder "PARENT (2)/parent.txt" should match "" - Examples: - | dav-path | timeout | result | - | old | second-999 | /Second-\d{3}$/ | - | old | second-99999999 | /Second-\d{5}$/ | - | old | infinite | /Second-\d{5}$/ | - | old | second--1 | /Second-\d{5}$/ | - | old | second-0 | /Second-\d{4}$/ | - | new | second-999 | /Second-\d{3}$/ | - | new | second-99999999 | /Second-\d{5}$/ | - | new | infinite | /Second-\d{5}$/ | - | new | second--1 | /Second-\d{5}$/ | - | new | second-0 | /Second-\d{4}$/ | - - - Scenario Outline: as share receiver set timeout on folder as owner check it - Given using DAV path - And user "Alice" has shared folder "PARENT" with user "Brian" - When user "Brian" locks folder "PARENT (2)" using the WebDAV API setting the following properties - | lockscope | shared | - | timeout | | - Then the HTTP status code should be "200" - And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT" should match "" - And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/CHILD" should match "" - And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/parent.txt" should match "" - Examples: - | dav-path | timeout | result | - | old | second-999 | /Second-\d{3}$/ | - | old | second-99999999 | /Second-\d{5}$/ | - | old | infinite | /Second-\d{5}$/ | - | old | second--1 | /Second-\d{5}$/ | - | old | second-0 | /Second-\d{4}$/ | - | new | second-999 | /Second-\d{3}$/ | - | new | second-99999999 | /Second-\d{5}$/ | - | new | infinite | /Second-\d{5}$/ | - | new | second--1 | /Second-\d{5}$/ | - | new | second-0 | /Second-\d{4}$/ | diff --git a/tests/acceptance/features/coreApiWebdavLocks2/setTimeoutSharesToShares.feature b/tests/acceptance/features/coreApiWebdavLocks2/setTimeoutSharesToShares.feature deleted file mode 100644 index 34ca92e8ee6..00000000000 --- a/tests/acceptance/features/coreApiWebdavLocks2/setTimeoutSharesToShares.feature +++ /dev/null @@ -1,66 +0,0 @@ -@api @smokeTest @public_link_share-feature-required @files_sharing-app-required @issue-ocis-reva-172 @notToImplementOnOCIS -Feature: set timeouts of LOCKS on shares - - 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 created folder "PARENT" - And user "Alice" has created folder "PARENT/CHILD" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" - And user "Brian" has created folder "PARENT" - And user "Brian" has created folder "PARENT/CHILD" - And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" - - - Scenario Outline: as owner set timeout on folder as receiver check it - Given using DAV path - And user "Alice" has shared folder "PARENT" with user "Brian" - And user "Brian" has accepted share "/PARENT" offered by user "Alice" - When user "Alice" locks folder "PARENT" using the WebDAV API setting the following properties - | lockscope | shared | - | timeout | | - Then the HTTP status code should be "200" - And as user "Brian" the lock discovery property "//d:timeout" of the folder "Shares/PARENT" should match "" - And as user "Brian" the lock discovery property "//d:timeout" of the folder "Shares/PARENT/CHILD" should match "" - And as user "Brian" the lock discovery property "//d:timeout" of the folder "Shares/PARENT/parent.txt" should match "" - Examples: - | dav-path | timeout | result | - | old | second-999 | /Second-\d{3}$/ | - | old | second-99999999 | /Second-\d{5}$/ | - | old | infinite | /Second-\d{5}$/ | - | old | second--1 | /Second-\d{5}$/ | - | old | second-0 | /Second-\d{4}$/ | - | new | second-999 | /Second-\d{3}$/ | - | new | second-99999999 | /Second-\d{5}$/ | - | new | infinite | /Second-\d{5}$/ | - | new | second--1 | /Second-\d{5}$/ | - | new | second-0 | /Second-\d{4}$/ | - - - Scenario Outline: as share receiver set timeout on folder as owner check it - Given using DAV path - And user "Alice" has shared folder "PARENT" with user "Brian" - And user "Brian" has accepted share "/PARENT" offered by user "Alice" - When user "Brian" locks folder "Shares/PARENT" using the WebDAV API setting the following properties - | lockscope | shared | - | timeout | | - Then the HTTP status code should be "200" - And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT" should match "" - And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/CHILD" should match "" - And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/parent.txt" should match "" - Examples: - | dav-path | timeout | result | - | old | second-999 | /Second-\d{3}$/ | - | old | second-99999999 | /Second-\d{5}$/ | - | old | infinite | /Second-\d{5}$/ | - | old | second--1 | /Second-\d{5}$/ | - | old | second-0 | /Second-\d{4}$/ | - | new | second-999 | /Second-\d{3}$/ | - | new | second-99999999 | /Second-\d{5}$/ | - | new | infinite | /Second-\d{5}$/ | - | new | second--1 | /Second-\d{5}$/ | - | new | second-0 | /Second-\d{4}$/ | diff --git a/tests/acceptance/features/coreApiWebdavLocks3/independentLocksShareToRoot.feature b/tests/acceptance/features/coreApiWebdavLocks3/independentLocksShareToRoot.feature deleted file mode 100644 index 4e492f6a30b..00000000000 --- a/tests/acceptance/features/coreApiWebdavLocks3/independentLocksShareToRoot.feature +++ /dev/null @@ -1,91 +0,0 @@ -@api @issue-ocis-reva-172 @notToImplementOnOCIS -Feature: independent locks - Make sure all locks are independent and don't interact with other items that have the same name - - Background: - Given 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 - - - Scenario Outline: locking a received share does not lock other shares that had the same name on the sharer side (shares from different users) - Given using DAV path - And user "Carol" has been created with default attributes and without skeleton files - And user "Alice" has created folder "toShare" - And user "Brian" has created folder "toShare" - And user "Alice" has shared folder "toShare" with user "Carol" - And user "Brian" has shared folder "toShare" with user "Carol" - When user "Carol" locks folder "/toShare" using the WebDAV API setting the following properties - | lockscope | | - Then the HTTP status code should be "200" - And user "Carol" should be able to upload file "filesForUpload/lorem.txt" to "/toShare (2)/file.txt" - But user "Carol" should not be able to upload file "filesForUpload/lorem.txt" to "/toShare/file.txt" - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: locking a received share does not lock other shares that had the same name on the sharer side (shares from the same user) - Given using DAV path - And user "Alice" has created folder "locked/" - And user "Alice" has created folder "locked/toShare" - And user "Alice" has created folder "notlocked/" - And user "Alice" has created folder "notlocked/toShare" - And user "Alice" has shared folder "locked/toShare" with user "Brian" - And user "Alice" has shared folder "notlocked/toShare" with user "Brian" - When user "Brian" locks folder "/toShare" using the WebDAV API setting the following properties - | lockscope | | - Then the HTTP status code should be "200" - And user "Brian" should be able to upload file "filesForUpload/lorem.txt" to "/toShare (2)/file.txt" - But user "Brian" should not be able to upload file "filesForUpload/lorem.txt" to "/toShare/file.txt" - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: locking a file in a received share does not lock other items with the same name in other received shares (shares from different users) - Given using DAV path - And user "Carol" has been created with default attributes and without skeleton files - And user "Alice" has created folder "FromAlice" - And user "Brian" has created folder "FromBrian" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/FromAlice/textfile0.txt" - And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/FromBrian/textfile0.txt" - And user "Alice" has shared folder "FromAlice" with user "Carol" - And user "Brian" has shared folder "FromBrian" with user "Carol" - When user "Carol" locks file "/FromBrian/textfile0.txt" using the WebDAV API setting the following properties - | lockscope | | - Then the HTTP status code should be "200" - And user "Carol" should be able to upload file "filesForUpload/lorem.txt" to "/FromAlice/textfile0.txt" - But user "Carol" should not be able to upload file "filesForUpload/lorem.txt" to "/FromBrian/textfile0.txt" - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: locking a file in a received share does not lock other items with the same name in other received shares (shares from same user) - Given using DAV path - And user "Alice" has created folder "locked/" - And user "Alice" has created folder "notlocked/" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "locked/textfile0.txt" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "notlocked/textfile0.txt" - And user "Alice" has shared folder "locked" with user "Brian" - And user "Alice" has shared folder "notlocked" with user "Brian" - When user "Brian" locks file "/locked/textfile0.txt" using the WebDAV API setting the following properties - | lockscope | | - Then the HTTP status code should be "200" - And user "Brian" should be able to upload file "filesForUpload/lorem.txt" to "/notlocked/textfile0.txt" - But user "Brian" should not be able to upload file "filesForUpload/lorem.txt" to "/locked/textfile0.txt" - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavLocksUnlock/lockBreakersGroups.feature b/tests/acceptance/features/coreApiWebdavLocksUnlock/lockBreakersGroups.feature deleted file mode 100644 index 19d23ab32a6..00000000000 --- a/tests/acceptance/features/coreApiWebdavLocksUnlock/lockBreakersGroups.feature +++ /dev/null @@ -1,310 +0,0 @@ -@api @issue-ocis-2413 @notToImplementOnOCIS -Feature: UNLOCK locked items - - Background: - Given user "Alice" has been created with default attributes and without skeleton files - - - Scenario Outline: a group can be added as a lock breaker group - Given using DAV path - And group "grp1" has been created - When the administrator sets parameter "lock-breaker-groups" of app "core" to '["grp1"]' - Then the HTTP status code should be "200" - And group "grp1" should exist as a lock breaker group - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: more than one group can be added as a lock breaker group - Given using DAV path - And group "grp1" has been created - And group "grp2" has been created - When the administrator sets parameter "lock-breaker-groups" of app "core" to '["grp1","grp2"]' - Then the HTTP status code should be "200" - And following groups should exist as lock breaker groups - | groups | - | grp1 | - | grp2 | - Examples: - | dav-path | - | old | - | new | - - - Scenario Outline: member of the lock breakers group can unlock a locked folder shared with them - Given using DAV path - And group "grp1" has been created - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created folder "FOLDER" - And parameter "lock-breaker-groups" of app "core" has been set to '["grp1"]' - And user "Brian" has been added to group "grp1" - And user "Alice" has locked folder "FOLDER" setting the following properties - | lockscope | | - And user "Alice" has shared folder "FOLDER" with user "Brian" - When user "Brian" unlocks folder "FOLDER" with the last created lock of folder "FOLDER" of user "Alice" using the WebDAV API - Then the HTTP status code should be "204" - And 0 locks should be reported for folder "FOLDER" of user "Brian" by the WebDAV API - And 0 locks should be reported for folder "FOLDER" of user "Alice" by the WebDAV API - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: members of the lock breakers group can lock shared folder that was unlocked by the lock breaker group before - Given using DAV path - And group "grp1" has been created - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has created folder "FOLDER" - And parameter "lock-breaker-groups" of app "core" has been set to '["grp1"]' - And user "Brian" has been added to group "grp1" - And user "Alice" has locked folder "FOLDER" setting the following properties - | lockscope | | - And user "Alice" has shared folder "FOLDER" with user "Brian" - And user "Brian" has unlocked folder "FOLDER" with the last created lock of folder "FOLDER" of user "Alice" using the WebDAV API - When user "Brian" locks folder "FOLDER" using the WebDAV API setting the following properties - | lockscope | | - Then the HTTP status code should be "200" - And 1 locks should be reported for folder "FOLDER" of user "Brian" by the WebDAV API - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: members of the lock breakers group can unlock a locked file shared with them - Given using DAV path - And group "grp1" has been created - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" - And parameter "lock-breaker-groups" of app "core" has been set to '["grp1"]' - And user "Brian" has been added to group "grp1" - And user "Alice" has locked file "textfile0.txt" setting the following properties - | lockscope | | - And user "Alice" has shared file "textfile0.txt" with user "Brian" - When user "Brian" unlocks file "textfile0.txt" with the last created lock of file "textfile0.txt" of user "Alice" using the WebDAV API - Then the HTTP status code should be "204" - And 0 locks should be reported for file "textfile0.txt" of user "Brian" by the WebDAV API - And 0 locks should be reported for file "textfile0.txt" of user "Alice" by the WebDAV API - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: members of the lock breakers group can lock shared file that was unlocked by the lock breaker group before - Given using DAV path - And group "grp1" has been created - And user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" - And parameter "lock-breaker-groups" of app "core" has been set to '["grp1"]' - And user "Brian" has been added to group "grp1" - And user "Alice" has locked file "textfile0.txt" setting the following properties - | lockscope | | - And user "Alice" has shared file "textfile0.txt" with user "Brian" - And user "Brian" has unlocked file "textfile0.txt" with the last created lock of folder "textfile0.txt" of user "Alice" using the WebDAV API - When user "Brian" locks file "textfile0.txt" using the WebDAV API setting the following properties - | lockscope | | - Then the HTTP status code should be "200" - And 1 locks should be reported for file "textfile0.txt" of user "Brian" by the WebDAV API - And 1 locks should be reported for file "textfile0.txt" of user "Alice" by the WebDAV API - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: as a member of lock breaker group unlocking a file in a share locked by the file owner is possible - Given using DAV path - And group "grp1" has been created - And user "Brian" has been created with default attributes and without skeleton files - And parameter "lock-breaker-groups" of app "core" has been set to '["grp1"]' - And user "Brian" has been added to group "grp1" - And user "Alice" has created folder "PARENT" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" - And user "Alice" has locked file "PARENT/parent.txt" setting the following properties - | lockscope | | - And user "Alice" has shared folder "PARENT" with user "Brian" - When user "Brian" unlocks file "PARENT/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 "204" - And 0 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API - And 0 locks should be reported for file "PARENT/parent.txt" of user "Brian" by the WebDAV API - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: as a member of lock breaker group unlocking a folder in a share locked by the folder owner is possible - Given using DAV path - And group "grp1" has been created - And user "Brian" has been created with default attributes and without skeleton files - And parameter "lock-breaker-groups" of app "core" has been set to '["grp1"]' - And user "Brian" has been added to group "grp1" - And user "Alice" has created folder "PARENT" - And user "Alice" has created folder "CHILD" - And user "Alice" has locked folder "PARENT/CHILD" setting the following properties - | lockscope | | - And user "Alice" has shared folder "PARENT" with user "Brian" - When user "Brian" unlocks folder "PARENT/CHILD" with the last created lock of folder "PARENT/CHILD" of user "Alice" using the WebDAV API - Then the HTTP status code should be "204" - And 0 locks should be reported for folder "PARENT/CHILD" of user "Alice" by the WebDAV API - And 0 locks should be reported for folder "PARENT/CHILD" of user "Brian" by the WebDAV API - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: members of different lock breaker groups can lock and unlock same folder shared to them - Given using DAV path - And group "grp1" has been created - And group "grp2" has been created - And user "Brian" has been created with default attributes and without skeleton files - And user "Carol" has been created with default attributes and without skeleton files - And parameter "lock-breaker-groups" of app "core" has been set to '["grp1","grp2"]' - And user "Carol" has been added to group "grp2" - And user "Brian" has been added to group "grp1" - And user "Alice" has created folder "PARENT" - And user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - And user "Alice" has shared folder "PARENT" with user "Brian" - And user "Alice" has shared folder "PARENT" with user "Carol" - When user "Brian" unlocks folder "PARENT" with the last created lock of file "PARENT" of user "Alice" using the WebDAV API - Then the HTTP status code should be "204" - And 0 locks should be reported for folder "PARENT" of user "Alice" by the WebDAV API - And 0 locks should be reported for folder "PARENT" of user "Brian" by the WebDAV API - And 0 locks should be reported for folder "PARENT" of user "Carol" by the WebDAV API - When user "Brian" locks folder "PARENT" using the WebDAV API setting the following properties - | lockscope | | - And 1 locks should be reported for folder "PARENT" of user "Alice" by the WebDAV API - And 1 locks should be reported for folder "PARENT" of user "Brian" by the WebDAV API - And 1 locks should be reported for folder "PARENT" of user "Carol" by the WebDAV API - Then the HTTP status code should be "200" - When user "Carol" unlocks folder "PARENT" with the last created lock of folder "PARENT" of user "Brian" using the WebDAV API - Then the HTTP status code should be "204" - And 0 locks should be reported for folder "PARENT" of user "Alice" by the WebDAV API - And 0 locks should be reported for folder "PARENT" of user "Brian" by the WebDAV API - And 0 locks should be reported for folder "PARENT" of user "Carol" by the WebDAV API - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: members of different lock breaker groups can lock and unlock same file shared to them - Given using DAV path - And group "grp1" has been created - And group "grp2" has been created - And user "Brian" has been created with default attributes and without skeleton files - And user "Carol" has been created with default attributes and without skeleton files - And parameter "lock-breaker-groups" of app "core" has been set to '["grp1","grp2"]' - And user "Carol" has been added to group "grp2" - And user "Brian" has been added to group "grp1" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" - And user "Alice" has locked file "textfile.txt" setting the following properties - | lockscope | | - And user "Alice" has shared file "textfile.txt" with user "Brian" - And user "Alice" has shared file "textfile.txt" with user "Carol" - When user "Brian" unlocks file "textfile.txt" with the last created lock of file "textfile.txt" of user "Alice" using the WebDAV API - Then the HTTP status code should be "204" - And 0 locks should be reported for file "textfile.txt" of user "Alice" by the WebDAV API - And 0 locks should be reported for file "textfile.txt" of user "Brian" by the WebDAV API - And 0 locks should be reported for file "textfile.txt" of user "Carol" by the WebDAV API - When user "Brian" locks file "textfile.txt" using the WebDAV API setting the following properties - | lockscope | | - And 1 locks should be reported for file "textfile.txt" of user "Alice" by the WebDAV API - And 1 locks should be reported for file "textfile.txt" of user "Brian" by the WebDAV API - And 1 locks should be reported for file "textfile.txt" of user "Carol" by the WebDAV API - Then the HTTP status code should be "200" - When user "Carol" unlocks file "textfile.txt" with the last created lock of file "textfile.txt" of user "Brian" using the WebDAV API - Then the HTTP status code should be "204" - And 0 locks should be reported for file "textfile.txt" of user "Alice" by the WebDAV API - And 0 locks should be reported for file "textfile.txt" of user "Brian" by the WebDAV API - And 0 locks should be reported for file "textfile.txt" of user "Carol" by the WebDAV API - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: members of lock breaker group can unlock a folder in group sharing - Given using DAV path - And group "grp1" has been created - And group "grp2" has been created - And user "Brian" has been created with default attributes and without skeleton files - And user "Carol" has been created with default attributes and without skeleton files - And parameter "lock-breaker-groups" of app "core" has been set to '["grp1"]' - And user "Carol" has been added to group "grp2" - And user "Brian" has been added to group "grp1" - And user "Brian" has been added to group "grp2" - And user "Alice" has created folder "PARENT" - And user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - And user "Alice" has shared folder "PARENT" with group "grp2" - When user "Carol" unlocks folder "PARENT" with the last created lock of folder "PARENT" of user "Alice" using the WebDAV API - Then the HTTP status code should be "403" - And 1 locks should be reported for folder "PARENT" of user "Alice" by the WebDAV API - And 1 locks should be reported for folder "PARENT" of user "Brian" by the WebDAV API - And 1 locks should be reported for folder "PARENT" of user "Carol" by the WebDAV API - When user "Brian" unlocks folder "PARENT" with the last created lock of file "PARENT" of user "Alice" using the WebDAV API - Then the HTTP status code should be "204" - And 0 locks should be reported for folder "PARENT" of user "Alice" by the WebDAV API - And 0 locks should be reported for folder "PARENT" of user "Brian" by the WebDAV API - And 0 locks should be reported for folder "PARENT" of user "Carol" by the WebDAV API - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: members of lock breaker group can unlock a file in group sharing - Given using DAV path - And group "grp1" has been created - And group "grp2" has been created - And user "Brian" has been created with default attributes and without skeleton files - And user "Carol" has been created with default attributes and without skeleton files - And parameter "lock-breaker-groups" of app "core" has been set to '["grp1"]' - And user "Carol" has been added to group "grp2" - And user "Brian" has been added to group "grp1" - And user "Brian" has been added to group "grp2" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" - And user "Alice" has locked file "textfile0.txt" setting the following properties - | lockscope | | - And user "Alice" has shared file "textfile0.txt" with group "grp2" - When user "Carol" unlocks file "textfile0.txt" with the last created lock of file "textfile0.txt" of user "Alice" using the WebDAV API - Then the HTTP status code should be "403" - And 1 locks should be reported for file "textfile0.txt" of user "Alice" by the WebDAV API - And 1 locks should be reported for file "textfile0.txt" of user "Brian" by the WebDAV API - And 1 locks should be reported for file "textfile0.txt" of user "Carol" by the WebDAV API - When user "Brian" unlocks file "textfile0.txt" with the last created lock of file "textfile0.txt" of user "Alice" using the WebDAV API - Then the HTTP status code should be "204" - And 0 locks should be reported for file "textfile0.txt" of user "Alice" by the WebDAV API - And 0 locks should be reported for file "textfile0.txt" of user "Brian" by the WebDAV API - And 0 locks should be reported for file "textfile0.txt" of user "Carol" by the WebDAV API - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavLocksUnlock/unlock.feature b/tests/acceptance/features/coreApiWebdavLocksUnlock/unlock.feature index cf45ac5ac98..7e8dc030621 100644 --- a/tests/acceptance/features/coreApiWebdavLocksUnlock/unlock.feature +++ b/tests/acceptance/features/coreApiWebdavLocksUnlock/unlock.feature @@ -4,26 +4,6 @@ Feature: UNLOCK locked items Background: Given user "Alice" has been created with default attributes and without skeleton files - @smokeTest @notToImplementOnOCIS - Scenario Outline: unlock a single lock set by the user itself - Given using DAV path - And user "Alice" has created folder "PARENT" - And user "Alice" has created folder "PARENT/CHILD" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" - And user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - When user "Alice" unlocks the last created lock of folder "PARENT" using the WebDAV API - Then the HTTP status code should be "204" - And 0 locks should be reported for folder "PARENT" of user "Alice" by the WebDAV API - And 0 locks should be reported for folder "PARENT/CHILD" of user "Alice" by the WebDAV API - And 0 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - Scenario Outline: unlock one of multiple locks set by the user itself Given using DAV path @@ -45,25 +25,6 @@ Feature: UNLOCK locked items | dav-path | | spaces | - @notToImplementOnOCIS - Scenario Outline: unlocking a file that was locked by the user locking the folder above is not possible - Given using DAV path - 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 user "Alice" has locked folder "PARENT/CHILD" setting the following properties - | lockscope | | - When user "Alice" unlocks file "PARENT/CHILD/child.txt" with the last created lock of folder "PARENT/CHILD" using the WebDAV API - Then the HTTP status code should be "204" - And 1 locks should be reported for file "PARENT/CHILD/child.txt" of user "Alice" by the WebDAV API - And 2 locks should be reported for folder "PARENT/CHILD" of user "Alice" by the WebDAV API - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - @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" @@ -79,33 +40,6 @@ Feature: UNLOCK locked items | shared | | exclusive | - @notToImplementOnOCIS - Scenario Outline: unlocking a file or folder does not unlock another folder with the same name in another part of the file system - Given using DAV path - And user "Alice" has created folder "locked" - And user "Alice" has created folder "locked/PARENT" - And user "Alice" has created folder "notlocked" - And user "Alice" has created folder "notlocked/PARENT" - And user "Alice" has created folder "alsonotlocked" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/alsonotlocked/PARENT" - And user "Alice" has locked folder "locked/PARENT" setting the following properties - | lockscope | | - And user "Alice" has locked folder "notlocked/PARENT" setting the following properties - | lockscope | | - And user "Alice" has locked file "alsonotlocked/PARENT" setting the following properties - | lockscope | | - When user "Alice" unlocks the last created lock of folder "notlocked/PARENT" using the WebDAV API - And user "Alice" unlocks the last created lock of file "alsonotlocked/PARENT" using the WebDAV API - Then user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/notlocked/PARENT/file.txt" - And user "Alice" should be able to upload file "filesForUpload/lorem.txt" to "/alsonotlocked/PARENT" - But user "Alice" should not be able to upload file "filesForUpload/lorem.txt" to "/locked/PARENT/textfile0.txt" - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - Scenario Outline: unlocking a file or folder does not unlock another file with the same name in another part of the file system Given using DAV path diff --git a/tests/acceptance/features/coreApiWebdavLocksUnlock/unlockSharingToRoot.feature b/tests/acceptance/features/coreApiWebdavLocksUnlock/unlockSharingToRoot.feature deleted file mode 100644 index f12440d25fc..00000000000 --- a/tests/acceptance/features/coreApiWebdavLocksUnlock/unlockSharingToRoot.feature +++ /dev/null @@ -1,143 +0,0 @@ -@api @issue-ocis-reva-172 @files_sharing-app-required @notToImplementOnOCIS -Feature: UNLOCK locked items (sharing) - - Background: - Given these users have been created with default attributes and without skeleton files: - | username | - | Alice | - | Brian | - And user "Alice" has created folder "PARENT" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" - - - Scenario Outline: as share receiver unlocking a shared file locked by the file owner is not possible. To unlock use the owners locktoken - Given using DAV path - And user "Alice" has locked file "PARENT/parent.txt" setting the following properties - | lockscope | | - And user "Alice" has shared file "PARENT/parent.txt" with user "Brian" - When user "Brian" 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 "403" - And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API - And 1 locks should be reported for file "parent.txt" of user "Brian" by the WebDAV API - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: as share receiver unlocking a file in a share locked by the file owner is not possible. To unlock use the owners locktoken - Given using DAV path - And user "Brian" has created folder "PARENT" - And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt" - And user "Alice" has locked file "PARENT/parent.txt" setting the following properties - | lockscope | | - And user "Alice" has shared folder "PARENT" with user "Brian" - When user "Brian" unlocks file "PARENT (2)/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 "403" - And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API - And 1 locks should be reported for file "PARENT (2)/parent.txt" of user "Brian" by the WebDAV API - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: as share receiver unlocking a shared folder locked by the file owner is not possible. To unlock use the owners locktoken - Given using DAV path - And user "Alice" has created folder "PARENT/CHILD" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/CHILD/child.txt" - And user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - And user "Alice" has shared folder "PARENT" with user "Brian" - When user "Brian" unlocks folder "PARENT" with the last created lock of folder "PARENT" of user "Alice" using the WebDAV API - Then the HTTP status code should be "403" - And 3 locks should be reported for folder "PARENT" of user "Alice" by the WebDAV API - And 2 locks should be reported for folder "PARENT/CHILD" of user "Alice" by the WebDAV API - And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API - And 3 locks should be reported for folder "PARENT" of user "Brian" by the WebDAV API - And 2 locks should be reported for folder "PARENT/CHILD" of user "Brian" by the WebDAV API - And 1 locks should be reported for file "PARENT/parent.txt" of user "Brian" by the WebDAV API - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: as share receiver unlock a shared file - Given using DAV path - And user "Alice" has shared file "PARENT/parent.txt" with user "Brian" - And user "Brian" has locked file "parent.txt" setting the following properties - | lockscope | | - When user "Brian" unlocks the last created lock of file "parent.txt" using the WebDAV API - Then the HTTP status code should be "204" - And 0 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API - And 0 locks should be reported for file "parent.txt" of user "Brian" by the WebDAV API - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: as owner unlocking a shared file locked by the receiver is not possible. To unlock use the receivers locktoken - Given using DAV path - And user "Alice" has shared file "PARENT/parent.txt" with user "Brian" - And user "Brian" has locked file "parent.txt" setting the following properties - | lockscope | | - When user "Alice" unlocks file "PARENT/parent.txt" with the last created lock of file "parent.txt" of user "Brian" using the WebDAV API - 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 - And 1 locks should be reported for file "parent.txt" of user "Brian" by the WebDAV API - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: as owner unlocking a file in a share that was locked by the share receiver is not possible. To unlock use the receivers locktoken - Given using DAV path - And user "Alice" has shared folder "PARENT" with user "Brian" - And user "Brian" has locked file "PARENT/parent.txt" setting the following properties - | lockscope | | - When user "Alice" unlocks file "PARENT/parent.txt" with the last created lock of file "PARENT/parent.txt" of user "Brian" using the WebDAV API - 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 - And 1 locks should be reported for file "PARENT/parent.txt" of user "Brian" by the WebDAV API - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - - - Scenario Outline: as owner unlocking a shared folder locked by the share receiver is not possible. To unlock use the receivers locktoken - Given using DAV path - And user "Alice" has created folder "PARENT/CHILD" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/CHILD/child.txt" - And user "Alice" has shared folder "PARENT" with user "Brian" - And user "Brian" has locked folder "PARENT" setting the following properties - | lockscope | | - When user "Alice" unlocks folder "PARENT" with the last created lock of folder "PARENT" of user "Brian" using the WebDAV API - Then the HTTP status code should be "403" - And 3 locks should be reported for folder "PARENT" of user "Alice" by the WebDAV API - And 2 locks should be reported for folder "PARENT/CHILD" of user "Alice" by the WebDAV API - And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API - And 3 locks should be reported for folder "PARENT" of user "Brian" by the WebDAV API - And 2 locks should be reported for folder "PARENT/CHILD" of user "Brian" by the WebDAV API - And 1 locks should be reported for file "PARENT/parent.txt" of user "Brian" by the WebDAV API - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavLocksUnlock/unlockSharingToShares.feature b/tests/acceptance/features/coreApiWebdavLocksUnlock/unlockSharingToShares.feature index 97d4507278d..6061083fb71 100644 --- a/tests/acceptance/features/coreApiWebdavLocksUnlock/unlockSharingToShares.feature +++ b/tests/acceptance/features/coreApiWebdavLocksUnlock/unlockSharingToShares.feature @@ -59,30 +59,6 @@ Feature: UNLOCK locked items (sharing) | spaces | shared | | spaces | exclusive | - @notToImplementOnOCIS - Scenario Outline: as share receiver unlocking a shared folder locked by the file owner is not possible. To unlock use the owners locktoken - Given using DAV path - And user "Alice" has created folder "PARENT/CHILD" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/CHILD/child.txt" - And user "Alice" has locked folder "PARENT" setting the following properties - | lockscope | | - And user "Alice" has shared folder "PARENT" with user "Brian" - And user "Brian" has accepted share "/PARENT" offered by user "Alice" - When user "Brian" unlocks folder "Shares/PARENT" with the last created lock of folder "PARENT" of user "Alice" using the WebDAV API - Then the HTTP status code should be "403" - And 3 locks should be reported for folder "PARENT" of user "Alice" by the WebDAV API - And 2 locks should be reported for folder "PARENT/CHILD" of user "Alice" by the WebDAV API - And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API - And 3 locks should be reported for folder "Shares/PARENT" of user "Brian" by the WebDAV API - And 2 locks should be reported for folder "Shares/PARENT/CHILD" of user "Brian" by the WebDAV API - And 1 locks should be reported for file "Shares/PARENT/parent.txt" of user "Brian" by the WebDAV API - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | - Scenario Outline: as share receiver unlock a shared file Given using DAV path @@ -154,27 +130,3 @@ Feature: UNLOCK locked items (sharing) | dav-path | lock-scope | | spaces | shared | | spaces | exclusive | - - @notToImplementOnOCIS - Scenario Outline: as owner unlocking a shared folder locked by the share receiver is not possible. To unlock use the receivers locktoken - Given using DAV path - And user "Alice" has created folder "PARENT/CHILD" - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/CHILD/child.txt" - And user "Alice" has shared folder "PARENT" with user "Brian" - And user "Brian" has accepted share "/PARENT" offered by user "Alice" - And user "Brian" has locked folder "Shares/PARENT" setting the following properties - | lockscope | | - When user "Alice" unlocks folder "PARENT" with the last created lock of folder "Shares/PARENT" of user "Brian" using the WebDAV API - Then the HTTP status code should be "403" - And 3 locks should be reported for folder "PARENT" of user "Alice" by the WebDAV API - And 2 locks should be reported for folder "PARENT/CHILD" of user "Alice" by the WebDAV API - And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API - And 3 locks should be reported for folder "Shares/PARENT" of user "Brian" by the WebDAV API - And 2 locks should be reported for folder "Shares/PARENT/CHILD" of user "Brian" by the WebDAV API - And 1 locks should be reported for file "Shares/PARENT/parent.txt" of user "Brian" by the WebDAV API - Examples: - | dav-path | lock-scope | - | old | shared | - | old | exclusive | - | new | shared | - | new | exclusive | diff --git a/tests/acceptance/features/coreApiWebdavMove1/moveFileAsync.feature b/tests/acceptance/features/coreApiWebdavMove1/moveFileAsync.feature deleted file mode 100644 index fa35764eafb..00000000000 --- a/tests/acceptance/features/coreApiWebdavMove1/moveFileAsync.feature +++ /dev/null @@ -1,278 +0,0 @@ -@api @issue-ocis-reva-14 @notToImplementOnOCIS -Feature: move (rename) file - As a user - I want to be able to move and rename files asynchronously - So that I can manage my file system - - Background: - Given using new DAV path - And 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" - And the administrator has enabled async operations - - - Scenario Outline: Moving a file - Given user "Alice" has created folder "FOLDER" - When user "Alice" moves file "/textfile0.txt" asynchronously to "/FOLDER/" using the WebDAV API - Then the HTTP status code should be "202" - And the following headers should match these regular expressions for user "Alice" - | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | - And the oc job status values of last request for user "Alice" should match these regular expressions - | status | /^finished$/ | - | fileId | /^[0-9a-z]{20,}$/ | - | ETag | /^"[0-9a-f]{1,32}"$/ | - And the content of file "/FOLDER/" for user "Alice" should be "ownCloud test text file 0" - And user "Alice" should not see the following elements - | /textfile0.txt | - Examples: - | destination-file-name | - | नेपाली.txt | - | strängé file.txt | - | C++ file.cpp | - | file #2.txt | - | file ?2.txt | - | sample,1.txt | - - - Scenario: Moving and overwriting a file - Given user "Alice" has uploaded file with content "Welcome to move" to "/fileToMove.txt" - When user "Alice" moves file "/fileToMove.txt" asynchronously to "/textfile0.txt" using the WebDAV API - Then the HTTP status code should be "202" - And the following headers should match these regular expressions for user "Alice" - | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | - And the oc job status values of last request for user "Alice" should match these regular expressions - | status | /^finished$/ | - | fileId | /^[0-9a-z]{20,}$/ | - | ETag | /^"[0-9a-f]{1,32}"$/ | - And the content of file "/textfile0.txt" for user "Alice" should be "Welcome to move" - And user "Alice" should not see the following elements - | /fileToMove.txt | - - - Scenario: Moving (renaming) a file to be only different case - When user "Alice" moves file "/textfile0.txt" asynchronously to "/TextFile0.txt" using the WebDAV API - Then the HTTP status code should be "202" - And the following headers should match these regular expressions for user "Alice" - | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | - And the oc job status values of last request for user "Alice" should match these regular expressions - | status | /^finished$/ | - | fileId | /^[0-9a-z]{20,}$/ | - | ETag | /^"[0-9a-f]{1,32}"$/ | - And the content of file "/TextFile0.txt" for user "Alice" should be "ownCloud test text file 0" - And user "Alice" should not see the following elements - | /textfile0.txt | - - - Scenario: Moving (renaming) a file to a file with only different case to an existing file - Given user "Alice" has uploaded file with content "ownCloud test text file 1" to "textfile1.txt" - When user "Alice" moves file "/textfile1.txt" asynchronously to "/TextFile0.txt" using the WebDAV API - Then the HTTP status code should be "202" - And the following headers should match these regular expressions for user "Alice" - | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | - And the oc job status values of last request for user "Alice" should match these regular expressions - | status | /^finished$/ | - | fileId | /^[0-9a-z]{20,}$/ | - | ETag | /^"[0-9a-f]{1,32}"$/ | - And the content of file "/textfile0.txt" for user "Alice" should be "ownCloud test text file 0" - And the content of file "/TextFile0.txt" for user "Alice" should be "ownCloud test text file 1" - And user "Alice" should not see the following elements - | /textfile1.txt | - - - Scenario: Moving (renaming) a file to a file in a folder with only different case to an existing file - Given user "Alice" has created folder "PARENT" - And user "Alice" has uploaded file with content "ownCloud test text file parent" to "PARENT/parent.txt" - When user "Alice" moves file "/textfile0.txt" asynchronously to "/PARENT/Parent.txt" using the WebDAV API - Then the HTTP status code should be "202" - And the following headers should match these regular expressions for user "Alice" - | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | - And the oc job status values of last request for user "Alice" should match these regular expressions - | status | /^finished$/ | - | fileId | /^[0-9a-z]{20,}$/ | - | ETag | /^"[0-9a-f]{1,32}"$/ | - And the content of file "/PARENT/parent.txt" for user "Alice" should be "ownCloud test text file parent" - And the content of file "/PARENT/Parent.txt" for user "Alice" should be "ownCloud test text file 0" - And user "Alice" should not see the following elements - | /textfile0.txt | - - @files_sharing-app-required - Scenario: Moving a file to a folder with no permissions - Given 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 | read | - | shareWith | Alice | - When user "Alice" moves file "/textfile0.txt" asynchronously to "/testshare/textfile0.txt" using the WebDAV API - Then the HTTP status code should be "202" - And the oc job status values of last request for user "Alice" should match these regular expressions - | status | /^error$/ | - | errorCode | /^403$/ | - And user "Alice" downloads file "/testshare/textfile0.txt" using the WebDAV API - And the HTTP status code should be "404" - And user "Alice" should see the following elements - | /textfile0.txt | - - @files_sharing-app-required - Scenario: Moving a file to overwrite a file in a folder with no permissions - Given 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 "Welcome to overwrite" to "/fileToCopy.txt" - And user "Brian" has created a share with settings - | path | testshare | - | shareType | user | - | permissions | read | - | shareWith | Alice | - And user "Brian" has copied file "/fileToCopy.txt" to "/testshare/overwritethis.txt" - When user "Alice" moves file "/textfile0.txt" asynchronously to "/testshare/overwritethis.txt" using the WebDAV API - Then the HTTP status code should be "202" - And the oc job status values of last request for user "Alice" should match these regular expressions - | status | /^error$/ | - | errorCode | /^403$/ | - And the content of file "/testshare/overwritethis.txt" for user "Alice" should be "Welcome to overwrite" - And user "Alice" should see the following elements - | /textfile0.txt | - - - Scenario: move file into a not-existing folder - When user "Alice" moves file "/textfile0.txt" asynchronously to "/not-existing/not-existing-file.txt" using the WebDAV API - Then the HTTP status code should be "202" - And the oc job status values of last request for user "Alice" should match these regular expressions - | status | /^error$/ | - | errorCode | /^409$/ | - | errorMessage | /^The destination node is not found$/ | - And user "Alice" should see the following elements - | /textfile0.txt | - - - Scenario: rename a file into an invalid filename - When user "Alice" moves file "/textfile0.txt" asynchronously to "/a\\a" using the WebDAV API - Then the HTTP status code should be "400" - And user "Alice" should see the following elements - | /textfile0.txt | - - - Scenario: Renaming a file to a path with extension .part should not be possible - When user "Alice" moves file "/textfile0.txt" asynchronously to "/textfile0.part" using the WebDAV API - Then the HTTP status code should be "400" - And user "Alice" should see the following elements - | /textfile0.txt | - But user "Alice" should not see the following elements - | /textfile0.part | - - - Scenario: Checking file id after a move - Given user "Alice" has stored id of file "/textfile0.txt" - And user "Alice" has created folder "FOLDER" - When user "Alice" moves file "/textfile0.txt" asynchronously to "/FOLDER/textfile0.txt" using the WebDAV API - Then the HTTP status code should be "202" - And user "Alice" file "/FOLDER/textfile0.txt" should have the previously stored id - And user "Alice" should not see the following elements - | /textfile0.txt | - - - Scenario: disabled async operations leads to original behavior - Given the administrator has disabled async operations - And user "Alice" has created folder "FOLDER" - When user "Alice" moves file "/textfile0.txt" asynchronously to "/FOLDER/fileToMove.txt" using the WebDAV API - Then the HTTP status code should be "201" - And the following headers should not be set - | header | - | OC-JobStatus-Location | - And the content of file "/FOLDER/fileToMove.txt" for user "Alice" should be "ownCloud test text file 0" - - - Scenario Outline: enabling async operations does no difference to normal MOVE - Moving a file - Given the administrator has enabled async operations - And user "Alice" has created folder "FOLDER" - And using DAV path - When user "Alice" moves file "/textfile0.txt" to "/FOLDER/fileToMove.txt" using the WebDAV API - Then the HTTP status code should be "201" - And the content of file "/FOLDER/fileToMove.txt" for user "Alice" should be "ownCloud test text file 0" - Examples: - | dav_version | - | old | - | new | - - - Scenario Outline: enabling async operations does no difference to normal MOVE - Moving and overwriting a file - Given the administrator has enabled async operations - And user "Alice" has uploaded file with content "Welcome to ownCloud" to "/fileToMove.txt" - And using DAV path - When user "Alice" moves file "/fileToMove.txt" to "/textfile0.txt" using the WebDAV API - Then the HTTP status code should be "204" - And the content of file "/textfile0.txt" for user "Alice" should be "Welcome to ownCloud" - Examples: - | dav_version | - | old | - | new | - - @files_sharing-app-required - Scenario Outline: enabling async operations does no difference to normal MOVE - Moving a file to a folder with no permissions - Given the administrator has enabled async operations - And 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 | read | - | shareWith | Alice | - When user "Alice" moves file "/textfile0.txt" to "/testshare/textfile0.txt" using the WebDAV API - Then the HTTP status code should be "403" - And user "Alice" should not be able to download file "/testshare/textfile0.txt" - Examples: - | dav_version | - | old | - | new | - - - Scenario Outline: enabling async operations does no difference to normal MOVE - move file into a not-existing folder - Given the administrator has enabled async operations - And using DAV path - When user "Alice" moves file "/textfile0.txt" to "/not-existing/fileToMove.txt" using the WebDAV API - Then the HTTP status code should be "409" - Examples: - | dav_version | - | old | - | new | - - - Scenario Outline: enabling async operations does no difference to normal MOVE - rename a file into an invalid filename - Given the administrator has enabled async operations - And using DAV path - When user "Alice" moves file "/textfile0.txt" to "/a\\a" using the WebDAV API - Then the HTTP status code should be "400" - Examples: - | dav_version | - | old | - | new | - - - Scenario Outline: enabling async operations does no difference to normal MOVE - rename a file into a banned filename - Given the administrator has enabled async operations - And using DAV path - When user "Alice" moves file "/textfile0.txt" to "/.htaccess" using the WebDAV API - Then the HTTP status code should be "403" - Examples: - | dav_version | - | old | - | new | - - #this does not work if firewall app is enabled - #and it also does not work with the php-dev server - @skipOnFirewall - Scenario: Moving and overwriting a file with lazyops - #need to slowdown the request for longer than the timeout - #when doing LazyOps the server does not close the connection - #so we timeout the request and check the job-status - Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToMove.txt" - And the HTTP-Request-timeout is set to 5 seconds - And the MOVE DAV requests are slowed down by 10 seconds - When user "Alice" moves file "/fileToMove.txt" asynchronously to "/textfile0.txt" using the WebDAV API - Then the HTTP status code should be "202" - And the following headers should match these regular expressions for user "Alice" - | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | - And the oc job status values of last request for user "Alice" should match these regular expressions - | status | /^started$/ | diff --git a/tests/acceptance/features/coreApiWebdavMove1/moveFileToBlacklistedNameAsync.feature b/tests/acceptance/features/coreApiWebdavMove1/moveFileToBlacklistedNameAsync.feature deleted file mode 100644 index 9f31a815df8..00000000000 --- a/tests/acceptance/features/coreApiWebdavMove1/moveFileToBlacklistedNameAsync.feature +++ /dev/null @@ -1,55 +0,0 @@ -@api @issue-ocis-reva-14 @notToImplementOnOCIS -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 new DAV path - And 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" - And the administrator has enabled async operations - - - Scenario: rename a file to a filename that is banned by default - When user "Alice" moves file "/textfile0.txt" asynchronously to "/.htaccess" using the WebDAV API - Then the HTTP status code should be "403" - And user "Alice" should see the following elements - | /textfile0.txt | - - - Scenario: rename a file to a banned filename - Given the administrator has updated system config key "blacklisted_files" with value '["blacklisted-file.txt",".htaccess"]' and type "json" - When user "Alice" moves file "/textfile0.txt" asynchronously to "/blacklisted-file.txt" using the WebDAV API - Then the HTTP status code should be "403" - And user "Alice" should see the following elements - | /textfile0.txt | - - - Scenario: rename a file to a filename that matches (or not) blacklisted_files_regex - Given user "Alice" has created folder "FOLDER" - # 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\..+ - And the administrator has updated system config key "blacklisted_files_regex" with value '[".*\\.ext$","^bannedfilename\\..+","containsbannedstring"]' and type "json" - When user "Alice" moves file "/textfile0.txt" asynchronously to these filenames using the webDAV API then the results should be as listed - | filename | http-code | exists | - | .ext | 403 | no | - | filename.ext | 403 | no | - | bannedfilename.txt | 403 | no | - | containsbannedstring | 403 | no | - | this-ContainsBannedString.txt | 403 | no | - | /FOLDER/.ext | 403 | no | - | /FOLDER/filename.ext | 403 | no | - | /FOLDER/bannedfilename.txt | 403 | no | - | /FOLDER/containsbannedstring | 403 | no | - | /FOLDER/this-ContainsBannedString.txt | 403 | no | - | .extension | 202 | yes | - | filename.txt | 202 | yes | - | bannedfilename | 202 | yes | - | bannedfilenamewithoutdot | 202 | yes | - | not-contains-banned-string.txt | 202 | yes | - | /FOLDER/.extension | 202 | yes | - | /FOLDER/filename.txt | 202 | yes | - | /FOLDER/bannedfilename | 202 | yes | - | /FOLDER/bannedfilenamewithoutdot | 202 | yes | - | /FOLDER/not-contains-banned-string.txt | 202 | yes | diff --git a/tests/acceptance/features/coreApiWebdavMove1/moveFileToExcludedDirectoryAsync.feature b/tests/acceptance/features/coreApiWebdavMove1/moveFileToExcludedDirectoryAsync.feature deleted file mode 100644 index 40942abb222..00000000000 --- a/tests/acceptance/features/coreApiWebdavMove1/moveFileToExcludedDirectoryAsync.feature +++ /dev/null @@ -1,59 +0,0 @@ -@api @issue-ocis-reva-14 @notToImplementOnOCIS -Feature: users cannot move (rename) a file to or into an excluded directory - As an administrator - I want to be able to exclude directories (folders) from being processed. Any attempt to rename an existing file or folder 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 new DAV path - And 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" - And the administrator has enabled async operations - - - Scenario: rename a file to an excluded directory name - Given the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" - When user "Alice" moves file "/textfile0.txt" asynchronously to "/.github" using the WebDAV API - Then the HTTP status code should be "403" - And user "Alice" should see the following elements - | /textfile0.txt | - - - Scenario: rename a file to an excluded directory name inside a parent directory - 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" moves file "/textfile0.txt" asynchronously to "/FOLDER/.github" using the WebDAV API - Then the HTTP status code should be "403" - And user "Alice" should see the following elements - | /textfile0.txt | - - - Scenario: rename a file to a filename that matches (or not) excluded_directories_regex - Given user "Alice" has created folder "FOLDER" - # 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 - And the administrator has updated system config key "excluded_directories_regex" with value '["endswith\\.bad$","^\\.git","containsvirusinthename"]' and type "json" - When user "Alice" moves file "/textfile0.txt" asynchronously to these filenames using the webDAV API then the results should be as listed - | filename | http-code | exists | - | endswith.bad | 403 | no | - | thisendswith.bad | 403 | no | - | .git | 403 | no | - | .github | 403 | no | - | containsvirusinthename | 403 | no | - | this-containsvirusinthename.txt | 403 | no | - | /FOLDER/endswith.bad | 403 | no | - | /FOLDER/thisendswith.bad | 403 | no | - | /FOLDER/.git | 403 | no | - | /FOLDER/.github | 403 | no | - | /FOLDER/containsvirusinthename | 403 | no | - | /FOLDER/this-containsvirusinthename.txt | 403 | no | - | endswith.badandotherstuff | 202 | yes | - | thisendswith.badandotherstuff | 202 | yes | - | name.git | 202 | yes | - | name.github | 202 | yes | - | not-contains-virus-in-the-name.txt | 202 | yes | - | /FOLDER/endswith.badandotherstuff | 202 | yes | - | /FOLDER/thisendswith.badandotherstuff | 202 | yes | - | /FOLDER/name.git | 202 | yes | - | /FOLDER/name.github | 202 | yes | - | /FOLDER/not-contains-virus-in-the-name.txt | 202 | yes | diff --git a/tests/acceptance/features/coreApiWebdavOperations/downloadFile.feature b/tests/acceptance/features/coreApiWebdavOperations/downloadFile.feature index 76e436229a8..e401ba753ee 100644 --- a/tests/acceptance/features/coreApiWebdavOperations/downloadFile.feature +++ b/tests/acceptance/features/coreApiWebdavOperations/downloadFile.feature @@ -59,51 +59,6 @@ Feature: download file | dav_version | | spaces | - @smokeTest @notToImplementOnOCIS - Scenario Outline: Downloading a file should serve security headers - Given using DAV path - When user "Alice" downloads file "/welcome.txt" using the WebDAV API - Then the HTTP status code should be "200" - And the following headers should be set - | header | value | - | Content-Disposition | attachment; filename*=UTF-8''welcome.txt; filename="welcome.txt" | - | Content-Security-Policy | default-src 'none'; | - | X-Content-Type-Options | nosniff | - | X-Download-Options | noopen | - | X-Frame-Options | SAMEORIGIN | - | X-Permitted-Cross-Domain-Policies | none | - | X-Robots-Tag | none | - | X-XSS-Protection | 0 | - And the downloaded content should start with "Welcome" - Examples: - | dav_version | - | old | - | new | - - @notToImplementOnOCIS - Scenario Outline: Doing a GET with a web login should work without CSRF token on the new backend - Given using DAV path - And user "Alice" has logged in to a web-style session - When the client sends a "GET" to "/remote.php/dav/files/%username%/welcome.txt" of user "Alice" without requesttoken - Then the HTTP status code should be "200" - And the downloaded content should start with "Welcome" - Examples: - | dav_version | - | old | - | new | - - @notToImplementOnOCIS - Scenario Outline: Doing a GET with a web login should work with CSRF token on the new backend - Given using DAV path - And user "Alice" has logged in to a web-style session - When the client sends a "GET" to "/remote.php/dav/files/%username%/welcome.txt" of user "Alice" with requesttoken - Then the HTTP status code should be "200" - And the downloaded content should start with "Welcome" - Examples: - | dav_version | - | old | - | new | - Scenario Outline: Get the size of a file Given using DAV path @@ -339,4 +294,4 @@ Feature: download file Given user "Alice" has uploaded file "filesForUpload/zerobyte.txt" to "/zerobyte.txt" When user "Alice" downloads file "/zerobyte.txt" using the WebDAV API Then the HTTP status code should be "200" - And the size of the downloaded file should be 0 bytes \ No newline at end of file + And the size of the downloaded file should be 0 bytes diff --git a/tests/acceptance/features/coreApiWebdavOperations/listFiles.feature b/tests/acceptance/features/coreApiWebdavOperations/listFiles.feature index b91ec668af3..d2040308fd3 100644 --- a/tests/acceptance/features/coreApiWebdavOperations/listFiles.feature +++ b/tests/acceptance/features/coreApiWebdavOperations/listFiles.feature @@ -203,11 +203,6 @@ Feature: list files | /simple-folder1/simple-folder2/welcome.txt | | /simple-folder1/simple-folder2/simple-folder3 | | /simple-folder1/simple-folder2/simple-folder3/simple-folder4 | - @notToImplementOnOCIS @issue-ocis-2079 - Examples: - | dav_version | - | old | - Examples: | dav_version | | new | @@ -236,11 +231,6 @@ Feature: list files | /simple-folder1/simple-folder2 | | /simple-folder1/textfile0.txt | | /simple-folder1/simple-folder2/simple-folder3/simple-folder4 | - @notToImplementOnOCIS @issue-ocis-2079 - Examples: - | dav_version | - | old | - Examples: | dav_version | | new | @@ -268,11 +258,6 @@ Feature: list files | /simple-folder1/simple-folder2/welcome.txt | | /simple-folder1/simple-folder2/simple-folder3 | | /simple-folder1/simple-folder2/simple-folder3/simple-folder4 | - @notToImplementOnOCIS @issue-ocis-2079 - Examples: - | dav_version | - | old | - Examples: | dav_version | | new | @@ -398,11 +383,6 @@ Feature: list files And user "Alice" has created a public link share of folder "simple-folder" When the public lists the resources in the last created public link with depth "infinity" using the WebDAV API Then the HTTP status code should be "412" - @notToImplementOnOCIS @issue-ocis-2079 - Examples: - | dav_version | - | old | - Examples: | dav_version | | new | diff --git a/tests/acceptance/features/coreApiWebdavOperations/propfind.feature b/tests/acceptance/features/coreApiWebdavOperations/propfind.feature index ff3598b684b..5fd6caebd5f 100644 --- a/tests/acceptance/features/coreApiWebdavOperations/propfind.feature +++ b/tests/acceptance/features/coreApiWebdavOperations/propfind.feature @@ -23,16 +23,6 @@ Feature: PROPFIND | header | value | | depth | | Then the HTTP status code should be "" - @notToImplementOnOCIS @depthInfinityPropfindEnabled - Examples: - | dav_path | depth_infinity_allowed | depth | http_status | - | /remote.php/dav/files/alice | 1 | 0 | 207 | - | /remote.php/dav/files/alice | 1 | infinity | 207 | - @notToImplementOnOCIS @depthInfinityPropfindDisabled - Examples: - | dav_path | depth_infinity_allowed | depth | http_status | - | /remote.php/dav/files/alice | 0 | 0 | 207 | - | /remote.php/dav/files/alice | 0 | infinity | 412 | @skipOnOcV10 @depthInfinityPropfindEnabled Examples: | dav_path | depth_infinity_allowed | depth | http_status | @@ -96,4 +86,4 @@ Feature: PROPFIND | password | 1111 | When the public sends "PROPFIND" request to the last public link share using the new public WebDAV API with password "1234" Then the HTTP status code should be "401" - And the value of the item "/d:error/s:exception" in the response should be "Sabre\DAV\Exception\NotAuthenticated" \ No newline at end of file + And the value of the item "/d:error/s:exception" in the response should be "Sabre\DAV\Exception\NotAuthenticated" diff --git a/tests/acceptance/features/coreApiWebdavPreviews/previews.feature b/tests/acceptance/features/coreApiWebdavPreviews/previews.feature index b038397f8ae..cb59a22c4cb 100644 --- a/tests/acceptance/features/coreApiWebdavPreviews/previews.feature +++ b/tests/acceptance/features/coreApiWebdavPreviews/previews.feature @@ -89,15 +89,6 @@ Feature: previews of files downloaded through the webdav API Then the HTTP status code should be "200" And the downloaded image should be "32" pixels wide and "32" pixels high - @notToImplementOnOCIS - Scenario: download previews of shared files (to root) - Given user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt" - And user "Alice" has shared file "/parent.txt" with user "Brian" - When user "Brian" downloads the preview of "/parent.txt" with width "32" and height "32" using the WebDAV API - Then the HTTP status code should be "200" - And the downloaded image should be "32" pixels wide and "32" pixels high - Scenario: download previews of other users files Given user "Brian" has been created with default attributes and without skeleton files @@ -184,16 +175,6 @@ Feature: previews of files downloaded through the webdav API Then the HTTP status code should be "204" And as user "Alice" the preview of "/parent.txt" with width "32" and height "32" should have been changed - @notToImplementOnOCIS - Scenario: when owner updates a shared file, previews for sharee are also updated - Given user "Brian" has been created with default attributes and without skeleton files - And user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt" - And user "Alice" has shared file "/parent.txt" with user "Brian" - And user "Brian" has downloaded the preview of "/parent.txt" with width "32" and height "32" - When user "Alice" uploads file with content "this is a file to upload" to "/parent.txt" using the WebDAV API - Then the HTTP status code should be "204" - And as user "Brian" the preview of "/parent.txt" with width "32" and height "32" should have been changed - @issue-ocis-2538 Scenario: when owner updates a shared file, previews for sharee are also updated (to shared folder) Given the administrator has set the default folder for received shares to "Shares" @@ -263,16 +244,3 @@ Feature: previews of files downloaded through the webdav API And as user "Alice" the preview of "/FOLDER/lorem.txt" with width "32" and height "32" should have been changed And as user "Brian" the preview of "Shares/FOLDER/lorem.txt" with width "32" and height "32" should have been changed And as user "Carol" the preview of "Shares/FOLDER/lorem.txt" with width "32" and height "32" should have been changed - - @notToImplementOnOCIS - Scenario: JPEG preview quality can be determined by config - Given user "Alice" has uploaded file "filesForUpload/testavatar.jpg" to "/testavatar_low.jpg" - And the administrator has updated system config key "previewJPEGImageDisplayQuality" with value "1" - And user "Alice" downloads the preview of "/testavatar_low.jpg" with width "32" and height "32" using the WebDAV API - Then the HTTP status code should be "200" - And the requested JPEG image should have a quality value of "1" - Then user "Alice" has uploaded file "filesForUpload/testavatar.jpg" to "/testavatar_high.jpg" - And the administrator has updated system config key "previewJPEGImageDisplayQuality" with value "100" - And user "Alice" downloads the preview of "/testavatar_high.jpg" with width "32" and height "32" using the WebDAV API - Then the HTTP status code should be "200" - And the requested JPEG image should have a quality value of "100" diff --git a/tests/acceptance/features/coreApiWebdavProperties2/getFileProperties.feature b/tests/acceptance/features/coreApiWebdavProperties2/getFileProperties.feature index c3fddf28117..9466c5d8390 100644 --- a/tests/acceptance/features/coreApiWebdavProperties2/getFileProperties.feature +++ b/tests/acceptance/features/coreApiWebdavProperties2/getFileProperties.feature @@ -280,18 +280,6 @@ Feature: get file properties | dav_version | | spaces | - @notToImplementOnOCIS - Scenario Outline: Doing a PROPFIND with a web login should work with CSRF token on the new backend - Given using DAV path - And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/somefile.txt" - And user "Alice" has logged in to a web-style session - When the client sends a "PROPFIND" to "/remote.php/dav/files/%username%/somefile.txt" of user "Alice" with requesttoken - Then the HTTP status code should be "207" - Examples: - | dav_version | - | old | - | new | - @smokeTest @issue-ocis-reva-216 Scenario Outline: Retrieving private link Given using DAV path diff --git a/tests/acceptance/features/coreApiWebdavUpload1/uploadFileAsyncUsingNewChunking.feature b/tests/acceptance/features/coreApiWebdavUpload1/uploadFileAsyncUsingNewChunking.feature deleted file mode 100644 index ac8b0f3175c..00000000000 --- a/tests/acceptance/features/coreApiWebdavUpload1/uploadFileAsyncUsingNewChunking.feature +++ /dev/null @@ -1,184 +0,0 @@ -@api @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 -Feature: upload file using new chunking - As a user - I want to be able to upload "large" files in chunks asynchronously - So that I do not have to wait for the long MOVE operation on assembly to finish - - Background: - Given using new 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 - And the administrator has enabled async operations - - - Scenario: Upload chunked file ordered asc using async MOVE - When user "Alice" uploads the following chunks asynchronously to "/myChunkedFile.txt" with new chunking and using the WebDAV API - | number | content | - | 1 | AAAAA | - | 2 | BBBBB | - | 3 | CCCCC | - Then the HTTP status code should be "202" - And the following headers should match these regular expressions for user "Alice" - | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | - And the oc job status values of last request for user "Alice" should match these regular expressions - | status | /^finished$/ | - | fileId | /^[0-9a-z]{20,}$/ | - And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" - And the log file should not contain any log-entries containing these attributes: - | app | - | dav | - - - Scenario: Upload chunked file ordered desc using async MOVE - When user "Alice" uploads the following chunks asynchronously to "/myChunkedFile.txt" with new chunking and using the WebDAV API - | number | content | - | 3 | CCCCC | - | 2 | BBBBB | - | 1 | AAAAA | - Then the HTTP status code should be "202" - And the following headers should match these regular expressions for user "Alice" - | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | - And the oc job status values of last request for user "Alice" should match these regular expressions - | status | /^finished$/ | - | fileId | /^[0-9a-z]{20,}$/ | - And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" - And the log file should not contain any log-entries containing these attributes: - | app | - | dav | - - - Scenario: Upload chunked file in random order using async MOVE - When user "Alice" uploads the following chunks asynchronously to "/myChunkedFile.txt" with new chunking and using the WebDAV API - | number | content | - | 2 | BBBBB | - | 3 | CCCCC | - | 1 | AAAAA | - Then the HTTP status code should be "202" - And the following headers should match these regular expressions for user "Alice" - | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | - And the oc job status values of last request for user "Alice" should match these regular expressions - | status | /^finished$/ | - | fileId | /^[0-9a-z]{20,}$/ | - And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" - And the log file should not contain any log-entries containing these attributes: - | app | - | dav | - - - Scenario: Upload chunked file overwriting existing file using async MOVE - Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" - And user "Alice" has copied file "/textfile0.txt" to "/existingFile.txt" - When user "Alice" uploads the following chunks asynchronously to "/existingFile.txt" with new chunking and using the WebDAV API - | number | content | - | 1 | AAAAA | - | 2 | BBBBB | - | 3 | CCCCC | - Then the HTTP status code should be "202" - And the following headers should match these regular expressions for user "Alice" - | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | - And the oc job status values of last request for user "Alice" should match these regular expressions - | status | /^finished$/ | - | fileId | /^[0-9a-z]{20,}$/ | - And the content of file "/existingFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" - And the log file should not contain any log-entries containing these attributes: - | app | - | dav | - - - Scenario: New chunked upload MOVE using old DAV path should fail - Given user "Alice" has created a new chunking upload with id "chunking-42" - And user "Alice" has uploaded new chunk file "2" with "BBBBB" to id "chunking-42" - And user "Alice" has uploaded new chunk file "3" with "CCCCC" to id "chunking-42" - And user "Alice" has uploaded new chunk file "1" with "AAAAA" to id "chunking-42" - When using old DAV path - And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" using the WebDAV API - Then the HTTP status code should be "404" - - - Scenario: Upload file via new chunking endpoint with wrong size header using async MOVE - Given user "Alice" has created a new chunking upload with id "chunking-42" - And user "Alice" has uploaded new chunk file "1" with "AAAAA" to id "chunking-42" - And user "Alice" has uploaded new chunk file "2" with "BBBBB" to id "chunking-42" - And user "Alice" has uploaded new chunk file "3" with "CCCCC" to id "chunking-42" - When user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" with size 5 using the WebDAV API - Then the HTTP status code should be "202" - And the following headers should match these regular expressions for user "Alice" - | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | - And the oc job status values of last request for user "Alice" should match these regular expressions - | status | /^error$/ | - | errorCode | /^400$/ | - | errorMessage | /^Chunks on server do not sum up to 5 but to 15$/ | - - - Scenario: Upload file via new chunking endpoint with correct size header using async MOVE - Given user "Alice" has created a new chunking upload with id "chunking-42" - And user "Alice" has uploaded new chunk file "1" with "AAAAA" to id "chunking-42" - And user "Alice" has uploaded new chunk file "2" with "BBBBB" to id "chunking-42" - And user "Alice" has uploaded new chunk file "3" with "CCCCC" to id "chunking-42" - When user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" with size 15 using the WebDAV API - Then the HTTP status code should be "202" - And the following headers should match these regular expressions for user "Alice" - | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | - And the oc job status values of last request for user "Alice" should match these regular expressions - | status | /^finished$/ | - | fileId | /^[0-9a-z]{20,}$/ | - And as "Alice" file "/myChunkedFile.txt" should exist - And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" - And the log file should not contain any log-entries containing these attributes: - | app | - | dav | - - - Scenario Outline: Upload files with difficult names using new chunking and async MOVE - When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/" using the WebDAV API - Then the HTTP status code should be "202" - And the following headers should match these regular expressions for user "Alice" - | OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ | - And the oc job status values of last request for user "Alice" should match these regular expressions - | status | /^finished$/ | - | fileId | /^[0-9a-z]{20,}$/ | - And as "Alice" file "/" should exist - And the content of file "/" for user "Alice" should be "AAAAABBBBBCCCCC" - And the log file should not contain any log-entries containing these attributes: - | app | - | dav | - Examples: - | file-name | - | &#? | - | TIÄFÜ | - - - Scenario: disabled async operations leads to original behavior - Given the administrator has disabled async operations - When user "Alice" uploads the following chunks asynchronously to "/myChunkedFile.txt" with new 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 not be set - | header | - | OC-JobStatus-Location | - And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" - - - Scenario: enabling async operations does no difference to normal MOVE - Upload chunked file - When user "Alice" uploads the following chunks to "/myChunkedFile.txt" with new 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 not be set - | header | - | OC-JobStatus-Location | - And as "Alice" file "/myChunkedFile.txt" should exist - And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" - And the log file should not contain any log-entries containing these attributes: - | app | - | dav | diff --git a/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToBlacklistedName.feature b/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToBlacklistedName.feature index 3b67e27d8e3..a870a647861 100644 --- a/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToBlacklistedName.feature +++ b/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToBlacklistedName.feature @@ -8,17 +8,6 @@ Feature: users cannot upload a file to a blacklisted name Given using OCS API version "1" And user "Alice" has been created with default attributes and without skeleton files - @issue-ocis-reva-15 @notToImplementOnOCIS - Scenario Outline: upload a file to a filename that is banned by default - Given using DAV path - When user "Alice" uploads file with content "uploaded content" to ".htaccess" using the WebDAV API - Then the HTTP status code should be "403" - And as "Alice" file ".htaccess" should not exist - Examples: - | dav_version | - | old | - | new | - @issue-ocis-reva-54 Scenario Outline: upload a file to a banned filename Given using DAV path diff --git a/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToBlacklistedNameAsyncUsingNewChunking.feature b/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToBlacklistedNameAsyncUsingNewChunking.feature deleted file mode 100644 index 8705504a848..00000000000 --- a/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToBlacklistedNameAsyncUsingNewChunking.feature +++ /dev/null @@ -1,64 +0,0 @@ -@api @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 -Feature: users cannot upload a file to a blacklisted name using new 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 new 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 - And the administrator has enabled async operations - - - Scenario: Upload to a filename that is banned by default using new chunking and async MOVE - When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/.htaccess" using the WebDAV API - Then the HTTP status code should be "403" - And as "Alice" file "/.htaccess" should not exist - - - Scenario: Upload to a banned filename using new chunking and async MOVE - Given the administrator has updated system config key "blacklisted_files" with value '["blacklisted-file.txt",".htaccess"]' and type "json" - When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/blacklisted-file.txt" using the WebDAV API - Then the HTTP status code should be "403" - And as "Alice" file "/blacklisted-file.txt" should not exist - - - Scenario Outline: upload a file to a filename that matches blacklisted_files_regex using new chunking and async MOVE - # 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" creates a new chunking upload with id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "" using the WebDAV API - Then the HTTP status code should be "403" - And as "Alice" file "" should not exist - Examples: - | filename | - | filename.ext | - | bannedfilename.txt | - | this-ContainsBannedString.txt | - - - Scenario: upload a file to a filename that does not match blacklisted_files_regex using new chunking and async MOVE - # 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" creates a new chunking upload with id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "not-contains-banned-string.txt" using the WebDAV API - Then the HTTP status code should be "202" - And as "Alice" file "not-contains-banned-string.txt" should exist diff --git a/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToExcludedDirectoryAsyncUsingNewChunking.feature b/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToExcludedDirectoryAsyncUsingNewChunking.feature deleted file mode 100644 index 7dbc847654f..00000000000 --- a/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToExcludedDirectoryAsyncUsingNewChunking.feature +++ /dev/null @@ -1,67 +0,0 @@ -@api @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 -Feature: users cannot upload a file to or into an excluded directory using new 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 new 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 - And the administrator has enabled async operations - - - Scenario: Upload to an excluded directory name using new chunking and async MOVE - Given the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" - When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/.github" using the WebDAV API - Then the HTTP status code should be "403" - And as "Alice" file "/.github" should not exist - - - Scenario: Upload to an excluded directory name inside a parent directory using new chunking and async MOVE - 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" creates a new chunking upload with id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/FOLDER/.github" using the WebDAV API - Then the HTTP status code should be "403" - And as "Alice" folder "/FOLDER" should exist - But as "Alice" file "/FOLDER/.github" should not exist - - - Scenario Outline: upload a file to a filename that matches excluded_directories_regex using new chunking and async MOVE - # 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" creates a new chunking upload with id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "" using the WebDAV API - Then the HTTP status code should be "403" - And as "Alice" file "" should not exist - Examples: - | filename | - | thisendswith.bad | - | .github | - | this-containsvirusinthename.txt | - - - Scenario: upload a file to a filename that does not match excluded_directories_regex using new chunking and async MOVE - # 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" creates a new chunking upload with id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "not-contains-virus-in-the-name.txt" using the WebDAV API - Then the HTTP status code should be "202" - And as "Alice" file "not-contains-virus-in-the-name.txt" should exist diff --git a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingNewChunking.feature b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingNewChunking.feature deleted file mode 100644 index 7e02f174cd2..00000000000 --- a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingNewChunking.feature +++ /dev/null @@ -1,62 +0,0 @@ -@api @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 -Feature: users cannot upload a file to a blacklisted name using new 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 new DAV path - And user "Alice" has been created with default attributes and without skeleton files - - - Scenario: Upload a file to a filename that is banned by default using new chunking - When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" to ".htaccess" using the WebDAV API - Then the HTTP status code should be "403" - And as "Alice" file ".htaccess" should not exist - - - Scenario: Upload a file to a banned filename using new chunking - Given the administrator has updated system config key "blacklisted_files" with value '["blacklisted-file.txt",".htaccess"]' and type "json" - When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" to "blacklisted-file.txt" using the WebDAV API - Then the HTTP status code should be "403" - And as "Alice" file "blacklisted-file.txt" should not exist - - - Scenario Outline: upload a file to a filename that matches blacklisted_files_regex using new 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" creates a new chunking upload with id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" to "" using the WebDAV API - Then the HTTP status code should be "403" - And as "Alice" file "" should not exist - Examples: - | filename | - | filename.ext | - | bannedfilename.txt | - | this-ContainsBannedString.txt | - - - Scenario: upload a file to a filename that does not match blacklisted_files_regex using new 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" creates a new chunking upload with id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" to "not-contains-banned-string.txt" using the WebDAV API - Then the HTTP status code should be "201" - And as "Alice" file "not-contains-banned-string.txt" should exist diff --git a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunking.feature b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunking.feature index 973265c179b..107290f4c78 100644 --- a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunking.feature +++ b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunking.feature @@ -9,12 +9,6 @@ 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 - @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 - 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" diff --git a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingNewChunking.feature b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingNewChunking.feature deleted file mode 100644 index accfd7aa1f3..00000000000 --- a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingNewChunking.feature +++ /dev/null @@ -1,65 +0,0 @@ -@api @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 -Feature: users cannot upload a file to or into an excluded directory using new 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 new DAV path - And user "Alice" has been created with default attributes and without skeleton files - - - Scenario: Upload a file to an excluded directory name using new chunking - Given the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json" - When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" to ".github" using the WebDAV API - Then the HTTP status code should be "403" - And as "Alice" file ".github" should not exist - - - Scenario: Upload a file to an excluded directory name inside a parent directory using new 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" creates a new chunking upload with id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" to "/FOLDER/.github" using the WebDAV API - Then the HTTP status code should be "403" - And as "Alice" folder "/FOLDER" should exist - But as "Alice" file "/FOLDER/.github" should not exist - - - Scenario Outline: upload a file to a filename that matches excluded_directories_regex using new 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" creates a new chunking upload with id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" to "" using the WebDAV API - Then the HTTP status code should be "403" - And as "Alice" file "" should not exist - Examples: - | filename | - | thisendswith.bad | - | .github | - | this-containsvirusinthename.txt | - - - Scenario: upload a file to a filename that does not match excluded_directories_regex using new 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" creates a new chunking upload with id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" to "not-contains-virus-in-the-name.txt" using the WebDAV API - Then the HTTP status code should be "201" - And as "Alice" file "not-contains-virus-in-the-name.txt" should exist diff --git a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileUsingNewChunking.feature b/tests/acceptance/features/coreApiWebdavUpload2/uploadFileUsingNewChunking.feature deleted file mode 100644 index 69419021364..00000000000 --- a/tests/acceptance/features/coreApiWebdavUpload2/uploadFileUsingNewChunking.feature +++ /dev/null @@ -1,193 +0,0 @@ -@api @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321 -Feature: upload file using new 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 - - Background: - Given using OCS API version "1" - And using new DAV path - And user "Alice" has been created with default attributes and without skeleton files - - - Scenario: Upload chunked file asc with new chunking - Given the owncloud log level has been set to debug - And the owncloud log has been cleared - When user "Alice" uploads the following chunks to "/myChunkedFile.txt" with new 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}"$/ | - And as "Alice" file "/myChunkedFile.txt" should exist - And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" - And the log file should not contain any log-entries containing these attributes: - | app | - | dav | - - - Scenario: Upload chunked file desc with new chunking - Given the owncloud log level has been set to debug - And the owncloud log has been cleared - When user "Alice" uploads the following chunks to "/myChunkedFile.txt" with new chunking and using the WebDAV API - | number | content | - | 1 | AAAAA | - | 2 | BBBBB | - | 3 | CCCCC | - Then the HTTP status code should be "201" - And as "Alice" file "/myChunkedFile.txt" should exist - And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" - And the log file should not contain any log-entries containing these attributes: - | app | - | dav | - - - Scenario: Upload chunked file random with new chunking - Given the owncloud log level has been set to debug - And the owncloud log has been cleared - When user "Alice" uploads the following chunks to "/myChunkedFile.txt" with new chunking and using the WebDAV API - | number | content | - | 1 | AAAAA | - | 2 | BBBBB | - | 3 | CCCCC | - Then the HTTP status code should be "201" - And as "Alice" file "/myChunkedFile.txt" should exist - And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" - And the log file should not contain any log-entries containing these attributes: - | app | - | dav | - - - Scenario: Checking file id after a move overwrite using new chunking endpoint - Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt" - And the owncloud log level has been set to debug - And the owncloud log has been cleared - And user "Alice" has copied file "/textfile0.txt" to "/existingFile.txt" - And user "Alice" has stored id of file "/existingFile.txt" - When user "Alice" uploads file "filesForUpload/textfile.txt" to "/existingFile.txt" in 3 chunks with new chunking and using the WebDAV API - Then the HTTP status code should be "204" - And user "Alice" file "/existingFile.txt" should have the previously stored id - And the content of file "/existingFile.txt" for user "Alice" should be: - """ - This is a testfile. - - Cheers. - """ - And the log file should not contain any log-entries containing these attributes: - | app | - | dav | - - - Scenario: New chunked upload MKDIR using old DAV path should fail - Given using old DAV path - When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API - Then the HTTP status code should be "409" - - - Scenario: New chunked upload PUT using old DAV path should fail - Given user "Alice" has created a new chunking upload with id "chunking-42" - When using old DAV path - And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API - Then the HTTP status code should be "409" - - - Scenario: New chunked upload MOVE using old DAV path should fail - Given user "Alice" has created a new chunking upload with id "chunking-42" - And user "Alice" has uploaded new chunk file "2" with "BBBBB" to id "chunking-42" - And user "Alice" has uploaded new chunk file "3" with "CCCCC" to id "chunking-42" - And user "Alice" has uploaded new chunk file "1" with "AAAAA" to id "chunking-42" - When using old DAV path - And user "Alice" moves new chunk file with id "chunking-42" to "/myChunkedFile.txt" using the WebDAV API - Then the HTTP status code should be "404" - - - Scenario: Upload to new DAV path using old way should fail - When user "Alice" uploads chunk file "1" of "3" with "AAAAA" to "/myChunkedFile.txt" using the WebDAV API - Then the HTTP status code should be "503" - - - Scenario: Upload file via new chunking endpoint with wrong size header - Given user "Alice" has created a new chunking upload with id "chunking-42" - And user "Alice" has uploaded new chunk file "1" with "AAAAA" to id "chunking-42" - And user "Alice" has uploaded new chunk file "2" with "BBBBB" to id "chunking-42" - And user "Alice" has uploaded new chunk file "3" with "CCCCC" to id "chunking-42" - When user "Alice" moves new chunk file with id "chunking-42" to "/myChunkedFile.txt" with size 5 using the WebDAV API - Then the HTTP status code should be "400" - - - Scenario: Upload file via new chunking endpoint with correct size header - Given the owncloud log level has been set to debug - And the owncloud log has been cleared - And user "Alice" has created a new chunking upload with id "chunking-42" - And user "Alice" has uploaded new chunk file "1" with "AAAAA" to id "chunking-42" - And user "Alice" has uploaded new chunk file "2" with "BBBBB" to id "chunking-42" - And user "Alice" has uploaded new chunk file "3" with "CCCCC" to id "chunking-42" - When user "Alice" moves new chunk file with id "chunking-42" to "/myChunkedFile.txt" with size 15 using the WebDAV API - Then the HTTP status code should be "201" - And as "Alice" file "/myChunkedFile.txt" should exist - And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC" - And the log file should not contain any log-entries containing these attributes: - | app | - | dav | - - @smokeTest - # This smokeTest scenario does ordinary checks for chunked upload, - # without adjusting the log level. This allows it to run in test environments - # where the log level has been fixed and cannot be changed. - Scenario Outline: Upload files with difficult names using new chunking - When user "Alice" creates a new chunking upload with id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "1" with "AAAAA" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API - And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API - And user "Alice" moves new chunk file with id "chunking-42" to "/" using the WebDAV API - Then the HTTP status code should be "201" - And as "Alice" file "/" should exist - And the content of file "/" for user "Alice" should be "AAAAABBBBBCCCCC" - Examples: - | file-name | - | 0 | - | &#? | - | TIÄFÜ | - - - # This scenario does extra checks with the log level set to debug. - # It does not run in smoke test runs. (see comments in scenario above) - Scenario Outline: Upload files with difficult names using new chunking and check the log - Given the owncloud log level has been set to debug - And the owncloud log has been cleared - When user "Alice" uploads file "filesForUpload/textfile.txt" to "/" in 3 chunks with new chunking and using the WebDAV API - Then the HTTP status code should be "201" - And as "Alice" file "/" should exist - And the content of file "/" for user "Alice" should be: - """ - This is a testfile. - - Cheers. - """ - And the log file should not contain any log-entries containing these attributes: - | app | - | dav | - Examples: - | file-name | - | &#? | - | TIÄFÜ | - - - Scenario: Upload chunked file with new chunking with lengthy filenames - Given 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-नाम-012345.txt" with new 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-नाम-012345.txt" should exist - And the content of file "हजार नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-012345.txt" for user "Alice" should be "AAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCCCCCCCCCCC" - And the log file should not contain any log-entries containing these attributes: - | app | - | dav |