mirror/opencloud
1
0
Fork 0
mirror of https://github.com/opencloud-eu/opencloud.git synced 2026-01-04 11:19:39 -06:00
Code Issues Packages Projects Releases Wiki Activity

[Tests-Only] Add bug demo scenarios

Browse Source
This commit is contained in:
Phil Davis
2020-08-11 14:15:57 +05:45
parent 2c4727d79e
commit 83d5370a1c
36 changed files with 1365 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
.drone.star
View File

@@ -85,7 +85,7 @@ def testPipelines(ctx):
pipelines = [
linting(ctx),
unitTests(ctx),
localApiTests(ctx, config['apiTests']['coreBranch'], config['apiTests']['coreCommit'])
localApiTestsOcStorage(ctx, config['apiTests']['coreBranch'], config['apiTests']['coreCommit'])
]
for runPart in range(1, config['apiTests']['numberOfParts'] + 1):
@@ -203,11 +203,11 @@ def unitTests(ctx):
},
}
def localApiTests(ctx, coreBranch = 'master', coreCommit = ''):
def localApiTestsOcStorage(ctx, coreBranch = 'master', coreCommit = ''):
return {
'kind': 'pipeline',
'type': 'docker',
'name': 'localApiTests',
'name': 'localApiTestsOcStorage',
'platform': {
'os': 'linux',
'arch': 'amd64',
@@ -218,7 +218,7 @@ def localApiTests(ctx, coreBranch = 'master', coreCommit = ''):
ocisServer() +
cloneCoreRepos(coreBranch, coreCommit) + [
{
'name': 'LocalApiTests',
'name': 'localApiTestsOcStorage',
'image': 'owncloudci/php:7.2',
'pull': 'always',
'environment' : {
@@ -228,6 +228,7 @@ def localApiTests(ctx, coreBranch = 'master', coreCommit = ''):
'TEST_EXTERNAL_USER_BACKENDS':'true',
'REVA_LDAP_HOSTNAME':'ldap',
'TEST_OCIS':'true',
'BEHAT_FILTER_TAGS': '~@skipOnOcis-OC-Storage',
'PATH_TO_CORE': '/srv/app/testrunner'
},
'commands': [
@@ -462,7 +463,7 @@ def docker(ctx, arch):
'depends_on': [
'linting',
'unitTests',
'localApiTests',
'localApiTestsOcStorage',
] + getCoreApiTestPipelineNames() + getUITestSuiteNames(),
'trigger': {
'ref': [
@@ -608,7 +609,7 @@ def binary(ctx, name):
'depends_on': [
'linting',
'unitTests',
'localApiTests',
'localApiTestsOcStorage',
] + getCoreApiTestPipelineNames() + getUITestSuiteNames(),
'trigger': {
'ref': [

4
tests/acceptance/config/behat.yml
View File

@@ -21,7 +21,11 @@ default:
adminPassword: admin
regularUserPassword: 123456
ocPath: apps/testing/api/v1/occ
- CapabilitiesContext:
- ChecksumContext:
- FavoritesContext:
- FilesVersionsContext:
- PublicWebDavContext:
- WebDavPropertiesContext:
extensions:

0
tests/acceptance/features/apiOcisSpecific/ocsDELETEAuth.feature → tests/acceptance/features/apiOcisSpecific/apiAuthOcs-ocsDELETEAuth.feature
View File

0
tests/acceptance/features/apiOcisSpecific/ocsGETAuth.feature → tests/acceptance/features/apiOcisSpecific/apiAuthOcs-ocsGETAuth.feature
View File

0
tests/acceptance/features/apiOcisSpecific/ocsPOSTAuth.feature → tests/acceptance/features/apiOcisSpecific/apiAuthOcs-ocsPOSTAuth.feature
View File

0
tests/acceptance/features/apiOcisSpecific/ocsPUTAuth.feature → tests/acceptance/features/apiOcisSpecific/apiAuthOcs-ocsPUTAuth.feature
View File

21
tests/acceptance/features/apiOcisSpecific/apiAuthWebDav-webDavLOCKAuth.feature Normal file
View File

@@ -0,0 +1,21 @@
@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/apiOcisSpecific/apiAuthWebDav-webDavMOVEAuth.feature Normal file
View File

@@ -0,0 +1,20 @@
@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"

20
tests/acceptance/features/apiOcisSpecific/apiAuthWebDav-webDavPROPFINDAuth.feature Normal file
View File

@@ -0,0 +1,20 @@
@api
Feature: get file info using PROPFIND
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-9 @skipOnOcis-EOS-Storage @issue-ocis-reva-303
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: send PROPFIND requests to another user's webDav endpoints as normal user
When user "Brian" requests these endpoints with "PROPFIND" to get property "d:getetag" 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 "207"

48
tests/acceptance/features/apiOcisSpecific/apiCapabilities-capabilitiesWithNormalUser.feature Normal file
View File

@@ -0,0 +1,48 @@
@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 | 1 |
| 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 |

25
tests/acceptance/features/apiOcisSpecific/apiFavorites-favorites.feature Normal file
View File

@@ -0,0 +1,25 @@
@api
Feature: favorite
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 "some data" to "/textfile0.txt"
And user "Alice" has uploaded file with content "some data" to "/textfile1.txt"
And user "Alice" has uploaded file with content "some data" to "/textfile2.txt"
And user "Alice" has uploaded file with content "some data" to "/textfile3.txt"
And user "Alice" has uploaded file with content "some data" to "/textfile4.txt"
And user "Alice" has created folder "/FOLDER"
And user "Alice" has created folder "/PARENT"
And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt"
@skipOnOcis-OC-Storage @issue-ocis-reva-276
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Favorite a folder
Given using <dav_version> DAV path
When user "Alice" favorites element "/FOLDER" using the WebDAV API
Then the HTTP status code should be "500"
Examples:
| dav_version |
| old |
| new |

57
tests/acceptance/features/apiOcisSpecific/apiMain-checksums.feature Normal file
View File

@@ -0,0 +1,57 @@
@api
Feature: checksums
Background:
Given user "Alice" has been created with default attributes and without skeleton files
@issue-ocis-reva-98
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Uploading a file with checksum should return the checksum in the download header
Given using <dav_version> DAV path
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a"
When user "Alice" downloads file "/myChecksumFile.txt" using the WebDAV API
Then the following headers should not be set
| header |
| OC-Checksum |
Examples:
| dav_version |
| old |
| new |
@issue-ocis-reva-98
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: Copying file with checksum should return the checksum in the download header using new DAV path
Given using new DAV path
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a"
When user "Alice" copies file "/myChecksumFile.txt" to "/myChecksumFileCopy.txt" using the WebDAV API
And user "Alice" downloads file "/myChecksumFileCopy.txt" using the WebDAV API
Then the following headers should not be set
| header |
| OC-Checksum |
@issue-ocis-reva-99
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Upload a file where checksum does not match
Given using <dav_version> DAV path
When user "Alice" uploads file with checksum "SHA1:f005ba11" and content "Some Text" to "/chksumtst.txt" using the WebDAV API
Then the HTTP status code should be "201"
And user "Alice" should see the following elements
| /chksumtst.txt |
Examples:
| dav_version |
| old |
| new |
@issue-ocis-reva-99
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Uploaded file 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 "/chksumtst.txt"
When user "Alice" downloads file "/chksumtst.txt" using the WebDAV API
Then the following headers should not be set
| header |
| OC-Checksum |
Examples:
| dav_version |
| old |
| new |

8
tests/acceptance/features/apiOcisSpecific/apiMain-main.feature Normal file
View File

@@ -0,0 +1,8 @@
@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"

45
tests/acceptance/features/apiOcisSpecific/apiShareCreateSpecial2-createShareWithInvalidPermissions.feature Normal file
View File

@@ -0,0 +1,45 @@
@api @files_sharing-app-required @issue-ocis-reva-243
Feature: cannot share resources with invalid permissions
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"
@issue-ocis-reva-45 @issue-ocis-reva-243
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Cannot create a share of a file with a user with only create permission
Given using OCS API version "<ocs_api_version>"
And user "Brian" has been created with default attributes and without skeleton files
When user "Alice" creates a share using the sharing API with settings
| path | textfile0.txt |
| shareWith | Brian |
| shareType | user |
| permissions | create |
Then the OCS status code should be "<ocs_status_code>" or "<eos_status_code>"
And the HTTP status code should be "<http_status_code_ocs>" or "<http_status_code_eos>"
And as "Brian" entry "textfile0.txt" should not exist
Examples:
| ocs_api_version | ocs_status_code | eos_status_code | http_status_code_ocs | http_status_code_eos |
| 1 | 100 | 996 | 200 | 500 |
| 2 | 200 | 996 | 200 | 500 |
@issue-ocis-reva-45 @issue-ocis-reva-243
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Cannot create a share of a file with a user with only (create,delete) permission
Given using OCS API version "<ocs_api_version>"
And user "Brian" has been created with default attributes and without skeleton files
When user "Alice" creates a share using the sharing API with settings
| path | textfile0.txt |
| shareWith | Brian |
| shareType | user |
| permissions | <permissions> |
Then the OCS status code should be "<ocs_status_code>" or "<eos_status_code>"
And the HTTP status code should be "<http_status_code_ocs>" or "<http_status_code_eos>"
And as "Brian" entry "textfile0.txt" should not exist
Examples:
| ocs_api_version | eos_status_code | ocs_status_code | http_status_code_ocs | http_status_code_eos | permissions |
| 1 | 100 | 996 | 200 | 500 | delete |
| 2 | 200 | 996 | 200 | 500 | delete |
| 1 | 100 | 996 | 200 | 500 | create,delete |
| 2 | 200 | 996 | 200 | 500 | create,delete |

117
tests/acceptance/features/apiOcisSpecific/apiShareManagementBasic-createShare.feature Normal file
View File

@@ -0,0 +1,117 @@
@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 @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 @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
# 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 "<http_status_code>"
# On OCIS and reva the response is currently not there
# 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 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 "/folder2" should be included as path in the response
# And folder "/folder1/folder2" should be included as path in the response
Examples:
| ocs_api_version | http_status_code | ocs_status_code |
| 1 | 200 | 996 |
| 2 | 500 | 996 |

17
tests/acceptance/features/apiOcisSpecific/apiShareManagementBasic-deleteShare.feature Normal file
View File

@@ -0,0 +1,17 @@
@api @files_sharing-app-required @issue-ocis-reva-243
Feature: sharing
@issue-ocis-reva-356
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: delete a share
Given user "Alice" has been created with default attributes and skeleton files
And user "Brian" has been created with default attributes and without skeleton files
And using OCS API version "<ocs_api_version>"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
When user "Alice" deletes the last share using the sharing API
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |

23
tests/acceptance/features/apiOcisSpecific/apiShareOperations-accessToShare.feature Normal file
View File

@@ -0,0 +1,23 @@
@api @files_sharing-app-required
Feature: sharing
Background:
Given these users have been created with default attributes and skeleton files:
| username |
| Alice |
| Brian |
@issue-ocis-reva-260
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Sharee can't see the share that is filtered out
Given using OCS API version "<ocs_api_version>"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
And user "Alice" has shared file "textfile1.txt" with user "Brian"
When user "Brian" gets all the shares shared with him that are received as file "textfile0 (2).txt" using the provisioning API
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
And the last share_id should be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |

23
tests/acceptance/features/apiOcisSpecific/apiShareOperations-getWebDAVSharePermissions.feature Normal file
View File

@@ -0,0 +1,23 @@
@api @files_sharing-app-required @issue-ocis-reva-47
Feature: sharing
Background:
Given using OCS API version "1"
And these users have been created with default attributes and without skeleton files:
| username |
| Alice |
| Brian |
@issue-ocis-reva-47
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Empty webdav share-permissions for owned file
Given using <dav-path> DAV path
And user "Alice" has uploaded file with content "foo" to "/tmp.txt"
When user "Alice" gets the following properties of file "/tmp.txt" using the WebDAV API
| propertyName |
| ocs:share-permissions |
Then the single response should contain a property "ocs:share-permissions" with value "5"
Examples:
| dav-path |
| old |
| new |

37
tests/acceptance/features/apiOcisSpecific/apiShareOperations-gettingShares.feature Normal file
View File

@@ -0,0 +1,37 @@
@api @files_sharing-app-required
Feature: sharing
Background:
Given these users have been created with default attributes and 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 |

31
tests/acceptance/features/apiOcisSpecific/apiSharePublicLink1-createPublicLinkShare.feature Normal file
View File

@@ -0,0 +1,31 @@
@api @files_sharing-app-required @public_link_share-feature-required @skipOnOcis-EOS-Storage @issue-ocis-reva-315 @issue-ocis-reva-316
Feature: create a public link share
Background:
Given user "Alice" has been created with default attributes and skeleton files
@issue-37605
# after fixing all issues make the oC10 scenario like this one, and delete this scenario
Scenario: Get the mtime of a file inside a folder shared by public link using new webDAV version (run on OCIS)
Given user "Alice" has created folder "testFolder"
And user "Alice" has created a public link share with settings
| path | /testFolder |
| permissions | read,update,create,delete |
When the public uploads file "file.txt" to the last shared folder with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the new public WebDAV API
Then as "Alice" file "testFolder/file.txt" should exist
And as "Alice" the mtime of the file "testFolder/file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT"
And the mtime of file "file.txt" in the last shared public link using the WebDAV API should be "Thu, 08 Aug 2019 04:18:13 GMT"
@issue-37605
# after fixing all issues make the oC10 scenario like this one, and delete this scenario
Scenario: overwriting a file changes its mtime (new public webDAV API) (run on OCIS)
Given user "Alice" has created folder "testFolder"
When user "Alice" uploads file with content "uploaded content for file name ending with a dot" to "testFolder/file.txt" using the WebDAV API
And user "Alice" has created a public link share with settings
| path | /testFolder |
| permissions | read,update,create,delete |
And the public uploads file "file.txt" to the last shared folder with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the new public WebDAV API
Then as "Alice" file "/testFolder/file.txt" should exist
And as "Alice" the mtime of the file "testFolder/file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT"
And the mtime of file "file.txt" in the last shared public link using the WebDAV API should be "Thu, 08 Aug 2019 04:18:13 GMT"

67
tests/acceptance/features/apiOcisSpecific/apiSharePublicLink2-copyFromPublicLink.feature Normal file
View File

@@ -0,0 +1,67 @@
@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
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: Copy folder within a public link folder to the same folder name as an already existing file
Given user "Alice" has created folder "/PARENT/testFolder"
And user "Alice" has uploaded file with content "some data" to "/PARENT/testFolder/testfile.txt"
And user "Alice" has uploaded file with content "some data 1" to "/PARENT/copy1.txt"
And user "Alice" has created a public link share with settings
| path | /PARENT |
| permissions | read,update,create,delete |
When the public copies folder "/testFolder" to "/copy1.txt" using the new public WebDAV API
Then the HTTP status code should be "204"
And as "Alice" folder "/PARENT/testFolder" should exist
And as "Alice" file "/PARENT/copy1.txt" should exist
And the content of file "/PARENT/testFolder/testfile.txt" for user "Alice" should be "some data"
And the content of file "/PARENT/copy1.txt" for user "Alice" should be "some data 1"
@issue-ocis-reva-373 @issue-core-37683
# 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"
@issue-ocis-reva-368
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Copy file within a public link folder to a file with unusual destination names
Given user "Alice" has uploaded file with content "some data" to "/PARENT/testfile.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 "/<destination-file-name>" using the new public WebDAV API
Then the HTTP status code should be "204"
And as "Alice" file "/PARENT/<destination-file-name>" should exist
And the content of file "/PARENT/<destination-file-name>" for user "Alice" should be "some data"
Examples:
| destination-file-name |
| testfile.txt |
| |
@issue-ocis-reva-368
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: Copy folder within a public link folder to a folder with unusual destination names
Given user "Alice" has created folder "/PARENT/testFolder"
And user "Alice" has uploaded file with content "some data" to "/PARENT/testFolder/testfile.txt"
And user "Alice" has created a public link share with settings
| path | /PARENT |
| permissions | read,update,create,delete |
When the public copies folder "/testFolder" to "/testFolder" using the new public WebDAV API
Then the HTTP status code should be "204"
And as "Alice" folder "/PARENT/testFolder" should exist
And the content of file "/PARENT/testFolder/testfile.txt" for user "Alice" should be "some data"

47
tests/acceptance/features/apiOcisSpecific/apiSharePublicLink2-updatePublicLinkShare.feature Normal file
View File

@@ -0,0 +1,47 @@
@api @files_sharing-app-required @public_link_share-feature-required @issue-ocis-reva-252
Feature: update a public link share
Background:
Given using OCS API version "1"
And user "Alice" has been created with default attributes and skeleton files
@issue-ocis-reva-243 @issue-ocis-reva-349 @issue-37653
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: API responds with a full set of parameters when owner changes the expireDate of a public share
Given using OCS API version "<ocs_api_version>"
When user "Alice" creates a public link share using the sharing API with settings
| path | FOLDER |
And user "Alice" updates the last share using the sharing API with
| expireDate | +3 days |
Then the OCS status code should be "<ocs_status_code>"
And the OCS status message should be "OK"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" should include
| id | A_STRING |
| share_type | public_link |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| permissions | read |
| stime | A_NUMBER |
| parent | |
| expiration | A_STRING |
| token | A_STRING |
| uid_file_owner | %username% |
| displayname_file_owner | %displayname% |
| additional_info_owner | |
| additional_info_file_owner | |
| state | 0 |
| item_type | folder |
| item_source | A_STRING |
| path | /FOLDER |
| mimetype | httpd/unix-directory |
| storage_id | A_STRING |
| storage | A_NUMBER |
| file_source | A_STRING |
| file_target | /FOLDER |
| mail_send | 0 |
| name | |
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |

17
tests/acceptance/features/apiOcisSpecific/apiSharePublicLink2-uploadToPublicLinkShare.feature Normal file
View File

@@ -0,0 +1,17 @@
@api @files_sharing-app-required @public_link_share-feature-required @skipOnOcis-EOS-Storage @issue-ocis-reva-315 @issue-ocis-reva-316
Feature: upload to a public link share
Background:
Given user "Alice" has been created with default attributes and skeleton files
@issue-ocis-reva-290
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: Uploading file to a public upload-only share that was deleted does not work
Given the administrator has enabled DAV tech_preview
And user "Alice" has created a public link share with settings
| path | FOLDER |
| permissions | create |
When user "Alice" deletes file "/FOLDER" using the WebDAV API
And the public uploads file "does-not-matter.txt" with content "does not matter" using the new public WebDAV API
Then the HTTP status code should be "500"

124
tests/acceptance/features/apiOcisSpecific/apiShareUpdate-updateShare.feature Normal file
View File

@@ -0,0 +1,124 @@
@api @files_sharing-app-required
Feature: sharing
Background:
Given using OCS API version "1"
And user "Alice" has been created with default attributes and skeleton files
@skipOnOcis-EOS-Storage @toFixOnOCIS @issue-ocis-reva-243
# 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 @toFixOnOCIS @issue-ocis-reva-243
# 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
@toFixOnOCIS @toFixOnOcV10 @issue-ocis-reva-243 @issue-ocis-reva-349 @issue-ocis-reva-350 @issue-ocis-reva-352 @issue-37653
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: API responds with a full set of parameters when owner changes the permission of a share
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 "/Alice-folder"
And user "Alice" has shared folder "/Alice-folder" with user "Brian" with permissions "read"
When user "Alice" updates the last share using the sharing API with
| permissions | all |
Then the OCS status code should be "<ocs_status_code>"
And the OCS status message should be "OK"
And the HTTP status code should be "200"
Then 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 | all |
| stime | A_NUMBER |
| parent | |
| expiration | |
| token | |
| uid_file_owner | %username% |
| displayname_file_owner | %displayname% |
| additional_info_owner | |
| additional_info_file_owner | |
| state | 0 |
| item_type | folder |
| item_source | A_STRING |
| path | /Alice-folder |
| mimetype | httpd/unix-directory |
| storage_id | A_STRING |
| storage | 0 |
| file_source | A_STRING |
| file_target | /Alice-folder |
| share_with | %username% |
| share_with_displayname | %displayname% |
| share_with_additional_info | |
| mail_send | 0 |
| name | |
And the fields of the last response should not include
| attributes | |
# | token | |
# | name | |
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |

125
tests/acceptance/features/apiOcisSpecific/apiVersions-fileVersions.feature Normal file
View File

@@ -0,0 +1,125 @@
@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
And as "Alice" file "/davtest.txt-olddav-oldchunking" should not exist
And as "Alice" file "/davtest.txt-newdav-newchunking" should not exist
@issue-ocis-reva-17 @issue-ocis-reva-56
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: Upload a file twice and versions are 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
And 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 "1" element
And the version folder of file "/davtest.txt-newdav-regular" for user "Alice" should contain "1" element
And as "Alice" file "/davtest.txt-olddav-oldchunking" should not exist
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 |
@skipOnStorage:ceph @files_primary_s3-issue-161 @files_sharing-app-required
@issue-ocis-reva-376
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: Receiver tries get file versions of shared file from the sharer
Given user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "textfile0" to "textfile0.txt"
And user "Alice" has uploaded file with content "version 1" to "textfile0.txt"
And user "Alice" has uploaded file with content "version 2" to "textfile0.txt"
And user "Alice" has uploaded file with content "version 3" to "textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
When user "Brian" tries to get versions of file "textfile0.txt" from "Alice"
Then the HTTP status code should be "207"
And the number of versions should be "4"
# And the number of versions should be "3"

45
tests/acceptance/features/apiOcisSpecific/apiWebdavMove1-moveFolder.feature Normal file
View File

@@ -0,0 +1,45 @@
@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
@issue-ocis-reva-211
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Renaming a folder to a backslash is allowed
Given using <dav_version> DAV path
And user "Alice" has created folder "/testshare"
When user "Alice" moves folder "/testshare" to "\" using the WebDAV API
Then the HTTP status code should be "201" or "500"
Examples:
| dav_version |
| old |
| new |
@issue-ocis-reva-211
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Renaming a folder beginning with a backslash is allowed
Given using <dav_version> DAV path
And user "Alice" has created folder "/testshare"
When user "Alice" moves folder "/testshare" to "\testshare" using the WebDAV API
Then the HTTP status code should be "201" or "500"
Examples:
| dav_version |
| old |
| new |
@issue-ocis-reva-211
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Renaming a folder including a backslash encoded is allowed
Given using <dav_version> DAV path
And user "Alice" has created folder "/testshare"
When user "Alice" moves folder "/testshare" to "/hola\hola" using the WebDAV API
Then the HTTP status code should be "201" or "500"
Examples:
| dav_version |
| old |
| new |

22
tests/acceptance/features/apiOcisSpecific/apiWebdavMove1-moveFolderToBlacklistedName.feature Normal file
View File

@@ -0,0 +1,22 @@
@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
# 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 |

43
tests/acceptance/features/apiOcisSpecific/apiWebdavMove2-moveFile.feature Normal file
View File

@@ -0,0 +1,43 @@
@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 skeleton files
@issue-ocis-reva-211
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: rename a file into an invalid filename
Given using <dav_version> DAV path
When user "Alice" moves file "/welcome.txt" to "/a\\a" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "/a\\a" should exist
Examples:
| dav_version |
| old |
| new |
@issue-ocis-reva-211
# 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 "/welcome.txt" to "/welcome.part" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "/welcome.part" should exist
Examples:
| dav_version |
| old |
| new |
@skipOnOcis-OC-Storage @issue-ocis-reva-211
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: renaming to a file with special characters
When user "Alice" moves file "/textfile0.txt" to "/<renamed_file>" using the WebDAV API
Then the HTTP status code should be "201"
And the content of file "/<renamed_file>" for user "Alice" should be ""
Examples:
| renamed_file |
| #oc ab?cd=ef# |

21
tests/acceptance/features/apiOcisSpecific/apiWebdavMove2-moveFileToBlacklistedName.feature Normal file
View File

@@ -0,0 +1,21 @@
@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 skeleton files
@issue-ocis-reva-211
# 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 "/welcome.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 |

24
tests/acceptance/features/apiOcisSpecific/apiWebdavOperations-downloadFile.feature Normal file
View File

@@ -0,0 +1,24 @@
@api
Feature: download file
As a user
I want to be able to download files
So that I can work wih local copies of files on my client system
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"
And user "Alice" has uploaded file with content "Welcome this is just an example file for developers." to "/welcome.txt"
@skipOnOcis-OC-Storage @issue-ocis-reva-98
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Get the content-length response header of a pdf file
Given using <dav_version> DAV path
And user "Alice" has uploaded file "filesForUpload/simple.pdf" to "/simple.pdf"
When user "Alice" downloads file "/simple.pdf" using the WebDAV API
And the following headers should not be set
| header |
| OC-JobStatus-Location |
Examples:
| dav_version |
| old |
| new |

22
tests/acceptance/features/apiOcisSpecific/apiWebdavOperations-refuseAccess.feature Normal file
View File

@@ -0,0 +1,22 @@
@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 |

112
tests/acceptance/features/apiOcisSpecific/apiWebdavPreviews-previews.feature Normal file
View File

@@ -0,0 +1,112 @@
@api @issue-ocis-187
Feature: previews of files downloaded through the webdav API
Background:
Given user "Alice" has been created with default attributes and without skeleton files
@issue-ocis-188
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: download previews with invalid width
Given user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt"
When user "Alice" downloads the preview of "/parent.txt" with width "<width>" and height "32" using the WebDAV API
Then the HTTP status code should be "200"
Examples:
| width |
| 0 |
| 0.5 |
| -1 |
| false |
| true |
| A |
| %2F |
@issue-ocis-188
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: download previews with invalid height
Given user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt"
When user "Alice" downloads the preview of "/parent.txt" with width "32" and height "<height>" using the WebDAV API
Then the HTTP status code should be "200"
Examples:
| height |
| 0 |
| 0.5 |
| -1 |
| false |
| true |
| A |
| %2F |
@issue-ocis-189
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: download previews of file types that don't support preview
Given user "Alice" has uploaded file "filesForUpload/<filename>" to "/<newfilename>"
When user "Alice" downloads the preview of "/<newfilename>" with width "32" and height "32" using the WebDAV API
Then the HTTP status code should be "200"
Examples:
| filename | newfilename |
| simple.pdf | test.pdf |
| simple.odt | test.odt |
| new-data.zip | test.zip |
@issue-ocis-187
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: download previews of different image file types
Given user "Alice" has uploaded file "filesForUpload/<imageName>" to "/<newImageName>"
When user "Alice" downloads the preview of "/<newImageName>" with width "32" and height "32" using the WebDAV API
Then the HTTP status code should be "200"
And the downloaded image should be "1240" pixels wide and "648" pixels high
Examples:
| imageName | newImageName |
| testavatar.jpg | testimage.jpg |
| testavatar.png | testimage.png |
@issue-ocis-187
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: download previews of image after renaming it
Given user "Alice" has uploaded file "filesForUpload/testavatar.jpg" to "/testimage.jpg"
When user "Alice" moves file "/testimage.jpg" to "/testimage.txt" using the WebDAV API
And user "Alice" downloads the preview of "/testimage.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 "1240" pixels wide and "648" pixels high
@issue-ocis-thumbnails-191 @skipOnOcis-EOS-Storage @issue-ocis-reva-308
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: download previews of other users files
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"
When user "Brian" downloads the preview of "/parent.txt" of "Alice" with width "32" and height "32" using the WebDAV API
Then the HTTP status code should be "200"
@issue-ocis-190
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: download previews of folders
Given user "Alice" has created folder "subfolder"
When user "Alice" downloads the preview of "/subfolder/" with width "32" and height "32" using the WebDAV API
Then the HTTP status code should be "501"
@issue-ocis-192
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: Download file previews when it is disabled by the administrator
Given the administrator has updated system config key "enable_previews" with value "false" and type "boolean"
And user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt"
When user "Alice" downloads the preview of "/parent.txt" with width "32" and height "32" using the WebDAV API
Then the HTTP status code should be "200"
@issue-ocis-193
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: unset maximum size of previews
Given user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt"
And the administrator has updated system config key "preview_max_x" with value "null"
And the administrator has updated system config key "preview_max_y" with value "null"
When user "Alice" downloads the preview of "/parent.txt" with width "32" and height "32" using the WebDAV API
Then the HTTP status code should be "200"
@issue-ocis-193
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: set maximum size of previews
Given user "Alice" has uploaded file "filesForUpload/lorem.txt" to "/parent.txt"
When the administrator updates system config key "preview_max_x" with value "null" using the occ command
And the administrator updates system config key "preview_max_y" with value "null" using the occ command
Then the HTTP status code should be "201"
When user "Alice" downloads the preview of "/parent.txt" with width "null" and height "null" using the WebDAV API
Then the HTTP status code should be "200"

37
tests/acceptance/features/apiOcisSpecific/apiWebdavProperties1-createFolder.feature Normal file
View File

@@ -0,0 +1,37 @@
@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
# 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 |

21
tests/acceptance/features/apiOcisSpecific/apiWebdavProperties1-setFileProperties.feature Normal file
View File

@@ -0,0 +1,21 @@
@api @issue-ocis-reva-57
Feature: set file properties
As a user
I want to be able to set meta-information about files
So that I can reccord 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
@skipOnOcis-OC-Storage @issue-ocis-reva-276
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Setting custom DAV property
Given using <dav_version> DAV path
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/testcustomprop.txt"
When user "Alice" sets property "very-custom-prop" with namespace "x1='http://whatever.org/ns'" of file "/testcustomprop.txt" to "veryCustomPropValue" using the WebDAV API
Then the HTTP status code should be "500"
Examples:
| dav_version |
| old |
| new |

115
tests/acceptance/features/apiOcisSpecific/apiWebdavProperties2-getFileProperties.feature Normal file
View File

@@ -0,0 +1,115 @@
@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
# 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 | /C++ file.cpp | webdav\/C\+\+%20file\.cpp |
| old | /file #2.txt | webdav\/file%20%232\.txt |
| old | /file &2.txt | webdav\/file%20&2\.txt |
| new | /C++ file.cpp | dav\/files\/%username%\/C\+\+%20file\.cpp |
| new | /file #2.txt | dav\/files\/%username%\/file%20%232\.txt |
| new | /file &2.txt | dav\/files\/%username%\/file%20&2\.txt |
@issue-ocis-reva-214 @issue-ocis-reva-265 @skipOnOcis-EOS-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%3F2\.txt |
| new | /file ?2.txt | dav\/files\/%username%\/file%20%3F2\.txt |
@skipOnOcis-OC-Storage @issue-ocis-reva-265
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: upload a file to content
Given using <dav_version> DAV path
When user "Alice" uploads file with content "uploaded content" to "<file_name>" using the WebDAV API
Then the HTTP status code should be "500"
Examples:
| dav_version | file_name |
| old | /file ?2.txt |
| new | /file ?2.txt |
@issue-ocis-reva-214
# 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 | /strängé folder | webdav\/str%C3%A4ng%C3%A9%20folder |
| old | /C++ folder | webdav\/C\+\+%20folder |
| old | /नेपाली | webdav\/%E0%A4%A8%E0%A5%87%E0%A4%AA%E0%A4%BE%E0%A4%B2%E0%A5%80 |
| old | /folder #2.txt | webdav\/folder%20%232\.txt |
| old | /folder &2.txt | webdav\/folder%20&2\.txt |
| new | /upload | dav\/files\/%username%\/upload |
| new | /strängé folder | dav\/files\/%username%\/str%C3%A4ng%C3%A9%20folder |
| new | /C++ folder | dav\/files\/%username%\/C\+\+%20folder |
| new | /नेपाली | dav\/files\/%username%\/%E0%A4%A8%E0%A5%87%E0%A4%AA%E0%A4%BE%E0%A4%B2%E0%A5%80 |
| new | /folder #2.txt | dav\/files\/%username%\/folder%20%232\.txt |
| new | /folder &2.txt | dav\/files\/%username%\/folder%20&2\.txt |
@issue-ocis-reva-214 @skipOnOcis-EOS-Storage @issue-ocis-reva-265
# 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 | /folder ?2.txt | webdav\/folder%20%3F2\.txt |
| new | /folder ?2.txt | dav\/files\/%username%\/folder%20%3F2\.txt |
@skipOnOcis-OC-Storage @issue-ocis-reva-265
# 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 |
@issue-ocis-reva-163
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: Do a PROPFIND to a non-existing URL
And user "Alice" requests "<url>" with "PROPFIND" using basic auth
Then the body of the response should be empty
Examples:
| url |
| /remote.php/dav/files/does-not-exist |
| /remote.php/dav/does-not-exist |

20
tests/acceptance/features/apiOcisSpecific/apiWebdavUpload1-uploadFile.feature Normal file
View File

@@ -0,0 +1,20 @@
@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-ocis-reva-265
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario Outline: upload a file and check download content
Given using <dav_version> DAV path
When user "Alice" uploads file with content "uploaded content" to <file_name> using the WebDAV API
Then the content of file <file_name> for user "Alice" should be ""
Examples:
| dav_version | file_name |
| old | "file ?2.txt" |
| new | "file ?2.txt" |