mirror/opencloud
1
0
Fork 0
mirror of https://github.com/opencloud-eu/opencloud.git synced 2026-05-18 13:35:37 -04:00
Code Issues Packages Projects Releases Wiki Activity

Removed scenarios tagged with notToImplementOnOcis tag

Browse Source
This commit is contained in:
Prarup Gurung
2023-02-01 15:12:30 +05:45
parent 0193b3850a
commit 984f848cbd
65 changed files with 12 additions and 5264 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
.drone.star
View File

@@ -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 {

11
tests/acceptance/config/behat-core.yml
View File

@@ -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"

2
tests/acceptance/docker/src/run-tests.sh
View File

@@ -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" ]

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

@@ -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"

97
tests/acceptance/features/coreApiAuthOcs/ocsGETAuth.feature
View File

@@ -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"

29
tests/acceptance/features/coreApiAuthWebDav/webDavCOPYAuth.feature
View File

@@ -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"

28
tests/acceptance/features/coreApiAuthWebDav/webDavLOCKAuth.feature
View File

@@ -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"

28
tests/acceptance/features/coreApiAuthWebDav/webDavMKCOLAuth.feature
View File

@@ -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"

29
tests/acceptance/features/coreApiAuthWebDav/webDavMOVEAuth.feature
View File

@@ -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"

29
tests/acceptance/features/coreApiAuthWebDav/webDavPOSTAuth.feature
View File

@@ -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"

28
tests/acceptance/features/coreApiAuthWebDav/webDavPROPFINDAuth.feature
View File

@@ -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"

28
tests/acceptance/features/coreApiAuthWebDav/webDavPROPPATCHAuth.feature
View File

@@ -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"

37
tests/acceptance/features/coreApiAuthWebDav/webDavPUTAuth.feature
View File

@@ -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"

82
tests/acceptance/features/coreApiFavorites/favorites.feature
View File

@@ -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_version> 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_version> 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_version> 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_version> 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_version> 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_version> 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_version> 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_version> 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 |

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

@@ -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_version> 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_version> 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_version> 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_version> 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_version> DAV path

90
tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareGroupCaseSensitive.feature
View File

@@ -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 "<ocs_api_version>"
And group "<group_id1>" has been created
And group "<group_id2>" has been created
And group "<group_id3>" 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 "<group_id1>"
And user "Carol" has been added to group "<group_id2>"
And user "David" has been added to group "<group_id3>"
When user "Alice" shares file "textfile1.txt" with group "<group_id1>" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
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 "<ocs_status_code>"
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 "<group_id2>" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
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 "<ocs_status_code>"
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 "<group_id3>" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
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 "<ocs_status_code>"
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 "<ocs_api_version>"
And these users have been created with default attributes and without skeleton files:
| username |
| Brian |
And group "<group_id1>" has been created
And user "Brian" has been added to group "<group_id1>"
When user "Alice" shares file "textfile1.txt" with group "<group_id1>" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
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 "<ocs_status_code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" should include
| share_with | <group_id1> |
| 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 "<group_id2>" using the sharing API
Then the OCS status code should be "404"
And the HTTP status code should be "<http_status_code>"
When user "Alice" shares file "textfile3.txt" with group "<group_id3>" using the sharing API
Then the OCS status code should be "404"
And the HTTP status code should be "<http_status_code>"
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 |

114
tests/acceptance/features/coreApiShareManagementBasicToShares/createShareFromLocalStorageToSharesFolder.feature
View File

@@ -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 "<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 "<ocs_status_code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" sharing with user "Brian" should include
| share_with | %username% |
| share_with_displayname | %displayname% |
| file_target | /Shares/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 "<pending_share_path>" offered by user "Alice" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
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 "<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 "<ocs_status_code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" sharing with user "Brian" should include
| share_with | %username% |
| share_with_displayname | %displayname% |
| file_target | /Shares/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 "<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 "<ocs_status_code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" sharing with group "grp1" should include
| share_with | grp1 |
| 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 "<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 "<ocs_status_code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" sharing with group "grp1" should include
| share_with | grp1 |
| 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 |

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

@@ -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 "<share_folder>"
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 | <top_folder>/<received_textfile_name> |
| item_type | file |
| mimetype | text/plain |
| storage_id | shared::<top_folder>/<received_textfile_name> |
| storage | A_STRING |
| item_source | A_STRING |
| file_source | A_STRING |
| file_target | <top_folder>/<received_textfile_name> |
| share_with | %username% |
| share_with_displayname | %displayname% |
| mail_send | 0 |
And user "Brian" should see the following elements
| /FOLDER/ |
| /PARENT/ |
| <top_folder>/<received_parent_name>/ |
| <top_folder>/<received_parent_name>/parent.txt |
| /textfile0.txt |
| <top_folder>/<received_textfile_name> |
And the sharing API should report to user "Brian" that these shares are in the accepted state
| path |
| <top_folder>/<received_parent_name>/ |
| <top_folder>/<received_textfile_name> |
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

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

@@ -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 "<sharer_folder>"
And user "Alice" has created folder "<group_folder>"
And user "Brian" has created folder "<receiver_folder>"
And user "Carol" has created folder "<receiver_folder>"
And user "Alice" has shared folder "<sharer_folder>" with user "Brian"
And user "Brian" has accepted share "/<sharer_folder>" offered by user "Alice"
When user "Brian" moves folder "<receiver_folder>" to "/Shares/<sharer_folder>/<receiver_folder>" using the WebDAV API
And user "Alice" shares folder "<group_folder>" with group "grp1" using the sharing API
And user "Carol" accepts share "/<group_folder>" offered by user "Alice" using the sharing API
And user "Carol" moves folder "/<receiver_folder>" to "/Shares/<group_folder>/<receiver_folder>" 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 "<sharer_folder>/<receiver_folder>" should exist
And as "Brian" folder "/Shares/<sharer_folder>/<receiver_folder>" should exist
And as "Alice" folder "<group_folder>/<receiver_folder>" should exist
And as "Carol" folder "/Shares/<group_folder>/<receiver_folder>" 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

90
tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShareFromLocalStorage.feature
View File

@@ -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 "<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 "<pending_share_path>" 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 "<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 "<pending_share_path>" 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 "<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 "<pending_share_path>" 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 "<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 "<pending_share_path>" 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 |

41
tests/acceptance/features/coreApiShareManagementToShares/moveShareInsideAnotherShare.feature
View File

@@ -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"

119
tests/acceptance/features/coreApiShareOperationsToShares1/accessToSharesFolder.feature
View File

@@ -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

40
tests/acceptance/features/coreApiShareOperationsToShares1/changingFilesShare.feature
View File

@@ -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_version> 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_version> 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_version> DAV path

22
tests/acceptance/features/coreApiShareOperationsToShares2/uploadToShare.feature
View File

@@ -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> 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> DAV path
@@ -304,4 +286,4 @@ Feature: sharing
Examples:
| dav_version |
| old |
| new |
| new |

0
tests/acceptance/features/coreApiSharePublicLink3/allowGroupToCreatePublicLinks.feature Normal file
View File

19
tests/acceptance/features/coreApiShareReshareToShares2/reShareChain.feature
View File

@@ -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 "<pending_share_path>" offered by user "Brian"
And user "Carol" has shared file "/Shares/textfile0_shared.txt" with user "David"
And user "David" has accepted share "<pending_share_path>" 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"

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

@@ -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 "<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 "<ocs_status_code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" sharing with group "grp1" should include
| id | A_STRING |
| 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 "<ocs_api_version>"

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

@@ -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 "<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 "<ocs-status>"
And the HTTP status code should be "<http-status>"
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 "<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 "<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 "<ocs-status>"
And the HTTP status code should be "<http-status>"
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 "<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 "<ocs-status>"
And the HTTP status code should be "<http-status>"
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 "<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 "<ocs-status>"
And the HTTP status code should be "<http-status>"
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 "<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 "<ocs-status>"
And the HTTP status code should be "<http-status>"
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 "<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 "<ocs-status>"
And the HTTP status code should be "<http-status>"
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 "<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 "<ocs-status>"
And the HTTP status code should be "<http-status>"
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 "<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 "<ocs-status>"
And the HTTP status code should be "<http-status>"
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 "<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 "<ocs-status>"
And the HTTP status code should be "<http-status>"
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 "<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 "<ocs-status>"
And the HTTP status code should be "<http-status>"
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 "<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 "<ocs-status>"
And the HTTP status code should be "<http-status>"
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 "<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 "<ocs-status>"
And the HTTP status code should be "<http-status>"
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 "<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 "<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 "<ocs-status>"
And the HTTP status code should be "<http-status>"
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 "<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 "<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 "<ocs-status>"
And the HTTP status code should be "<http-status>"
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 "<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 "<ocs-status>"
And the HTTP status code should be "<http-status>"
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 "<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 "<ocs-status>"
And the HTTP status code should be "<http-status>"
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 "<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 "<ocs-status>"
And the HTTP status code should be "<http-status>"
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 "<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 "<ocs-status>"
And the HTTP status code should be "<http-status>"
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 "<ocs-api-version>"
When user "sharee1" gets the sharees using the sharing API with parameters
| itemType | file |
Then the OCS status code should be "<ocs-status>"
And the HTTP status code should be "<http-status>"
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 "<ocs-api-version>"
When user "sharee1" gets the sharees using the sharing API with parameters
| itemType | file |
Then the OCS status code should be "<ocs-status>"
And the HTTP status code should be "<http-status>"
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 |

178
tests/acceptance/features/coreApiTrashbin/trashbinSharingToRoot.feature
View File

@@ -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> 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> 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> 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> 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> 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> 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> 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> 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> 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 |

323
tests/acceptance/features/coreApiTrashbin/trashbinSkip.feature
View File

@@ -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> 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> 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> 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> 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> 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> 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> 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> 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> 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> 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> 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> 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> 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 |

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

@@ -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> DAV path

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

@@ -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_version> DAV path
And the administrator has set the default folder for received shares to "<share_folder>"
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 "<share_folder>" using the WebDAV API
Then the HTTP status code should be "403"
And as "Brian" folder "<share_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_version> 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_version> DAV path

78
tests/acceptance/features/coreApiWebdavLocks/exclusiveLocks.feature
View File

@@ -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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
| 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> DAV path

128
tests/acceptance/features/coreApiWebdavLocks/folder.feature
View File

@@ -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> DAV path
And user "Alice" has created folder "FOLDER"
And user "Alice" has locked folder "FOLDER" setting the following properties
| lockscope | <lock-scope> |
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> 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 | <lock-scope> |
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> DAV path
And user "Alice" has created folder "FOLDER"
And user "Alice" has locked folder "FOLDER" setting the following properties
| lockscope | <lock-scope> |
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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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 "<lock-root>"
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$/ |

100
tests/acceptance/features/coreApiWebdavLocks/publicLink.feature
View File

@@ -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> 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 | <lock-scope> |
When the public uploads file "/test.txt" with content "test" using the <public-webdav-api-version> 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 | <lock-scope> |
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-version> 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 | <lock-scope> |
When the public uploads file "parent.txt" with content "test" using the <public-webdav-api-version> 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 | <lock-scope> |
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-version> 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-version> public WebDAV API setting the following properties
| lockscope | <lock-scope> |
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 |

127
tests/acceptance/features/coreApiWebdavLocks/publicLinkLockdiscovery.feature
View File

@@ -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 | <lock-scope> |
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 | <lock-scope> |
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 | <lock-scope> |
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 | <lock-scope> |
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 | <lock-scope> |
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 | <lock-scope> |
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 | <lock-scope> |
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 |

97
tests/acceptance/features/coreApiWebdavLocks/requestsWithToken.feature
View File

@@ -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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
And user "Alice" has locked folder "PARENT/CHILD" setting the following properties
| lockscope | <lock-scope> |
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> 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 | <lock-scope> |
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 | <lock-scope> |
When the public uploads file "parent.txt" with content "test" sending the locktoken of file "PARENT" of user "Alice" using the <webdav_api_version> public WebDAV API
Then the HTTP status code should be "<http_status_code>"
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> DAV path

42
tests/acceptance/features/coreApiWebdavLocks3/independentLocks.feature → tests/acceptance/features/coreApiWebdavLocks2/independentLocks.feature
View File

@@ -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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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> DAV path

45
tests/acceptance/features/coreApiWebdavLocks3/independentLocksShareToShares.feature → tests/acceptance/features/coreApiWebdavLocks2/independentLocksShareToShares.feature
View File

@@ -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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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> DAV path

110
tests/acceptance/features/coreApiWebdavLocks2/resharedSharesToRoot.feature
View File

@@ -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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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 |

122
tests/acceptance/features/coreApiWebdavLocks2/resharedSharesToShares.feature
View File

@@ -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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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 |

126
tests/acceptance/features/coreApiWebdavLocks2/setTimeout.feature
View File

@@ -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> DAV path
And parameter "lock_timeout_default" of app "core" has been set to "<default-timeout>"
And parameter "lock_timeout_max" of app "core" has been set to "<max-timeout>"
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 "<result>"
And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/CHILD" should match "<result>"
And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/parent.txt" should match "<result>"
# 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> DAV path
When user "Alice" locks folder "PARENT" using the WebDAV API setting the following properties
| lockscope | shared |
| timeout | <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 "<result>"
And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/CHILD" should match "<result>"
And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/parent.txt" should match "<result>"
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> DAV path
And parameter "lock_timeout_default" of app "core" has been set to "<default-timeout>"
And parameter "lock_timeout_max" of app "core" has been set to "<max-timeout>"
When user "Alice" locks folder "PARENT" using the WebDAV API setting the following properties
| lockscope | shared |
| timeout | <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 "<result>"
And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/CHILD" should match "<result>"
And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/parent.txt" should match "<result>"
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> 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 | <timeout> |
Then the HTTP status code should be "200"
And as a public the lock discovery property "//d:timeout" of the folder "/" should match "<result>"
And as a public the lock discovery property "//d:timeout" of the folder "/CHILD" should match "<result>"
And as a public the lock discovery property "//d:timeout" of the folder "/parent.txt" should match "<result>"
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}$/ |

62
tests/acceptance/features/coreApiWebdavLocks2/setTimeoutSharesToRoot.feature
View File

@@ -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> 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 | <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 "<result>"
And as user "Brian" the lock discovery property "//d:timeout" of the folder "PARENT (2)/CHILD" should match "<result>"
And as user "Brian" the lock discovery property "//d:timeout" of the folder "PARENT (2)/parent.txt" should match "<result>"
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> 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 | <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 "<result>"
And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/CHILD" should match "<result>"
And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/parent.txt" should match "<result>"
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}$/ |

66
tests/acceptance/features/coreApiWebdavLocks2/setTimeoutSharesToShares.feature
View File

@@ -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> 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 | <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 "<result>"
And as user "Brian" the lock discovery property "//d:timeout" of the folder "Shares/PARENT/CHILD" should match "<result>"
And as user "Brian" the lock discovery property "//d:timeout" of the folder "Shares/PARENT/parent.txt" should match "<result>"
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> 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 | <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 "<result>"
And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/CHILD" should match "<result>"
And as user "Alice" the lock discovery property "//d:timeout" of the folder "PARENT/parent.txt" should match "<result>"
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}$/ |

91
tests/acceptance/features/coreApiWebdavLocks3/independentLocksShareToRoot.feature
View File

@@ -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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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 |

310
tests/acceptance/features/coreApiWebdavLocksUnlock/lockBreakersGroups.feature
View File

@@ -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> 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> 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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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 | <lock-scope> |
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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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 | <lock-scope> |
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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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 | <lock-scope> |
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> 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 | <lock-scope> |
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 | <lock-scope> |
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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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 |

66
tests/acceptance/features/coreApiWebdavLocksUnlock/unlock.feature
View File

@@ -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> 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 | <lock-scope> |
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> 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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
And user "Alice" has locked folder "notlocked/PARENT" setting the following properties
| lockscope | <lock-scope> |
And user "Alice" has locked file "alsonotlocked/PARENT" setting the following properties
| lockscope | <lock-scope> |
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> DAV path

143
tests/acceptance/features/coreApiWebdavLocksUnlock/unlockSharingToRoot.feature
View File

@@ -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> DAV path
And user "Alice" has locked file "PARENT/parent.txt" setting the following properties
| lockscope | <lock-scope> |
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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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> 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 | <lock-scope> |
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 |

48
tests/acceptance/features/coreApiWebdavLocksUnlock/unlockSharingToShares.feature
View File

@@ -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> 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 | <lock-scope> |
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> 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> 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 | <lock-scope> |
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 |

278
tests/acceptance/features/coreApiWebdavMove1/moveFileAsync.feature
View File

@@ -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/<destination-file-name>" 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/<destination-file-name>" 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_version> 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_version> 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_version> 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_version> 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_version> 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_version> 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$/ |

55
tests/acceptance/features/coreApiWebdavMove1/moveFileToBlacklistedNameAsync.feature
View File

@@ -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 |

59
tests/acceptance/features/coreApiWebdavMove1/moveFileToExcludedDirectoryAsync.feature
View File

@@ -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 |

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

@@ -59,51 +59,6 @@ Feature: download file
| dav_version |
| spaces |
@smokeTest @notToImplementOnOCIS
Scenario Outline: Downloading a file should serve security headers
Given using <dav_version> 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_version> 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_version> 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_version> 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
And the size of the downloaded file should be 0 bytes

20
tests/acceptance/features/coreApiWebdavOperations/listFiles.feature
View File

@@ -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 |

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

@@ -23,16 +23,6 @@ Feature: PROPFIND
| header | value |
| depth | <depth> |
Then the HTTP status code should be "<http_status>"
@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"
And the value of the item "/d:error/s:exception" in the response should be "Sabre\DAV\Exception\NotAuthenticated"

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

@@ -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"

12
tests/acceptance/features/coreApiWebdavProperties2/getFileProperties.feature
View File

@@ -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_version> 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_version> DAV path

184
tests/acceptance/features/coreApiWebdavUpload1/uploadFileAsyncUsingNewChunking.feature
View File

@@ -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 "/<file-name>" 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 "/<file-name>" should exist
And the content of file "/<file-name>" 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 |

11
tests/acceptance/features/coreApiWebdavUpload1/uploadFileToBlacklistedName.feature
View File

@@ -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_version> 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_version> DAV path

64
tests/acceptance/features/coreApiWebdavUpload1/uploadFileToBlacklistedNameAsyncUsingNewChunking.feature
View File

@@ -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 "<filename>" using the WebDAV API
Then the HTTP status code should be "403"
And as "Alice" file "<filename>" 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

67
tests/acceptance/features/coreApiWebdavUpload1/uploadFileToExcludedDirectoryAsyncUsingNewChunking.feature
View File

@@ -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 "<filename>" using the WebDAV API
Then the HTTP status code should be "403"
And as "Alice" file "<filename>" 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

62
tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingNewChunking.feature
View File

@@ -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 "<filename>" using the WebDAV API
Then the HTTP status code should be "403"
And as "Alice" file "<filename>" 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

6
tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunking.feature
View File

@@ -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"

65
tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingNewChunking.feature
View File

@@ -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 "<filename>" using the WebDAV API
Then the HTTP status code should be "403"
And as "Alice" file "<filename>" 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

193
tests/acceptance/features/coreApiWebdavUpload2/uploadFileUsingNewChunking.feature
View File

@@ -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 "/<file-name>" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "/<file-name>" should exist
And the content of file "/<file-name>" for user "Alice" should be "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 "/<file-name>" in 3 chunks with new chunking and using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "/<file-name>" should exist
And the content of file "/<file-name>" for user "Alice" should be:
"""
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 |