diff --git a/.drone.star b/.drone.star index 52f49e2fd..8da96f2c4 100644 --- a/.drone.star +++ b/.drone.star @@ -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': [ diff --git a/tests/acceptance/config/behat.yml b/tests/acceptance/config/behat.yml index b74d189ad..883dd1679 100644 --- a/tests/acceptance/config/behat.yml +++ b/tests/acceptance/config/behat.yml @@ -21,7 +21,11 @@ default: adminPassword: admin regularUserPassword: 123456 ocPath: apps/testing/api/v1/occ + - CapabilitiesContext: + - ChecksumContext: - FavoritesContext: + - FilesVersionsContext: + - PublicWebDavContext: - WebDavPropertiesContext: extensions: diff --git a/tests/acceptance/features/apiOcisSpecific/ocsDELETEAuth.feature b/tests/acceptance/features/apiOcisSpecific/apiAuthOcs-ocsDELETEAuth.feature similarity index 100% rename from tests/acceptance/features/apiOcisSpecific/ocsDELETEAuth.feature rename to tests/acceptance/features/apiOcisSpecific/apiAuthOcs-ocsDELETEAuth.feature diff --git a/tests/acceptance/features/apiOcisSpecific/ocsGETAuth.feature b/tests/acceptance/features/apiOcisSpecific/apiAuthOcs-ocsGETAuth.feature similarity index 100% rename from tests/acceptance/features/apiOcisSpecific/ocsGETAuth.feature rename to tests/acceptance/features/apiOcisSpecific/apiAuthOcs-ocsGETAuth.feature diff --git a/tests/acceptance/features/apiOcisSpecific/ocsPOSTAuth.feature b/tests/acceptance/features/apiOcisSpecific/apiAuthOcs-ocsPOSTAuth.feature similarity index 100% rename from tests/acceptance/features/apiOcisSpecific/ocsPOSTAuth.feature rename to tests/acceptance/features/apiOcisSpecific/apiAuthOcs-ocsPOSTAuth.feature diff --git a/tests/acceptance/features/apiOcisSpecific/ocsPUTAuth.feature b/tests/acceptance/features/apiOcisSpecific/apiAuthOcs-ocsPUTAuth.feature similarity index 100% rename from tests/acceptance/features/apiOcisSpecific/ocsPUTAuth.feature rename to tests/acceptance/features/apiOcisSpecific/apiAuthOcs-ocsPUTAuth.feature diff --git a/tests/acceptance/features/apiOcisSpecific/apiAuthWebDav-webDavLOCKAuth.feature b/tests/acceptance/features/apiOcisSpecific/apiAuthWebDav-webDavLOCKAuth.feature new file mode 100644 index 000000000..fe5c1c675 --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiAuthWebDav-webDavLOCKAuth.feature @@ -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" diff --git a/tests/acceptance/features/apiOcisSpecific/apiAuthWebDav-webDavMOVEAuth.feature b/tests/acceptance/features/apiOcisSpecific/apiAuthWebDav-webDavMOVEAuth.feature new file mode 100644 index 000000000..c2291fc5e --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiAuthWebDav-webDavMOVEAuth.feature @@ -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" diff --git a/tests/acceptance/features/apiOcisSpecific/apiAuthWebDav-webDavPROPFINDAuth.feature b/tests/acceptance/features/apiOcisSpecific/apiAuthWebDav-webDavPROPFINDAuth.feature new file mode 100644 index 000000000..478ab7466 --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiAuthWebDav-webDavPROPFINDAuth.feature @@ -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" diff --git a/tests/acceptance/features/apiOcisSpecific/apiCapabilities-capabilitiesWithNormalUser.feature b/tests/acceptance/features/apiOcisSpecific/apiCapabilities-capabilitiesWithNormalUser.feature new file mode 100644 index 000000000..cf833d5b2 --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiCapabilities-capabilitiesWithNormalUser.feature @@ -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 | diff --git a/tests/acceptance/features/apiOcisSpecific/apiFavorites-favorites.feature b/tests/acceptance/features/apiOcisSpecific/apiFavorites-favorites.feature new file mode 100644 index 000000000..cc96dcf5b --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiFavorites-favorites.feature @@ -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 path + When user "Alice" favorites element "/FOLDER" using the WebDAV API + Then the HTTP status code should be "500" + Examples: + | dav_version | + | old | + | new | diff --git a/tests/acceptance/features/apiOcisSpecific/apiMain-checksums.feature b/tests/acceptance/features/apiOcisSpecific/apiMain-checksums.feature new file mode 100644 index 000000000..d53698565 --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiMain-checksums.feature @@ -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 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 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 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 | diff --git a/tests/acceptance/features/apiOcisSpecific/apiMain-main.feature b/tests/acceptance/features/apiOcisSpecific/apiMain-main.feature new file mode 100644 index 000000000..9c4ad50f9 --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiMain-main.feature @@ -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" diff --git a/tests/acceptance/features/apiOcisSpecific/apiShareCreateSpecial2-createShareWithInvalidPermissions.feature b/tests/acceptance/features/apiOcisSpecific/apiShareCreateSpecial2-createShareWithInvalidPermissions.feature new file mode 100644 index 000000000..8d08de8b9 --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiShareCreateSpecial2-createShareWithInvalidPermissions.feature @@ -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 "" + 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 "" or "" + And the HTTP status code should be "" or "" + 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 "" + 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 | | + Then the OCS status code should be "" or "" + And the HTTP status code should be "" or "" + 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 | diff --git a/tests/acceptance/features/apiOcisSpecific/apiShareManagementBasic-createShare.feature b/tests/acceptance/features/apiOcisSpecific/apiShareManagementBasic-createShare.feature new file mode 100644 index 000000000..a4b6a73e7 --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiShareManagementBasic-createShare.feature @@ -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 "" + 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 using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_with | %username% | + | file_target | /textfile0.txt | + | path | /textfile0.txt | + | 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 "" + 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 "" or "" + 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 "" + 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 "" + 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 "" + 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 "" + And the HTTP status code should be "" + # 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 | diff --git a/tests/acceptance/features/apiOcisSpecific/apiShareManagementBasic-deleteShare.feature b/tests/acceptance/features/apiOcisSpecific/apiShareManagementBasic-deleteShare.feature new file mode 100644 index 000000000..3de47db44 --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiShareManagementBasic-deleteShare.feature @@ -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 "" + 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 "" + And the HTTP status code should be "200" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/apiOcisSpecific/apiShareOperations-accessToShare.feature b/tests/acceptance/features/apiOcisSpecific/apiShareOperations-accessToShare.feature new file mode 100644 index 000000000..afcc2da74 --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiShareOperations-accessToShare.feature @@ -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 "" + 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 "" + 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 | diff --git a/tests/acceptance/features/apiOcisSpecific/apiShareOperations-getWebDAVSharePermissions.feature b/tests/acceptance/features/apiOcisSpecific/apiShareOperations-getWebDAVSharePermissions.feature new file mode 100644 index 000000000..f7881377f --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiShareOperations-getWebDAVSharePermissions.feature @@ -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 + 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 | diff --git a/tests/acceptance/features/apiOcisSpecific/apiShareOperations-gettingShares.feature b/tests/acceptance/features/apiOcisSpecific/apiShareOperations-gettingShares.feature new file mode 100644 index 000000000..2007a366a --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiShareOperations-gettingShares.feature @@ -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 "" + 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 "" + 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 "" + 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 "" + 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 | diff --git a/tests/acceptance/features/apiOcisSpecific/apiSharePublicLink1-createPublicLinkShare.feature b/tests/acceptance/features/apiOcisSpecific/apiSharePublicLink1-createPublicLinkShare.feature new file mode 100644 index 000000000..235effb6a --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiSharePublicLink1-createPublicLinkShare.feature @@ -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" diff --git a/tests/acceptance/features/apiOcisSpecific/apiSharePublicLink2-copyFromPublicLink.feature b/tests/acceptance/features/apiOcisSpecific/apiSharePublicLink2-copyFromPublicLink.feature new file mode 100644 index 000000000..598f75155 --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiSharePublicLink2-copyFromPublicLink.feature @@ -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 "/" using the new public WebDAV API + Then the HTTP status code should be "204" + And as "Alice" file "/PARENT/" should exist + And the content of file "/PARENT/" 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" diff --git a/tests/acceptance/features/apiOcisSpecific/apiSharePublicLink2-updatePublicLinkShare.feature b/tests/acceptance/features/apiOcisSpecific/apiSharePublicLink2-updatePublicLinkShare.feature new file mode 100644 index 000000000..e14ed5e6a --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiSharePublicLink2-updatePublicLinkShare.feature @@ -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 "" + 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 "" + 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 | diff --git a/tests/acceptance/features/apiOcisSpecific/apiSharePublicLink2-uploadToPublicLinkShare.feature b/tests/acceptance/features/apiOcisSpecific/apiSharePublicLink2-uploadToPublicLinkShare.feature new file mode 100644 index 000000000..320ce525b --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiSharePublicLink2-uploadToPublicLinkShare.feature @@ -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" diff --git a/tests/acceptance/features/apiOcisSpecific/apiShareUpdate-updateShare.feature b/tests/acceptance/features/apiOcisSpecific/apiShareUpdate-updateShare.feature new file mode 100644 index 000000000..bd818e32a --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiShareUpdate-updateShare.feature @@ -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 "" + 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 "" + 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 | diff --git a/tests/acceptance/features/apiOcisSpecific/apiVersions-fileVersions.feature b/tests/acceptance/features/apiOcisSpecific/apiVersions-fileVersions.feature new file mode 100644 index 000000000..bea757a7e --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiVersions-fileVersions.feature @@ -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 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 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" diff --git a/tests/acceptance/features/apiOcisSpecific/apiWebdavMove1-moveFolder.feature b/tests/acceptance/features/apiOcisSpecific/apiWebdavMove1-moveFolder.feature new file mode 100644 index 000000000..6b5bc6a79 --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiWebdavMove1-moveFolder.feature @@ -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 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 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 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 | diff --git a/tests/acceptance/features/apiOcisSpecific/apiWebdavMove1-moveFolderToBlacklistedName.feature b/tests/acceptance/features/apiOcisSpecific/apiWebdavMove1-moveFolderToBlacklistedName.feature new file mode 100644 index 000000000..7a7701a7c --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiWebdavMove1-moveFolderToBlacklistedName.feature @@ -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 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 | diff --git a/tests/acceptance/features/apiOcisSpecific/apiWebdavMove2-moveFile.feature b/tests/acceptance/features/apiOcisSpecific/apiWebdavMove2-moveFile.feature new file mode 100644 index 000000000..89524b6a3 --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiWebdavMove2-moveFile.feature @@ -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 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 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 "/" using the WebDAV API + Then the HTTP status code should be "201" + And the content of file "/" for user "Alice" should be "" + Examples: + | renamed_file | + | #oc ab?cd=ef# | diff --git a/tests/acceptance/features/apiOcisSpecific/apiWebdavMove2-moveFileToBlacklistedName.feature b/tests/acceptance/features/apiOcisSpecific/apiWebdavMove2-moveFileToBlacklistedName.feature new file mode 100644 index 000000000..75221c1b0 --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiWebdavMove2-moveFileToBlacklistedName.feature @@ -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 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 | diff --git a/tests/acceptance/features/apiOcisSpecific/apiWebdavOperations-downloadFile.feature b/tests/acceptance/features/apiOcisSpecific/apiWebdavOperations-downloadFile.feature new file mode 100644 index 000000000..7dc49b2f8 --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiWebdavOperations-downloadFile.feature @@ -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 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 | diff --git a/tests/acceptance/features/apiOcisSpecific/apiWebdavOperations-refuseAccess.feature b/tests/acceptance/features/apiOcisSpecific/apiWebdavOperations-refuseAccess.feature new file mode 100644 index 000000000..5a1df0345 --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiWebdavOperations-refuseAccess.feature @@ -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 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 | diff --git a/tests/acceptance/features/apiOcisSpecific/apiWebdavPreviews-previews.feature b/tests/acceptance/features/apiOcisSpecific/apiWebdavPreviews-previews.feature new file mode 100644 index 000000000..08d796036 --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiWebdavPreviews-previews.feature @@ -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 "" 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 "" 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/" to "/" + When user "Alice" downloads the preview of "/" 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/" to "/" + When user "Alice" downloads the preview of "/" 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" diff --git a/tests/acceptance/features/apiOcisSpecific/apiWebdavProperties1-createFolder.feature b/tests/acceptance/features/apiOcisSpecific/apiWebdavProperties1-createFolder.feature new file mode 100644 index 000000000..c7b96e90f --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiWebdavProperties1-createFolder.feature @@ -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 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 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 | diff --git a/tests/acceptance/features/apiOcisSpecific/apiWebdavProperties1-setFileProperties.feature b/tests/acceptance/features/apiOcisSpecific/apiWebdavProperties1-setFileProperties.feature new file mode 100644 index 000000000..9bb58bd7b --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiWebdavProperties1-setFileProperties.feature @@ -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 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 | diff --git a/tests/acceptance/features/apiOcisSpecific/apiWebdavProperties2-getFileProperties.feature b/tests/acceptance/features/apiOcisSpecific/apiWebdavProperties2-getFileProperties.feature new file mode 100644 index 000000000..01ff43806 --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiWebdavProperties2-getFileProperties.feature @@ -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 path + And user "Alice" has uploaded file with content "uploaded content" to "" + When user "Alice" gets the properties of file "" 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\//" + 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 path + And user "Alice" has uploaded file with content "uploaded content" to "" + When user "Alice" gets the properties of file "" 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\//" + 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 path + When user "Alice" uploads file with content "uploaded content" to "" 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 path + And user "Alice" has created folder "" + And user "Alice" has uploaded file with content "uploaded content" to "/file1.txt" + And user "Alice" has uploaded file with content "uploaded content" to "/file2.txt" + When user "Alice" gets the properties of folder "" 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\/\//" + And the value of the item "//d:response[2]/d:href" in the response to user "Alice" should match "/remote\.php\/\/file1.txt/" + And the value of the item "//d:response[3]/d:href" in the response to user "Alice" should match "/remote\.php\/\/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 path + And user "Alice" has created folder "" + And user "Alice" has uploaded file with content "uploaded content" to "/file1.txt" + And user "Alice" has uploaded file with content "uploaded content" to "/file2.txt" + When user "Alice" gets the properties of folder "" 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\/\//" + And the value of the item "//d:response[2]/d:href" in the response to user "Alice" should match "/remote\.php\/\/file1.txt/" + And the value of the item "//d:response[3]/d:href" in the response to user "Alice" should match "/remote\.php\/\/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 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 "" 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 | diff --git a/tests/acceptance/features/apiOcisSpecific/apiWebdavUpload1-uploadFile.feature b/tests/acceptance/features/apiOcisSpecific/apiWebdavUpload1-uploadFile.feature new file mode 100644 index 000000000..057a17df9 --- /dev/null +++ b/tests/acceptance/features/apiOcisSpecific/apiWebdavUpload1-uploadFile.feature @@ -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 path + When user "Alice" uploads file with content "uploaded content" to using the WebDAV API + Then the content of file for user "Alice" should be "" + Examples: + | dav_version | file_name | + | old | "file ?2.txt" | + | new | "file ?2.txt" |