mirror/opencloud
1
0
Fork 0
mirror of https://github.com/opencloud-eu/opencloud.git synced 2026-01-08 21:30:07 -06:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #2341 from owncloud/review-local-api-tests

Browse Source 
[tests-only][full-ci]remove api bug demonstration scenarios that are covered by exected-to…
This commit is contained in:
Phil Davis
2021-08-03 16:28:46 +05:45
committed by GitHub
parent d30670450a 73f45deed6
commit cbe1bbf432
26 changed files with 6 additions and 1022 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
tests/acceptance/expected-failures-API-on-OCIS-storage.md
View File

@@ -16,10 +16,6 @@ Basic file management like up and download, move, copy, properties, trash, versi
#### [invalid file-names should not be created using the TUS protocol](https://github.com/owncloud/ocis/issues/1001)
#### [TUS OPTIONS requests do not reply with TUS headers when invalid password](https://github.com/owncloud/ocis/issues/1012)
- [apiWebdavUploadTUS/optionsRequest.feature:33](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L33)
- [apiWebdavUploadTUS/optionsRequest.feature:46](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L46)
#### [renaming to banned name works](https://github.com/owncloud/ocis/issues/1295)
#### [Getting information about a folder overwritten by a file gives 500 error instead of 404](https://github.com/owncloud/ocis/issues/1239)
@@ -1612,8 +1608,6 @@ Scenario Outline: Do a PROPFIND to a non-existing URL
- [apiWebdavUploadTUS/checksums.feature:218](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/checksums.feature#L218)
- [apiWebdavUploadTUS/optionsRequest.feature:7](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L7)
- [apiWebdavUploadTUS/optionsRequest.feature:20](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L20)
- [apiWebdavUploadTUS/optionsRequest.feature:33](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L33)
- [apiWebdavUploadTUS/optionsRequest.feature:46](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L46)
- [apiWebdavUploadTUS/uploadToShare.feature:173](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToShare.feature#L173)
- [apiWebdavUploadTUS/uploadToShare.feature:174](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToShare.feature#L174)
- [apiWebdavUploadTUS/uploadToShare.feature:192](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToShare.feature#L192)
@@ -1624,6 +1618,9 @@ Scenario Outline: Do a PROPFIND to a non-existing URL
- [apiWebdavUploadTUS/uploadToShare.feature:249](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToShare.feature#L249)
- [apiWebdavUploadTUS/uploadToShare.feature:289](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToShare.feature#L289)
- [apiWebdavUploadTUS/uploadToShare.feature:290](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToShare.feature#L290)
#### [TUS OPTIONS requests do not reply with TUS headers when invalid password](https://github.com/owncloud/ocis/issues/1012)
- [apiWebdavUploadTUS/optionsRequest.feature:33](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L33)
- [apiWebdavUploadTUS/optionsRequest.feature:46](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L46)
#### [Share inaccessible if folder with same name was deleted and recreated](https://github.com/owncloud/ocis/issues/1787)
- [apiShareReshareToShares1/reShare.feature:269](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiShareReshareToShares1/reShare.feature#L269)

9
tests/acceptance/expected-failures-API-on-OWNCLOUD-storage.md
View File

@@ -48,10 +48,6 @@ The following scenarios fail on OWNCLOUD storage but not on OCIS storage:
- [apiWebdavUploadTUS/uploadToNonExistingFolder.feature:60](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToNonExistingFolder.feature#L60)
- [apiWebdavUploadTUS/uploadToNonExistingFolder.feature:61](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToNonExistingFolder.feature#L61)
#### [TUS OPTIONS requests do not reply with TUS headers when invalid password](https://github.com/owncloud/ocis/issues/1012)
- [apiWebdavUploadTUS/optionsRequest.feature:33](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L33)
- [apiWebdavUploadTUS/optionsRequest.feature:46](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L46)
#### [renaming to banned name works](https://github.com/owncloud/ocis/issues/1295)
#### [Getting information about a folder overwritten by a file gives 500 error instead of 404](https://github.com/owncloud/ocis/issues/1239)
@@ -1795,8 +1791,6 @@ Scenario Outline: Do a PROPFIND to a non-existing URL
- [apiWebdavUploadTUS/checksums.feature:218](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/checksums.feature#L218)
- [apiWebdavUploadTUS/optionsRequest.feature:7](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L7)
- [apiWebdavUploadTUS/optionsRequest.feature:20](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L20)
- [apiWebdavUploadTUS/optionsRequest.feature:33](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L33)
- [apiWebdavUploadTUS/optionsRequest.feature:46](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L46)
- [apiWebdavUploadTUS/uploadToShare.feature:173](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToShare.feature#L173)
- [apiWebdavUploadTUS/uploadToShare.feature:174](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToShare.feature#L174)
- [apiWebdavUploadTUS/uploadToShare.feature:192](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToShare.feature#L192)
@@ -1807,6 +1801,9 @@ Scenario Outline: Do a PROPFIND to a non-existing URL
- [apiWebdavUploadTUS/uploadToShare.feature:249](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToShare.feature#L249)
- [apiWebdavUploadTUS/uploadToShare.feature:289](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToShare.feature#L289)
- [apiWebdavUploadTUS/uploadToShare.feature:290](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/uploadToShare.feature#L290)
#### [TUS OPTIONS requests do not reply with TUS headers when invalid password](https://github.com/owncloud/ocis/issues/1012)
- [apiWebdavUploadTUS/optionsRequest.feature:33](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L33)
- [apiWebdavUploadTUS/optionsRequest.feature:46](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiWebdavUploadTUS/optionsRequest.feature#L46)
#### [Trying to accept a share with invalid ID gives incorrect OCS and HTTP status](https://github.com/owncloud/ocis/issues/2111)
- [apiShareOperationsToShares2/shareAccessByID.feature:85](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiShareOperationsToShares2/shareAccessByID.feature#L85)

35
tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsDELETEAuth.feature
View File

@@ -1,35 +0,0 @@
@api @issue-ocis-ocs-26
# after fixing all issues delete these Scenarios and use the one from oC10 core
Feature: auth
# these endpoints are handled by the reva ocs implementation
Scenario: send DELETE requests to OCS endpoints as admin with wrong password
When the administrator requests these endpoints with "DELETE" using password "invalid" about user "Alice"
| endpoint |
| /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending/123 |
| /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending/123 |
| /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/123 |
| /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/123 |
| /ocs/v2.php/apps/files_sharing/api/v1/shares/123 |
| /ocs/v1.php/apps/files_sharing/api/v1/shares/pending/123 |
| /ocs/v2.php/apps/files_sharing/api/v1/shares/pending/123 |
| /ocs/v1.php/cloud/apps/testing |
| /ocs/v2.php/cloud/apps/testing |
| /ocs/v1.php/cloud/groups/group1 |
| /ocs/v2.php/cloud/groups/group1 |
Then the HTTP status code of responses on all endpoints should be "401"
And the OCS status code of responses on all endpoints should be "notset"
# these endpoints are handled by the ocis ocs implementation
Scenario: send DELETE requests to OCS endpoints as admin with wrong password
When the administrator requests these endpoints with "DELETE" using password "invalid" about user "Alice"
| endpoint |
| /ocs/v1.php/cloud/users/%username% |
| /ocs/v2.php/cloud/users/%username% |
| /ocs/v1.php/cloud/users/%username%/subadmins |
| /ocs/v2.php/cloud/users/%username%/subadmins |
| /ocs/v1.php/cloud/users/%username%/groups |
| /ocs/v2.php/cloud/users/%username%/groups |
Then the HTTP status code of responses on all endpoints should be "401"
And the OCS status code of responses on all endpoints should be "notset"

176
tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsGETAuth.feature
View File

@@ -1,176 +0,0 @@
@api
Feature: auth
Background:
Given user "Alice" has been created with default attributes and without skeleton files
@issue-ocis-reva-29
@issue-ocis-reva-30
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: using OCS anonymously
When a user requests these endpoints with "GET" and no authentication
| endpoint |
| /ocs/v1.php/apps/files_external/api/v1/mounts |
| /ocs/v2.php/apps/files_external/api/v1/mounts |
| /ocs/v1.php/apps/files_sharing/api/v1/remote_shares |
| /ocs/v2.php/apps/files_sharing/api/v1/remote_shares |
| /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending |
| /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending |
| /ocs/v1.php/apps/files_sharing/api/v1/shares |
| /ocs/v2.php/apps/files_sharing/api/v1/shares |
| /ocs/v1.php/cloud/apps |
| /ocs/v2.php/cloud/apps |
| /ocs/v1.php/config |
| /ocs/v2.php/config |
| /ocs/v1.php/privatedata/getattribute |
| /ocs/v2.php/privatedata/getattribute |
Then the HTTP status code of responses on all endpoints should be "401"
And the OCS status code of responses on all endpoints should be "notset"
@issue-ocis-ocs-26
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: using OCS anonymously
When a user requests these endpoints with "GET" and no authentication
| endpoint |
| /ocs/v1.php/cloud/users |
| /ocs/v2.php/cloud/users |
| /ocs/v1.php/cloud/groups |
| /ocs/v2.php/cloud/groups |
Then the HTTP status code of responses on all endpoints should be "401"
And the OCS status code of responses on all endpoints should be "997"
@issue-ocis-reva-11
@issue-ocis-reva-30
@issue-ocis-reva-31
@issue-ocis-reva-32
@issue-ocis-reva-33
@issue-ocis-reva-34
@issue-ocis-reva-35
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: using OCS with non-admin basic auth
When the user "Alice" requests these endpoints with "GET" with basic auth
| endpoint |
| /ocs/v1.php/apps/files_external/api/v1/mounts |
| /ocs/v1.php/apps/files_sharing/api/v1/remote_shares |
| /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending |
| /ocs/v1.php/privatedata/getattribute |
| /ocs/v1.php/cloud/apps |
Then the HTTP status code of responses on all endpoints should be "200"
And the OCS status code of responses on all endpoints should be "998"
When the user "Alice" requests these endpoints with "GET" with basic auth
| endpoint |
| /ocs/v1.php/config |
Then the HTTP status code of responses on all endpoints should be "200"
And the OCS status code of responses on all endpoints should be "100"
When the user "Alice" requests these endpoints with "GET" with basic auth
| endpoint |
| /ocs/v2.php/apps/files_external/api/v1/mounts |
| /ocs/v2.php/apps/files_sharing/api/v1/remote_shares |
| /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending |
# | /ocs/v1.php/apps/files_sharing/api/v1/shares | 100 | 200 |
# | /ocs/v2.php/apps/files_sharing/api/v1/shares | 100 | 200 |
| /ocs/v2.php/cloud/apps |
| /ocs/v2.php/privatedata/getattribute |
Then the HTTP status code of responses on all endpoints should be "404"
And the OCS status code of responses on all endpoints should be "998"
When the user "Alice" requests these endpoints with "GET" with basic auth
| endpoint |
| /ocs/v1.php/cloud/users |
| /ocs/v2.php/cloud/users |
| /ocs/v1.php/cloud/groups |
| /ocs/v2.php/cloud/groups |
Then the HTTP status code of responses on all endpoints should be "401"
And the OCS status code of responses on all endpoints should be "997"
When the user "Alice" requests these endpoints with "GET" with basic auth
| endpoint |
| /ocs/v2.php/config |
Then the HTTP status code of responses on all endpoints should be "200"
And the OCS status code of responses on all endpoints should be "200"
@issue-ocis-reva-29
@issue-ocis-reva-30
@issue-ocis-accounts-73
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: using OCS as normal user (username has a capital letter) with wrong password
When user "Alice" requests these endpoints with "GET" using password "invalid"
| endpoint |
| /ocs/v1.php/apps/files_external/api/v1/mounts |
| /ocs/v2.php/apps/files_external/api/v1/mounts |
| /ocs/v1.php/apps/files_sharing/api/v1/remote_shares |
| /ocs/v2.php/apps/files_sharing/api/v1/remote_shares |
| /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending |
| /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending |
| /ocs/v1.php/apps/files_sharing/api/v1/shares |
| /ocs/v2.php/apps/files_sharing/api/v1/shares |
| /ocs/v1.php/cloud/apps |
| /ocs/v2.php/cloud/apps |
| /ocs/v1.php/cloud/groups |
| /ocs/v2.php/cloud/groups |
| /ocs/v1.php/config |
| /ocs/v2.php/config |
| /ocs/v1.php/privatedata/getattribute |
| /ocs/v2.php/privatedata/getattribute |
Then the HTTP status code of responses on all endpoints should be "401"
And the OCS status code of responses on all endpoints should be "notset"
@issue-ocis-reva-29
@issue-ocis-reva-30
@issue-ocis-accounts-73
@issue-ocis-ocs-26
@smokeTest
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: using OCS as normal user (username has a capital letter) with wrong password
When user "Alice" requests these endpoints with "GET" using password "invalid"
| endpoint |
| /ocs/v1.php/cloud/users |
| /ocs/v2.php/cloud/users |
Then the HTTP status code of responses on all endpoints should be "401"
And the OCS status code of responses on all endpoints should be "notset"
@skipOnOcV10
@issue-ocis-reva-29
@issue-ocis-reva-30
@issue-ocis-accounts-73
@issue-ocis-ocs-26
@smokeTest
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: using OCS as normal user (username does not have a capital letter) with wrong password
Given user "brian" has been created with default attributes and without skeleton files
When user "brian" requests these endpoints with "GET" using password "invalid"
| endpoint |
| /ocs/v1.php/apps/files_external/api/v1/mounts |
| /ocs/v2.php/apps/files_external/api/v1/mounts |
| /ocs/v1.php/apps/files_sharing/api/v1/remote_shares |
| /ocs/v2.php/apps/files_sharing/api/v1/remote_shares |
| /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending |
| /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending |
| /ocs/v1.php/apps/files_sharing/api/v1/shares |
| /ocs/v2.php/apps/files_sharing/api/v1/shares |
| /ocs/v1.php/cloud/apps |
| /ocs/v2.php/cloud/apps |
| /ocs/v1.php/cloud/groups |
| /ocs/v2.php/cloud/groups |
| /ocs/v1.php/config |
| /ocs/v2.php/config |
| /ocs/v1.php/privatedata/getattribute |
| /ocs/v2.php/privatedata/getattribute |
Then the HTTP status code of responses on all endpoints should be "401"
And the OCS status code of responses on all endpoints should be "notset"
@skipOnOcV10
@issue-ocis-reva-29
@issue-ocis-reva-30
@issue-ocis-accounts-73
@issue-ocis-ocs-26
@smokeTest
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: using OCS as normal user (username does not have a capital letter) with wrong password
Given user "brian" has been created with default attributes and without skeleton files
When user "brian" requests these endpoints with "GET" using password "invalid"
| endpoint |
| /ocs/v1.php/cloud/users |
| /ocs/v2.php/cloud/users |
Then the HTTP status code of responses on all endpoints should be "401"
And the OCS status code of responses on all endpoints should be "notset"

43
tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsPOSTAuth.feature
View File

@@ -1,43 +0,0 @@
@api
Feature: auth
Background:
Given user "Alice" has been created with default attributes and without skeleton files
@issue-ocis-ocs-26 @issue-ocis-reva-30
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: send POST requests to OCS endpoints as normal user with wrong password
When user "Alice" requests these endpoints with "POST" including body "doesnotmatter" using password "invalid" about user "Alice"
| endpoint |
| /ocs/v1.php/apps/files_sharing/api/v1/remote_shares/pending/123 |
| /ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending/123 |
| /ocs/v1.php/apps/files_sharing/api/v1/shares |
| /ocs/v2.php/apps/files_sharing/api/v1/shares |
| /ocs/v1.php/apps/files_sharing/api/v1/shares/pending/123 |
| /ocs/v2.php/apps/files_sharing/api/v1/shares/pending/123 |
| /ocs/v1.php/cloud/apps/testing |
| /ocs/v2.php/cloud/apps/testing |
| /ocs/v1.php/cloud/groups |
| /ocs/v2.php/cloud/groups |
| /ocs/v1.php/person/check |
| /ocs/v2.php/person/check |
| /ocs/v1.php/privatedata/deleteattribute/testing/test |
| /ocs/v2.php/privatedata/deleteattribute/testing/test |
| /ocs/v1.php/privatedata/setattribute/testing/test |
| /ocs/v2.php/privatedata/setattribute/testing/test |
Then the HTTP status code of responses on all endpoints should be "401"
And the OCS status code of responses on all endpoints should be "notset"
@issue-ocis-reva-30
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: send POST requests to OCS endpoints as normal user with wrong password
When user "Alice" requests these endpoints with "POST" including body "doesnotmatter" using password "invalid" about user "Alice"
| endpoint |
| /ocs/v1.php/cloud/users |
| /ocs/v2.php/cloud/users |
| /ocs/v1.php/cloud/users/%username%/groups |
| /ocs/v2.php/cloud/users/%username%/groups |
| /ocs/v1.php/cloud/users/%username%/subadmins |
| /ocs/v2.php/cloud/users/%username%/subadmins |
Then the HTTP status code of responses on all endpoints should be "401"
And the OCS status code of responses on all endpoints should be "notset"

29
tests/acceptance/features/apiBugDemonstration/apiAuthOcs-ocsPUTAuth.feature
View File

@@ -1,29 +0,0 @@
@api
Feature: auth
@issue-ocis-reva-30
@issue-ocis-ocs-26
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: send PUT request to OCS endpoints as admin with wrong password
When the administrator requests these endpoints with "PUT" with body "doesnotmatter" using password "invalid" about user "Alice"
| endpoint |
| /ocs/v1.php/apps/files_sharing/api/v1/shares/123 |
| /ocs/v2.php/apps/files_sharing/api/v1/shares/123 |
| /ocs/v1.php/cloud/users/%username% |
| /ocs/v2.php/cloud/users/%username% |
Then the HTTP status code of responses on all endpoints should be "401"
And the OCS status code of responses on all endpoints should be "notset"
@issue-ocis-reva-30
@issue-ocis-ocs-28
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: send PUT request to OCS endpoints as admin with wrong password
When the administrator requests these endpoints with "PUT" with body "doesnotmatter" using password "invalid" about user "Alice"
| endpoint |
| /ocs/v1.php/cloud/users/%username%/disable |
| /ocs/v2.php/cloud/users/%username%/disable |
| /ocs/v1.php/cloud/users/%username%/enable |
| /ocs/v2.php/cloud/users/%username%/enable |
Then the HTTP status code of responses on all endpoints should be "401"
And the OCS status code of responses on all endpoints should be "notset"

21
tests/acceptance/features/apiBugDemonstration/apiAuthWebDav-webDavLOCKAuth.feature
View File

@@ -1,21 +0,0 @@
@api
Feature: LOCK file/folder
Background:
Given user "Alice" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "some data" to "/textfile0.txt"
And user "Alice" has uploaded file with content "some data" to "/textfile1.txt"
And user "Alice" has created folder "/PARENT"
And user "Alice" has created folder "/FOLDER"
And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt"
And user "Brian" has been created with default attributes and without skeleton files
@issue-ocis-reva-9
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: send LOCK requests to another user's webDav endpoints as normal user
When user "Brian" requests these endpoints with "LOCK" to get property "d:shared" about user "Alice"
| endpoint |
| /remote.php/dav/files/%username%/textfile0.txt |
| /remote.php/dav/files/%username%/PARENT |
| /remote.php/dav/files/%username%/PARENT/parent.txt |
Then the HTTP status code of responses on all endpoints should be "200"

20
tests/acceptance/features/apiBugDemonstration/apiAuthWebDav-webDavMOVEAuth.feature
View File

@@ -1,20 +0,0 @@
@api
Feature: MOVE file/folder
Background:
Given user "Alice" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "some data" to "/textfile0.txt"
And user "Alice" has created folder "/PARENT"
And user "Alice" has created folder "/FOLDER"
And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt"
And user "Brian" has been created with default attributes and without skeleton files
@issue-ocis-reva-14
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: send MOVE requests to another user's webDav endpoints as normal user
When user "Brian" requests these endpoints with "MOVE" including body "doesnotmatter" about user "Alice"
| endpoint |
| /remote.php/dav/files/%username%/textfile0.txt |
| /remote.php/dav/files/%username%/PARENT |
| /remote.php/dav/files/%username%/PARENT/parent.txt |
Then the HTTP status code of responses on all endpoints should be "400"

48
tests/acceptance/features/apiBugDemonstration/apiCapabilities-capabilitiesWithNormalUser.feature
View File

@@ -1,48 +0,0 @@
@api @files_sharing-app-required
Feature: default capabilities for normal user
Background:
Given using OCS API version "1"
And user "Alice" has been created with default attributes and without skeleton files
@issue-ocis-reva-175 @issue-ocis-reva-176
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: getting default capabilities with normal user
When user "Alice" retrieves the capabilities using the capabilities API
Then the capabilities should contain
| capability | path_to_element | value |
| core | pollinterval | 60 |
| core | webdav-root | remote.php/webdav |
| core | status@@@edition | %edition% |
| core | status@@@productname | reva |
| core | status@@@version | 10.0.11.5 |
| core | status@@@versionstring | 10.0.11 |
| files_sharing | api_enabled | 1 |
| files_sharing | default_permissions | 22 |
| files_sharing | search_min_length | 3 |
| files_sharing | public@@@enabled | 1 |
| files_sharing | public@@@multiple | 1 |
| files_sharing | public@@@upload | 1 |
| files_sharing | public@@@supports_upload_only | 1 |
| files_sharing | public@@@send_mail | 1 |
| files_sharing | public@@@social_share | 1 |
| files_sharing | public@@@enforced | EMPTY |
| files_sharing | public@@@enforced_for@@@read_only | EMPTY |
| files_sharing | public@@@enforced_for@@@read_write | EMPTY |
| files_sharing | public@@@enforced_for@@@upload_only | EMPTY |
| files_sharing | public@@@enforced_for@@@read_write_delete | EMPTY |
| files_sharing | public@@@expire_date@@@enabled | 0 |
| files_sharing | public@@@defaultPublicLinkShareName | EMPTY |
| files_sharing | resharing | 1 |
| files_sharing | federation@@@outgoing | 1 |
| files_sharing | federation@@@incoming | 1 |
| files_sharing | group_sharing | 1 |
| files_sharing | share_with_group_members_only | 1 |
| files_sharing | share_with_membership_groups_only | 1 |
| files_sharing | auto_accept_share | 1 |
| files_sharing | user_enumeration@@@enabled | 1 |
| files_sharing | user_enumeration@@@group_members_only | 1 |
| files_sharing | user@@@send_mail | 1 |
| files | bigfilechunking | 0 |
| files | privateLinks | 0 |
| files | privateLinksDetailsParam | EMPTY |

8
tests/acceptance/features/apiBugDemonstration/apiMain-main.feature
View File

@@ -1,8 +0,0 @@
@api
Feature: Other tests related to api
@issue-ocis-reva-100
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: robots.txt file should be accessible
When a user requests "/robots.txt" with "GET" and no authentication
Then the HTTP status code should be "401" or "404"

117
tests/acceptance/features/apiBugDemonstration/apiShareManagementBasic-createShare.feature
View File

@@ -1,117 +0,0 @@
@api @files_sharing-app-required
Feature: sharing
Background:
Given user "Alice" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
@skipOnOcis-OC-Storage @skipOnOcis-OCIS-Storage @issue-ocis-reva-301 @issue-ocis-reva-302
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Creating a share of a file with a user and asking for various permission combinations
Given using OCS API version "<ocs_api_version>"
And user "Brian" has been created with default attributes and without skeleton files
When user "Alice" shares file "textfile0.txt" with user "Brian" with permissions <requested_permissions> 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% |
| file_target | /textfile0.txt |
| path | /textfile0.txt |
| permissions | <granted_permissions> |
| uid_owner | %username% |
| displayname_owner | |
| item_type | file |
| mimetype | application/octet-stream |
| storage_id | ANY_VALUE |
| share_type | user |
And the fields of the last response should not include
| share_with_displayname | %displayname% |
Examples:
| ocs_api_version | requested_permissions | granted_permissions | ocs_status_code |
# Ask for full permissions. You get share plus read plus update. create and delete do not apply to shares of a file
| 1 | 31 | 19 | 100 |
| 2 | 31 | 19 | 200 |
# Ask for read, share (17), create and delete. You get share plus read
| 1 | 29 | 17 | 100 |
| 2 | 29 | 17 | 200 |
# Ask for read, update, create, delete. You get read plus update.
| 1 | 15 | 3 | 100 |
| 2 | 15 | 3 | 200 |
# Ask for just update. You get exactly update (you do not get read or anything else)
| 1 | 2 | 2 | 100 |
| 2 | 2 | 2 | 200 |
@issue-ocis-reva-243
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: more tests to demonstrate different ocis-reva issue 243 behaviours
Given using OCS API version "<ocs_api_version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "/home"
And user "Alice" has uploaded file with content "Random data" to "/home/randomfile.txt"
When user "Alice" shares file "/home/randomfile.txt" with user "Brian" using the sharing API
And the HTTP status code should be "<http_status_code_ocs>" or "<http_status_code_eos>"
And as "Brian" file "randomfile.txt" should not exist
Examples:
| ocs_api_version | http_status_code_ocs | http_status_code_eos |
| 1 | 200 | 500 |
| 2 | 200 | 500 |
@skipOnOcis-OC-Storage @skipOnOcis-OCIS-Storage @issue-ocis-reva-301 @issue-ocis-reva-302
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Creating a share of a folder with a user, the default permissions are all permissions(31)
Given using OCS API version "<ocs_api_version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "/FOLDER"
When user "Alice" shares folder "/FOLDER" with user "Brian" using the sharing API
Then the OCS status code should be "<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% |
| file_target | /FOLDER |
| path | /FOLDER |
| permissions | all |
| uid_owner | %username% |
| displayname_owner | |
| item_type | folder |
| mimetype | httpd/unix-directory |
| storage_id | ANY_VALUE |
| share_type | user |
And the fields of the last response should not include
| share_with_displayname | %displayname% |
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
@issue-ocis-reva-372 @issue-ocis-reva-243 @skipOnOcis-OCIS-Storage
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: sharing subfolder of already shared folder, GET result is correct
Given using OCS API version "<ocs_api_version>"
And these users have been created with default attributes and without skeleton files:
| username |
| Brian |
| Carol |
| David |
| Emily |
And user "Alice" has created folder "/folder1"
And user "Alice" has shared folder "/folder1" with user "Brian"
And user "Alice" has shared folder "/folder1" with user "Carol"
And user "Alice" has created folder "/folder1/folder2"
And user "Alice" has shared folder "/folder1/folder2" with user "David"
And user "Alice" has shared folder "/folder1/folder2" with user "Emily"
When user "Alice" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/shares"
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
And the response should contain 4 entries
And folder "/folder1" should be included as path in the response
# And folder "/folder1/folder2" should be included as path in the response
And folder "/folder2" should be included as path in the response
And user "Alice" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/shares?path=/folder1/folder2"
And the response should contain 2 entries
And folder "/folder1" should not be included as path in the response
# And folder "/folder1/folder2" should be included as path in the response
And folder "/folder2" should be included as path in the response
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |

37
tests/acceptance/features/apiBugDemonstration/apiShareOperations-gettingShares.feature
View File

@@ -1,37 +0,0 @@
@api @files_sharing-app-required
Feature: sharing
Background:
Given these users have been created with default attributes and small skeleton files:
| username |
| Alice |
| Brian |
@issue-ocis-reva-374
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Get a share with a user that didn't receive the share
Given using OCS API version "<ocs_api_version>"
And user "Carol" has been created with default attributes and without skeleton files
And user "Alice" has shared file "textfile0.txt" with user "Brian"
When user "Carol" gets the info of the last share using the sharing API
Then the OCS status code should be "998"
# Then the OCS status code should be "404"
And the HTTP status code should be "<http_status_code>"
Examples:
| ocs_api_version | http_status_code |
| 1 | 200 |
| 2 | 404 |
@issue-ocis-reva-372
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: getting all the shares inside the folder
Given using OCS API version "<ocs_api_version>"
And user "Alice" has shared file "PARENT/parent.txt" with user "Brian"
When user "Alice" gets all the shares inside the folder "PARENT/parent.txt" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
And file "parent.txt" should be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |

22
tests/acceptance/features/apiBugDemonstration/apiSharePublicLink2-copyFromPublicLink.feature
View File

@@ -1,22 +0,0 @@
@api @files_sharing-app-required @public_link_share-feature-required @issue-ocis-reva-310
Feature: copying from public link share
Background:
Given user "Alice" has been created with default attributes and without skeleton files
And user "Alice" has created folder "/PARENT"
And the administrator has enabled DAV tech_preview
@issue-ocis-reva-373 @issue-core-37683 @skipOnOcis-OCIS-Storage
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: Copy file within a public link folder to a file with name same as an existing folder
Given user "Alice" has uploaded file with content "some data" to "/PARENT/testfile.txt"
And user "Alice" has created folder "/PARENT/new-folder"
And user "Alice" has uploaded file with content "some data 1" to "/PARENT/new-folder/testfile1.txt"
And user "Alice" has created a public link share with settings
| path | /PARENT |
| permissions | read,update,create,delete |
When the public copies file "/testfile.txt" to "/new-folder" using the new public WebDAV API
Then the HTTP status code should be "204"
And as "Alice" file "/PARENT/testfile.txt" should exist
And as "Alice" file "/PARENT/new-folder" should exist
And the content of file "/PARENT/testfile.txt" for user "Alice" should be "some data"

75
tests/acceptance/features/apiBugDemonstration/apiShareUpdate-updateShare.feature
View File

@@ -1,75 +0,0 @@
@api @files_sharing-app-required
Feature: sharing
Background:
Given using OCS API version "1"
And user "Alice" has been created with default attributes and without skeleton files
@skipOnOcis-EOS-Storage @issue-ocis-reva-243 @skipOnOcis-OCIS-Storage
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: Share ownership change after moving a shared file to another share
Given these users have been created with default attributes and without skeleton files:
| username |
| Brian |
| Carol |
And user "Alice" has created folder "/Alice-folder"
And user "Alice" has created folder "/Alice-folder/folder2"
And user "Carol" has created folder "/Carol-folder"
And user "Alice" has shared folder "/Alice-folder" with user "Brian" with permissions "all"
And user "Carol" has shared folder "/Carol-folder" with user "Brian" with permissions "all"
When user "Brian" moves folder "/Alice-folder/folder2" to "/Carol-folder/folder2" using the WebDAV API
And user "Carol" gets the info of the last share using the sharing API
# Note: in the following fields, file_parent has been removed because OCIS does not report that
Then the fields of the last response to user "Carol" sharing with user "Brian" should include
| id | A_STRING |
| item_type | folder |
| item_source | A_STRING |
| share_type | user |
| file_source | A_STRING |
| file_target | /Carol-folder |
| permissions | all |
| stime | A_NUMBER |
| storage | A_STRING |
| mail_send | 0 |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| mimetype | httpd/unix-directory |
# Really folder2 should be gone from Alice-folder and be found in Carol-folder
# like in these 2 suggested steps:
# And as "Alice" folder "/Alice-folder/folder2" should not exist
# And as "Carol" folder "/Carol-folder/folder2" should exist
#
# But this happens on OCIS:
And as "Alice" folder "/Alice-folder/folder2" should exist
And as "Carol" folder "/Carol-folder/folder2" should not exist
@skipOnOcis-OC-Storage @issue-ocis-reva-243 @skipOnOcis-OCIS-Storage
# same as oC10 core Scenario but without displayname_owner because EOS does not report it
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: Share ownership change after moving a shared file to another share
Given these users have been created with default attributes and without skeleton files:
| username |
| Brian |
| Carol |
And user "Alice" has created folder "/Alice-folder"
And user "Alice" has created folder "/Alice-folder/folder2"
And user "Carol" has created folder "/Carol-folder"
And user "Alice" has shared folder "/Alice-folder" with user "Brian" with permissions "all"
And user "Carol" has shared folder "/Carol-folder" with user "Brian" with permissions "all"
When user "Brian" moves folder "/Alice-folder/folder2" to "/Carol-folder/folder2" using the WebDAV API
And user "Carol" gets the info of the last share using the sharing API
Then the fields of the last response to user "Carol" sharing with user "Brian" should include
| id | A_STRING |
| item_type | folder |
| item_source | A_STRING |
| share_type | user |
| file_source | A_STRING |
| file_target | /Carol-folder |
| permissions | all |
| stime | A_NUMBER |
| storage | A_STRING |
| mail_send | 0 |
| uid_owner | %username% |
| mimetype | httpd/unix-directory |
And as "Alice" folder "/Alice-folder/folder2" should exist
And as "Carol" folder "/Carol-folder/folder2" should not exist

14
tests/acceptance/features/apiBugDemonstration/apiTrashbin-trashbinDelete.feature
View File

@@ -1,14 +0,0 @@
@api @files_trashbin-app-required
Feature: files and folders can be deleted from the trashbin
As a user
I want to delete files and folders from the trashbin
So that I can control my trashbin space and which files are kept in that space
Background:
Given user "Alice" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "to delete" to "/textfile0.txt"
And user "Alice" has uploaded file with content "to delete" to "/textfile1.txt"
And user "Alice" has created folder "PARENT"
And user "Alice" has created folder "PARENT/CHILD"
And user "Alice" has uploaded file with content "to delete" to "/PARENT/parent.txt"
And user "Alice" has uploaded file with content "to delete" to "/PARENT/CHILD/child.txt"

101
tests/acceptance/features/apiBugDemonstration/apiVersions-fileVersions.feature
View File

@@ -1,101 +0,0 @@
@api @files_versions-app-required @skipOnOcis-EOS-Storage @issue-ocis-reva-275
Feature: dav-versions
Background:
Given using OCS API version "2"
And using new DAV path
And user "Alice" has been created with default attributes and without skeleton files
@issue-ocis-reva-17 @issue-ocis-reva-56
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: Upload file and no version is available using various chunking methods
When user "Alice" uploads file "filesForUpload/davtest.txt" to filenames based on "/davtest.txt" with all mechanisms using the WebDAV API
Then the version folder of file "/davtest.txt-olddav-regular" for user "Alice" should contain "0" elements
Then the version folder of file "/davtest.txt-newdav-regular" for user "Alice" should contain "0" elements
Then the version folder of file "/davtest.txt-olddav-oldchunking" for user "Alice" should contain "0" elements
And as "Alice" file "/davtest.txt-newdav-newchunking" should not exist
@files_sharing-app-required
@issue-ocis-reva-243
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: sharer of a file can see the old version information when the sharee changes the content of the file
Given user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "First content" to "sharefile.txt"
And user "Alice" has shared file "sharefile.txt" with user "Brian"
When user "Brian" has uploaded file with content "Second content" to "/sharefile.txt"
Then the HTTP status code should be "201"
And the version folder of file "/sharefile.txt" for user "Alice" should contain "0" element
# And the version folder of file "/sharefile.txt" for user "Alice" should contain "1" element
@files_sharing-app-required
@issue-ocis-reva-243
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: sharer of a file can restore the original content of a shared file after the file has been modified by the sharee
Given user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "First content" to "sharefile.txt"
And user "Alice" has shared file "sharefile.txt" with user "Brian"
And user "Brian" has uploaded file with content "Second content" to "/sharefile.txt"
When user "Alice" restores version index "0" of file "/sharefile.txt" using the WebDAV API
# When user "Alice" restores version index "1" of file "/sharefile.txt" using the WebDAV API
Then the HTTP status code should be "201"
And the content of file "/sharefile.txt" for user "Alice" should be "First content"
And the content of file "/sharefile.txt" for user "Brian" should be "Second content"
# And the content of file "/sharefile.txt" for user "Brian" should be "First content"
@files_sharing-app-required
@issue-ocis-reva-243 @issue-ocis-reva-386
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Moving a file (with versions) into a shared folder as the sharee and as the sharer
Given using <dav_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 | change |
| shareWith | Alice |
And user "Brian" has uploaded file with content "test data 1" to "/testfile.txt"
And user "Brian" has uploaded file with content "test data 2" to "/testfile.txt"
And user "Brian" has uploaded file with content "test data 3" to "/testfile.txt"
And user "Brian" moves file "/testfile.txt" to "/testshare/testfile.txt" using the WebDAV API
Then the HTTP status code should be "201"
And the content of file "/testshare/testfile.txt" for user "Alice" should be ""
# And the content of file "/testshare/testfile.txt" for user "Alice" should be "test data 3"
And the content of file "/testshare/testfile.txt" for user "Brian" should be "test data 3"
And as "Brian" file "/testfile.txt" should not exist
And as "Alice" file "/testshare/testfile.txt" should not exist
And the content of file "/testshare/testfile.txt" for user "Brian" should be "test data 3"
# And the version folder of file "/testshare/testfile.txt" for user "Alice" should contain "2" elements
# And the version folder of file "/testshare/testfile.txt" for user "Brian" should contain "2" elements
Examples:
| dav_version |
| old |
| new |
@files_sharing-app-required
@issue-ocis-reva-243 @issue-ocis-reva-386
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Moving a file (with versions) out of a shared folder as the sharee and as the sharer
Given using <dav_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 uploaded file with content "test data 1" to "/testshare/testfile.txt"
And user "Brian" has uploaded file with content "test data 2" to "/testshare/testfile.txt"
And user "Brian" has uploaded file with content "test data 3" to "/testshare/testfile.txt"
And user "Brian" has created a share with settings
| path | testshare |
| shareType | user |
| permissions | change |
| shareWith | Alice |
When user "Brian" moves file "/testshare/testfile.txt" to "/testfile.txt" using the WebDAV API
Then the HTTP status code should be "201"
And the content of file "/testfile.txt" for user "Brian" should be "test data 3"
And as "Alice" file "/testshare/testfile.txt" should not exist
And as "Brian" file "/testshare/testfile.txt" should not exist
# And the version folder of file "/testfile.txt" for user "Brian" should contain "2" elements
Examples:
| dav_version |
| old |
| new |

9
tests/acceptance/features/apiBugDemonstration/apiWebdavMove1-moveFolder.feature
View File

@@ -1,9 +0,0 @@
@api @issue-ocis-reva-14
Feature: move (rename) folder
As a user
I want to be able to move and rename folders
So that I can quickly manage my file system
Background:
Given using OCS API version "1"
And user "Alice" has been created with default attributes and without skeleton files

22
tests/acceptance/features/apiBugDemonstration/apiWebdavMove1-moveFolderToBlacklistedName.feature
View File

@@ -1,22 +0,0 @@
@api @issue-ocis-reva-14
Feature: users cannot move (rename) a folder to a blacklisted name
As an administrator
I want to be able to prevent users from moving (renaming) folders to specified names
So that I can prevent unwanted folder names existing in the cloud storage
Background:
Given using OCS API version "1"
And user "Alice" has been created with default attributes and without skeleton files
@issue-ocis-reva-211 @skipOnOcis-EOS-Storage @issue-ocis-reva-269 @skipOnOcis-OCIS-Storage
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Renaming a folder to a name that is banned by default is allowed
Given using <dav_version> DAV path
And user "Alice" has created folder "/testshare"
When user "Alice" moves folder "/testshare" to "/.htaccess" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" folder "/.htaccess" should exist
Examples:
| dav_version |
| old |
| new |

22
tests/acceptance/features/apiBugDemonstration/apiWebdavMove2-moveFile.feature
View File

@@ -1,22 +0,0 @@
@api @issue-ocis-reva-14
Feature: move (rename) file
As a user
I want to be able to move and rename files
So that I can manage my file system
Background:
Given using OCS API version "1"
And user "Alice" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "text file 0" to "/textfile0.txt"
@issue-ocis-reva-211 @skipOnOcis-OCIS-Storage
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Renaming a file to a path with extension .part is possible
Given using <dav_version> DAV path
When user "Alice" moves file "/textfile0.txt" to "/textfile0.part" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "/textfile0.part" should exist
Examples:
| dav_version |
| old |
| new |

22
tests/acceptance/features/apiBugDemonstration/apiWebdavMove2-moveFileToBlacklistedName.feature
View File

@@ -1,22 +0,0 @@
@api @issue-ocis-reva-14
Feature: users cannot move (rename) a file to a blacklisted name
As an administrator
I want to be able to prevent users from moving (renaming) files to specified file names
So that I can prevent unwanted file names existing in the cloud storage
Background:
Given using OCS API version "1"
And user "Alice" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "text file 0" to "/textfile0.txt"
@issue-ocis-reva-211 @skipOnOcis-OCIS-Storage
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: rename a file to a filename that is banned by default
Given using <dav_version> DAV path
When user "Alice" moves file "/textfile0.txt" to "/.htaccess" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "/.htaccess" should exist
Examples:
| dav_version |
| old |
| new |

22
tests/acceptance/features/apiBugDemonstration/apiWebdavOperations-refuseAccess.feature
View File

@@ -1,22 +0,0 @@
@api
Feature: refuse access
As an administrator
I want to refuse access to unauthenticated and disabled users
So that I can secure the system
Background:
Given using OCS API version "1"
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Unauthenticated call
Given using <dav_version> DAV path
When an unauthenticated client connects to the dav endpoint using the WebDAV API
Then the HTTP status code should be "401"
And there should be no duplicate headers
And the following headers should be set
| header | value |
| WWW-Authenticate | Basic realm="%base_url_without_scheme%" |
Examples:
| dav_version |
| old |
| new |

37
tests/acceptance/features/apiBugDemonstration/apiWebdavProperties1-createFolder.feature
View File

@@ -1,37 +0,0 @@
@api
Feature: create folder
As a user
I want to be able to create folders
So that I can organise the files in my file system
Background:
Given using OCS API version "1"
And user "Alice" has been created with default attributes and without skeleton files
@issue-ocis-reva-168 @skipOnOcis-EOS-Storage @skipOnOcis-OCIS-Storage
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: try to create a folder that already exists
Given using <dav_version> DAV path
And user "Alice" has created folder "my-data"
When user "Alice" creates folder "my-data" using the WebDAV API
Then the HTTP status code should be "405"
And as "Alice" folder "my-data" should exist
And the body of the response should be empty
Examples:
| dav_version |
| old |
| new |
@issue-ocis-reva-168
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: try to create a folder with a name of an existing file
Given using <dav_version> DAV path
And user "Alice" has uploaded file with content "uploaded data" to "/my-data.txt"
When user "Alice" creates folder "my-data.txt" using the WebDAV API
Then the HTTP status code should be "405"
And the body of the response should be empty
And the content of file "/my-data.txt" for user "Alice" should be "uploaded data"
Examples:
| dav_version |
| old |
| new |

53
tests/acceptance/features/apiBugDemonstration/apiWebdavProperties2-getFileProperties.feature
View File

@@ -1,53 +0,0 @@
@api
Feature: get file properties
As a user
I want to be able to get meta-information about files
So that I can know file meta-information (detailed requirement TBD)
Background:
Given using OCS API version "1"
And user "Alice" has been created with default attributes and without skeleton files
@issue-ocis-reva-214 @skipOnOcis-OCIS-Storage
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Do a PROPFIND of various file names
Given using <dav_version> DAV path
And user "Alice" has uploaded file with content "uploaded content" to "<file_name>"
When user "Alice" gets the properties of file "<file_name>" using the WebDAV API
Then the properties response should contain an etag
And the value of the item "//d:response/d:href" in the response to user "Alice" should match "/remote\.php\/<expected_href>/"
Examples:
| dav_version | file_name | expected_href |
| old | /file #2.txt | webdav\/file%20%232\.txt |
| new | /file #2.txt | dav\/files\/%username%\/file%20%232\.txt |
@issue-ocis-reva-214 @skipOnOcis-OCIS-Storage
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Do a PROPFIND of various folder names
Given using <dav_version> DAV path
And user "Alice" has created folder "<folder_name>"
And user "Alice" has uploaded file with content "uploaded content" to "<folder_name>/file1.txt"
And user "Alice" has uploaded file with content "uploaded content" to "<folder_name>/file2.txt"
When user "Alice" gets the properties of folder "<folder_name>" with depth 1 using the WebDAV API
Then the value of the item "//d:response[1]/d:href" in the response to user "Alice" should match "/remote\.php\/<expected_href>\//"
And the value of the item "//d:response[2]/d:href" in the response to user "Alice" should match "/remote\.php\/<expected_href>\/file1.txt/"
And the value of the item "//d:response[3]/d:href" in the response to user "Alice" should match "/remote\.php\/<expected_href>\/file2.txt/"
Examples:
| dav_version | folder_name | expected_href |
| old | /upload | webdav\/upload |
| old | /folder #2.txt | webdav\/folder%20%232\.txt |
| new | /upload | dav\/files\/%username%\/upload |
| new | /folder #2.txt | dav\/files\/%username%\/folder%20%232\.txt |
@skipOnOcis-OC-Storage @issue-ocis-reva-265 @skipOnOcis-OCIS-Storage
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Do a PROPFIND of various folder names
Given using <dav_version> DAV path
And user "Alice" has created folder "/folder ?2.txt"
When user "Alice" uploads to these filenames with content "uploaded content" using the webDAV API then the results should be as listed
| filename | http-code | exists |
| /folder ?2.txt/file1.txt | 500 | no |
Examples:
| dav_version |
| old |
| new |

27
tests/acceptance/features/apiBugDemonstration/apiWebdavUpload1-uploadFile.feature
View File

@@ -1,27 +0,0 @@
@api
Feature: upload file
As a user
I want to be able to upload files
So that I can store and share files between multiple client systems
Background:
Given using OCS API version "1"
And user "Alice" has been created with default attributes and without skeleton files
@skipOnOcis-OC-Storage @issue-product-127 @skipOnOcis-OCIS-Storage
# this scenario passes/fails intermittently on OC storage, so do not run it in CI
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: uploading a file inside a folder changes its etag
Given using <dav_version> DAV path
And user "Alice" has created folder "/upload"
And user "Alice" has stored etag of element "/<element>"
When user "Alice" uploads file with content "uploaded content" to "/upload/file.txt" using the WebDAV API
Then the content of file "/upload/file.txt" for user "Alice" should be "uploaded content"
# And the etag of element "/<element>" of user "Alice" should have changed
And the etag of element "/<element>" of user "Alice" should not have changed
Examples:
| dav_version | element |
| old | |
| old | upload |
| new | |
| new | upload |

29
tests/acceptance/features/apiBugDemonstration/apiWebdavUploadTUS-optionsRequest.feature
View File

@@ -1,29 +0,0 @@
@api @issue-ocis-1012
# after fixing all issues delete these Scenarios and use the one from oC10 core
Feature: OPTIONS request
Background:
Given user "Alice" has been created with default attributes and without skeleton files
Scenario: send OPTIONS request to webDav endpoints using the TUS protocol with valid username and wrong password
When user "Alice" requests these endpoints with "OPTIONS" including body "doesnotmatter" using password "invalid" about user "Alice"
| endpoint |
| /remote.php/webdav/ |
| /remote.php/dav/files/%username%/ |
Then the following headers should not be set
| header |
| Tus-Resumable |
| Tus-Version |
| Tus-Extension |
Scenario: send OPTIONS requests to webDav endpoints using valid password and username of different user
Given user "Brian" has been created with default attributes and without skeleton files
When user "Brian" requests these endpoints with "OPTIONS" including body "doesnotmatter" using the password of user "Alice"
| endpoint |
| /remote.php/webdav/ |
| /remote.php/dav/files/%username%/ |
Then the following headers should not be set
| header |
| Tus-Resumable |
| Tus-Version |
| Tus-Extension |

21
tests/acceptance/features/apiBugDemonstration/apiWebdavUploadTUS-uploadFile.feature
View File

@@ -1,21 +0,0 @@
@api @issue-ocis-1141
# after fixing all issues delete these Scenarios and use the one from oC10 core
Feature: upload file
As a user
I want to be able to upload files
So that I can store and share files between multiple client systems
Scenario Outline: upload a file using the resource URL of another user
Given using <dav_version> DAV path
And user "Alice" has been created with default attributes and without skeleton files
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created a new TUS resource on the WebDAV API with these headers:
| Upload-Length | 5 |
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
When user "Brian" sends a chunk to the last created TUS Location with offset "0" and data "12345" using the WebDAV API
Then the HTTP status code should be "204"
And as "Alice" file "/textFile.txt" should exist
Examples:
| dav_version |
| old |
| new |