mirror/opencloud
1
0
Fork 0
mirror of https://github.com/opencloud-eu/opencloud.git synced 2026-05-08 04:20:59 -05:00
Code Issues Packages Projects Releases Wiki Activity

add ocis subcommand

Browse Source
This commit is contained in:
A.Unger
2020-09-18 13:15:21 +02:00
parent 45f8b7c403
commit 1517eb9436
170 changed files with 13980 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
ocis/tests/acceptance/features/apiOcisSpecific/apiAuthOcs-ocsDELETEAuth.feature
+58
View File
@@ -0,0 +1,58 @@
@api @issue-ocis-ocs-26
# after fixing all issues delete these Scenarios and use the one from oC10 core
Feature: auth
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"
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/v1.php/cloud/users/%username%/subadmins |
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"
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/v2.php/cloud/users/%username% |
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"
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%/groups |
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 "996"
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/v2.php/cloud/users/%username%/groups |
Then the HTTP status code of responses on all endpoints should be "500"
And the OCS status code of responses on all endpoints should be "996"
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/v2.php/cloud/users/%username% |
| /ocs/v2.php/cloud/users/%username%/subadmins |
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"
ocis/tests/acceptance/features/apiOcisSpecific/apiAuthOcs-ocsGETAuth.feature
+192
View File
@@ -0,0 +1,192 @@
@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/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-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 |
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 a user requests these endpoints with "GET" and no authentication
| endpoint |
| /ocs/v2.php/cloud/users |
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-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/groups |
| /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/cloud/groups |
| /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 |
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/cloud/users |
Then the HTTP status code of responses on all endpoints should be "200"
And the OCS status code of responses on all endpoints should be "200"
When the user "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 |
Then the HTTP status code of responses on all endpoints should be "200"
And the OCS status code of responses on all endpoints should be "100"
When user "Alice" requests these endpoints with "GET" using password "invalid"
| endpoint |
| /ocs/v2.php/cloud/users |
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"
@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 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 |
Then the HTTP status code of responses on all endpoints should be "200"
And the OCS status code of responses on all endpoints should be "100"
When user "brian" requests these endpoints with "GET" using password "invalid"
| endpoint |
| /ocs/v2.php/cloud/users |
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"
ocis/tests/acceptance/features/apiOcisSpecific/apiAuthOcs-ocsPOSTAuth.feature
+70
View File
@@ -0,0 +1,70 @@
@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"
# 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 |
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 "400"
When user "Alice" requests these endpoints with "POST" including body "doesnotmatter" using password "invalid" about user "Alice"
| endpoint |
| /ocs/v2.php/cloud/users |
Then the HTTP status code of responses on all endpoints should be "400"
And the OCS status code of responses on all endpoints should be "400"
@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/%username%/groups |
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 "400"
When user "Alice" requests these endpoints with "POST" including body "doesnotmatter" using password "invalid" about user "Alice"
| endpoint |
| /ocs/v2.php/cloud/users/%username%/groups |
Then the HTTP status code of responses on all endpoints should be "400"
And the OCS status code of responses on all endpoints should be "400"
@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/%username%/subadmins |
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 user "Alice" requests these endpoints with "POST" including body "doesnotmatter" using password "invalid" about user "Alice"
| endpoint |
| /ocs/v2.php/cloud/users/%username%/subadmins |
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"
ocis/tests/acceptance/features/apiOcisSpecific/apiAuthOcs-ocsPUTAuth.feature
+46
View File
@@ -0,0 +1,46 @@
@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 |
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-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/cloud/users/%username% |
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 "103"
When the administrator requests these endpoints with "PUT" with body "doesnotmatter" using password "invalid" about user "Alice"
| endpoint |
| /ocs/v2.php/cloud/users/%username% |
Then the HTTP status code of responses on all endpoints should be "400"
And the OCS status code of responses on all endpoints should be "103"
@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/v1.php/cloud/users/%username%/enable |
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 administrator requests these endpoints with "PUT" with body "doesnotmatter" using password "invalid" about user "Alice"
| endpoint |
| /ocs/v2.php/cloud/users/%username%/disable |
| /ocs/v2.php/cloud/users/%username%/enable |
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"
ocis/tests/acceptance/features/apiOcisSpecific/apiAuthWebDav-webDavLOCKAuth.feature
+21
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"
ocis/tests/acceptance/features/apiOcisSpecific/apiAuthWebDav-webDavMOVEAuth.feature
+20
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"
ocis/tests/acceptance/features/apiOcisSpecific/apiAuthWebDav-webDavPROPFINDAuth.feature
+20
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"
ocis/tests/acceptance/features/apiOcisSpecific/apiCapabilities-capabilitiesWithNormalUser.feature
+48
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 |
ocis/tests/acceptance/features/apiOcisSpecific/apiFavorites-favorites.feature
+25
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 @skipOnOcis-OCIS-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 |
ocis/tests/acceptance/features/apiOcisSpecific/apiMain-checksums.feature
+57
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 |
ocis/tests/acceptance/features/apiOcisSpecific/apiMain-main.feature
+8
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"
ocis/tests/acceptance/features/apiOcisSpecific/apiShareCreateSpecial2-createShareWithInvalidPermissions.feature
+45
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 |
ocis/tests/acceptance/features/apiOcisSpecific/apiShareManagementBasic-createShare.feature
+117
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 @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 |
ocis/tests/acceptance/features/apiOcisSpecific/apiShareManagementBasic-deleteShare.feature
+18
View File
@@ -0,0 +1,18 @@
@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 without skeleton files
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
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 |
ocis/tests/acceptance/features/apiOcisSpecific/apiShareOperations-accessToShare.feature
+27
View File
@@ -0,0 +1,27 @@
@api @files_sharing-app-required
Feature: sharing
Background:
Given these users have been created with default attributes and without skeleton files:
| username |
| Alice |
| Brian |
And user "Alice" has uploaded file with content "ownCloud test text file 0 Alice" to "/textfile0.txt"
And user "Alice" has uploaded file with content "ownCloud test text file 1 Alice" to "/textfile1.txt"
And user "Brian" has uploaded file with content "ownCloud test text file 0 Brian" to "/textfile0.txt"
And user "Brian" has uploaded file with content "ownCloud test text file 1 Brian" to "/textfile1.txt"
@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 |
ocis/tests/acceptance/features/apiOcisSpecific/apiShareOperations-getWebDAVSharePermissions.feature
+23
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 |
ocis/tests/acceptance/features/apiOcisSpecific/apiShareOperations-gettingShares.feature
+38
View File
@@ -0,0 +1,38 @@
@api @files_sharing-app-required
Feature: sharing
Background:
Given user "Alice" has been created with default attributes and without skeleton files
And user "Brian" has been created with default attributes and without skeleton files
@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 user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
And 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 user "Alice" has created folder "/PARENT"
And user "Alice" has uploaded file with content "some data" to "/PARENT/parent.txt"
And 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 |
ocis/tests/acceptance/features/apiOcisSpecific/apiSharePublicLink1-createPublicLinkShare.feature
+31
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 without skeleton files
@issue-37605 @skipOnOcis-OCIS-Storage
# 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 @skipOnOcis-OCIS-Storage
# 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"
ocis/tests/acceptance/features/apiOcisSpecific/apiSharePublicLink2-copyFromPublicLink.feature
+67
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 @skipOnOcis-OCIS-Storage
# 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 @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"
@issue-ocis-reva-368 @skipOnOcis-OCIS-Storage
# 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 @skipOnOcis-OCIS-Storage
# 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"
ocis/tests/acceptance/features/apiOcisSpecific/apiSharePublicLink2-updatePublicLinkShare.feature
+48
View File
@@ -0,0 +1,48 @@
@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 without skeleton files
And user "Alice" has created folder "/FOLDER"
@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 |
ocis/tests/acceptance/features/apiOcisSpecific/apiSharePublicLink2-uploadToPublicLinkShare.feature
+18
View File
@@ -0,0 +1,18 @@
@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 without skeleton files
And user "Alice" has created folder "/FOLDER"
@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"
ocis/tests/acceptance/features/apiOcisSpecific/apiShareUpdate-updateShare.feature
+124
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 without skeleton files
@skipOnOcis-EOS-Storage @toFixOnOCIS @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 @toFixOnOCIS @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
@toFixOnOCIS @toFixOnOcV10 @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 |
ocis/tests/acceptance/features/apiOcisSpecific/apiTrashbin-trashbinDelete.feature
+55
View File
@@ -0,0 +1,55 @@
@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"
@smokeTest
@issue-product-139
@issue-product-178
@issue-product-179
Scenario Outline: Trashbin cannot be emptied
# after fixing all issues delete this Scenario and use the one from oC10 core
# because of @issue-product-178 we cannot perform this test using new dav, so only old dav is being used
Given user "Alice" has uploaded file with content "file with comma" to "sample,0.txt"
And user "Alice" has uploaded file with content "file with comma" to "sample,1.txt"
And using <dav-path> DAV path
And user "Alice" has deleted file "<filename1>"
And user "Alice" has deleted file "<filename2>"
And as "Alice" file "<filename1>" should exist in the trashbin
And as "Alice" file "<filename2>" should exist in the trashbin
When user "Alice" empties the trashbin using the trashbin API
Then as "Alice" the file with original path "<filename1>" should exist in the trashbin
And as "Alice" the file with original path "<filename2>" should exist in the trashbin
Examples:
| dav-path | filename1 | filename2 |
| old | textfile0.txt | textfile1.txt |
| old | sample,0.txt | sample,1.txt |
| new | textfile0.txt | textfile1.txt |
| new | sample,0.txt | sample,1.txt |
@smokeTest
@issue-ocis-reva-118
@issue-product-179
@skipOnOcis-OCIS-Storage
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: delete a single file from the trashbin
Given user "Alice" has deleted file "/textfile0.txt"
And user "Alice" has deleted file "/textfile1.txt"
And user "Alice" has deleted file "/PARENT/parent.txt"
And user "Alice" has deleted file "/PARENT/CHILD/child.txt"
When user "Alice" deletes the file with original path "textfile1.txt" from the trashbin using the trashbin API
Then the HTTP status code should be "405"
And as "Alice" the file with original path "/textfile1.txt" should exist in the trashbin
But as "Alice" the file with original path "/textfile0.txt" should exist in the trashbin
And as "Alice" the file with original path "/PARENT/parent.txt" should exist in the trashbin
And as "Alice" the file with original path "/PARENT/CHILD/child.txt" should exist in the trashbin
ocis/tests/acceptance/features/apiOcisSpecific/apiVersions-fileVersions.feature
+125
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"
ocis/tests/acceptance/features/apiOcisSpecific/apiWebdavMove1-moveFolder.feature
+45
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 |
ocis/tests/acceptance/features/apiOcisSpecific/apiWebdavMove1-moveFolderToBlacklistedName.feature
+22
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 @skipOnOcis-OCIS-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 |
ocis/tests/acceptance/features/apiOcisSpecific/apiWebdavMove2-moveFile.feature
+44
View File
@@ -0,0 +1,44 @@
@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 "some welcome data" to "/welcome.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 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 @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 "/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 @skipOnOcis-OCIS-Storage
# 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# |
ocis/tests/acceptance/features/apiOcisSpecific/apiWebdavMove2-moveFileToBlacklistedName.feature
+22
View File
@@ -0,0 +1,22 @@
@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 "some welcome data" to "/welcome.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 "/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 |
ocis/tests/acceptance/features/apiOcisSpecific/apiWebdavOperations-downloadFile.feature
+24
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 |
ocis/tests/acceptance/features/apiOcisSpecific/apiWebdavOperations-refuseAccess.feature
+22
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 |
ocis/tests/acceptance/features/apiOcisSpecific/apiWebdavPreviews-previews.feature
+112
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 "400"
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 "400"
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 "400"
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 "400"
# 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 "400"
# 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 "400"
@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 "400"
@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 "400"
@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 "400"
@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 "400"
ocis/tests/acceptance/features/apiOcisSpecific/apiWebdavProperties1-createFolder.feature
+37
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 @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 |
ocis/tests/acceptance/features/apiOcisSpecific/apiWebdavProperties1-setFileProperties.feature
+21
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 @skipOnOcis-OCIS-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 |
ocis/tests/acceptance/features/apiOcisSpecific/apiWebdavProperties2-getFileProperties.feature
+115
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 @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 | /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 @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%3F2\.txt |
| new | /file ?2.txt | dav\/files\/%username%\/file%20%3F2\.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: 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 @skipOnOcis-OCIS-Storage @issue-ocis-reva-471
# 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 @skipOnOcis-OCIS-Storage @issue-ocis-reva-471
# 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 @skipOnOcis-OCIS-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 |
ocis/tests/acceptance/features/apiOcisSpecific/apiWebdavUpload1-uploadFile.feature
+38
View File
@@ -0,0 +1,38 @@
@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 @skipOnOcis-OCIS-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" |
@skipOnOcis-OC-Storage @skipOnOcis-OCIS-Storage @issue-product-127
# 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 |