mirror of
https://github.com/opencloud-eu/opencloud.git
synced 2026-05-04 01:39:16 -05:00
copy feature files from core
This commit is contained in:
Saw-jan
@@ -0,0 +1,61 @@
|
||||
@api @skipOnLDAP @notToImplementOnOCIS
|
||||
Feature: AppManagement
|
||||
|
||||
Scenario: Update of patch version of an app
|
||||
Given these apps' path has been configured additionally with following attributes:
|
||||
| dir | is_writable |
|
||||
| apps-custom | true |
|
||||
And app "updatetest" with version "2.0.0" has been put in dir "apps"
|
||||
And app "updatetest" has been enabled
|
||||
And app "updatetest" has been disabled
|
||||
When the administrator puts app "updatetest" with version "2.0.1" in dir "apps"
|
||||
And the administrator enables app "updatetest"
|
||||
Then the installed version of "updatetest" should be "2.0.1"
|
||||
|
||||
|
||||
Scenario: Update of patch version of an app in apps-external, previous version in apps folder
|
||||
Given these apps' path has been configured additionally with following attributes:
|
||||
| dir | is_writable |
|
||||
| apps-custom | true |
|
||||
And app "updatetest" with version "2.0.0" has been put in dir "apps"
|
||||
And app "updatetest" has been enabled
|
||||
And app "updatetest" has been disabled
|
||||
When the administrator puts app "updatetest" with version "2.0.1" in dir "apps-external"
|
||||
And the administrator enables app "updatetest"
|
||||
Then the installed version of "updatetest" should be "2.0.1"
|
||||
|
||||
|
||||
Scenario: Update of patch version of an app in apps-external
|
||||
Given these apps' path has been configured additionally with following attributes:
|
||||
| dir | is_writable |
|
||||
| apps-custom | true |
|
||||
And app "updatetest" with version "2.0.0" has been put in dir "apps-external"
|
||||
And app "updatetest" has been enabled
|
||||
And app "updatetest" has been disabled
|
||||
When the administrator puts app "updatetest" with version "2.0.1" in dir "apps-external"
|
||||
And the administrator enables app "updatetest"
|
||||
Then the installed version of "updatetest" should be "2.0.1"
|
||||
|
||||
|
||||
Scenario: Update of patch version of an app but update is put in alternative folder
|
||||
Given these apps' path has been configured additionally with following attributes:
|
||||
| dir | is_writable |
|
||||
| apps-custom | true |
|
||||
And app "updatetest" with version "2.0.0" has been put in dir "apps"
|
||||
And app "updatetest" has been enabled
|
||||
And app "updatetest" has been disabled
|
||||
When the administrator puts app "updatetest" with version "2.0.1" in dir "apps-custom"
|
||||
And the administrator enables app "updatetest"
|
||||
Then the installed version of "updatetest" should be "2.0.1"
|
||||
|
||||
|
||||
Scenario: Update of patch version of an app previously in apps-external but update is put in alternative folder
|
||||
Given these apps' path has been configured additionally with following attributes:
|
||||
| dir | is_writable |
|
||||
| apps-custom | true |
|
||||
And app "updatetest" with version "2.0.0" has been put in dir "apps-external"
|
||||
And app "updatetest" has been enabled
|
||||
And app "updatetest" has been disabled
|
||||
When the administrator puts app "updatetest" with version "2.0.1" in dir "apps-custom"
|
||||
And the administrator enables app "updatetest"
|
||||
Then the installed version of "updatetest" should be "2.0.1"
|
||||
@@ -0,0 +1,33 @@
|
||||
@api
|
||||
Feature: caldav
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes and without skeleton files
|
||||
|
||||
@caldav
|
||||
Scenario: Accessing a nonexistent calendar of another user
|
||||
When the administrator requests calendar "%username%/MyCalendar" of user "Alice" using the new WebDAV API
|
||||
Then the CalDAV HTTP status code should be "404"
|
||||
And the CalDAV exception should be "Sabre\DAV\Exception\NotFound"
|
||||
And the CalDAV message should be "Node with name 'MyCalendar' could not be found"
|
||||
|
||||
@caldav
|
||||
Scenario: Accessing a not shared calendar of another user
|
||||
Given the administrator has successfully created a calendar named "MyCalendar"
|
||||
When user "Alice" requests calendar "%username%/MyCalendar" of user "admin" using the new WebDAV API
|
||||
Then the CalDAV HTTP status code should be "404"
|
||||
And the CalDAV exception should be "Sabre\DAV\Exception\NotFound"
|
||||
And the CalDAV message should be "Node with name 'MyCalendar' could not be found"
|
||||
|
||||
@caldav
|
||||
Scenario: Accessing a nonexistent calendar of myself
|
||||
When user "Alice" requests calendar "%username%/MyCalendar" of user "admin" using the new WebDAV API
|
||||
Then the CalDAV HTTP status code should be "404"
|
||||
And the CalDAV exception should be "Sabre\DAV\Exception\NotFound"
|
||||
And the CalDAV message should be "Node with name 'MyCalendar' could not be found"
|
||||
|
||||
@caldav @smokeTest
|
||||
Scenario: Creating a new calendar
|
||||
Given user "Alice" has successfully created a calendar named "MyCalendar"
|
||||
When user "Alice" requests calendar "%username%/MyCalendar" of user "Alice" using the new WebDAV API
|
||||
Then the CalDAV HTTP status code should be "200"
|
||||
@@ -0,0 +1,33 @@
|
||||
@api
|
||||
Feature: carddav
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes and without skeleton files
|
||||
|
||||
@carddav
|
||||
Scenario: Accessing a nonexistent addressbook of another user
|
||||
When the administrator requests address book "%username%/MyAddressbook" of user "Alice" using the new WebDAV API
|
||||
Then the CardDAV HTTP status code should be "404"
|
||||
And the CardDAV exception should be "Sabre\DAV\Exception\NotFound"
|
||||
And the CardDAV message should be "Addressbook with name 'MyAddressbook' could not be found"
|
||||
|
||||
@carddav
|
||||
Scenario: Accessing a not shared addressbook of another user
|
||||
Given the administrator has successfully created an address book named "MyAddressbook"
|
||||
When user "Alice" requests address book "%username%/MyAddressbook" of user "admin" using the new WebDAV API
|
||||
Then the CardDAV HTTP status code should be "404"
|
||||
And the CardDAV exception should be "Sabre\DAV\Exception\NotFound"
|
||||
And the CardDAV message should be "Addressbook with name 'MyAddressbook' could not be found"
|
||||
|
||||
@carddav
|
||||
Scenario: Accessing a nonexistent addressbook of myself
|
||||
When user "Alice" requests address book "%username%/MyAddressbook" of user "admin" using the new WebDAV API
|
||||
Then the CardDAV HTTP status code should be "404"
|
||||
And the CardDAV exception should be "Sabre\DAV\Exception\NotFound"
|
||||
And the CardDAV message should be "Addressbook with name 'MyAddressbook' could not be found"
|
||||
|
||||
@carddav @smokeTest
|
||||
Scenario: Creating a new addressbook
|
||||
Given user "Alice" has successfully created an address book named "MyAddressbook"
|
||||
When user "Alice" requests address book "%username%/MyAddressbook" of user "Alice" using the new WebDAV API
|
||||
Then the CardDAV HTTP status code should be "200"
|
||||
@@ -0,0 +1,21 @@
|
||||
@api @notToImplementOnOCIS
|
||||
Feature: checksums
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes and without skeleton files
|
||||
|
||||
# this is a bug demo scenario for https://github.com/owncloud/core/issues/38835
|
||||
# Once this scenario is fixed Delete this file and remove @skipOnOcV10 tag from tests/acceptance/features/apiMain/checksums.feature:132
|
||||
@files_sharing-app-required @skipOnStorage:ceph @skipOnStorage:scality
|
||||
Scenario: Sharing and modifying a file should return correct checksum in the propfind using new DAV path
|
||||
Given the administrator has set the default folder for received shares to "Shares"
|
||||
And auto-accept shares has been disabled
|
||||
And using new DAV path
|
||||
And user "Brian" has been created with default attributes and without skeleton files
|
||||
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a"
|
||||
And user "Alice" has shared file "/myChecksumFile.txt" with user "Brian"
|
||||
And user "Brian" has accepted share "/myChecksumFile.txt" offered by user "Alice"
|
||||
And user "Brian" has uploaded file with checksum "SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399" and content "Some Text" to "/Shares/myChecksumFile.txt"
|
||||
When user "Brian" requests the checksum of "/Shares/myChecksumFile.txt" via propfind
|
||||
Then the HTTP status code should be "207"
|
||||
And the webdav checksum should be empty
|
||||
@@ -0,0 +1,485 @@
|
||||
@api
|
||||
Feature: checksums
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes and without skeleton files
|
||||
|
||||
Scenario Outline: Uploading a file with checksum should work
|
||||
Given using <dav_version> DAV path
|
||||
When user "Alice" uploads file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@skipOnOcV10 @personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
@smokeTest @issue-ocis-reva-196
|
||||
Scenario Outline: Uploading a file with checksum should return the checksum in the propfind
|
||||
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" requests the checksum of "/myChecksumFile.txt" via propfind
|
||||
Then the webdav checksum should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@skipOnOcV10 @personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
@smokeTest @issue-ocis-reva-98
|
||||
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 HTTP status code should be "200"
|
||||
And the header checksum should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@skipOnOcV10 @personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
@issue-ocis-reva-196
|
||||
Scenario Outline: Moving a file with checksum should return the checksum in the propfind
|
||||
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" moves file "/myChecksumFile.txt" to "/myMovedChecksumFile.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And as user "Alice" the webdav checksum of "/myMovedChecksumFile.txt" via propfind should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@skipOnOcV10 @personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
@issue-ocis-reva-98
|
||||
Scenario Outline: Downloading 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"
|
||||
And user "Alice" has moved file "/myChecksumFile.txt" to "/myMovedChecksumFile.txt"
|
||||
When user "Alice" downloads file "/myMovedChecksumFile.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "200"
|
||||
And the header checksum should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@skipOnOcV10 @personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
@issue-ocis-reva-196
|
||||
Scenario Outline: Uploading a chunked file with checksum should return the checksum in the propfind
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has uploaded chunk file "1" of "3" with "AAAAA" to "/myChecksumFile.txt" with checksum "MD5:45a72715acdd5019c5be30bdbb75233e"
|
||||
And user "Alice" has uploaded chunk file "2" of "3" with "BBBBB" to "/myChecksumFile.txt" with checksum "MD5:45a72715acdd5019c5be30bdbb75233e"
|
||||
And user "Alice" has uploaded chunk file "3" of "3" with "CCCCC" to "/myChecksumFile.txt" with checksum "MD5:45a72715acdd5019c5be30bdbb75233e"
|
||||
When user "Alice" requests the checksum of "/myChecksumFile.txt" via propfind
|
||||
Then the HTTP status code should be "207"
|
||||
And the webdav checksum should match "SHA1:acfa6b1565f9710d4d497c6035d5c069bd35a8e8 MD5:45a72715acdd5019c5be30bdbb75233e ADLER32:1ecd03df"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
|
||||
@skipOnOcV10 @personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
@issue-ocis-reva-17
|
||||
Scenario Outline: Uploading a chunked file with checksum should return the checksum in the download header
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has uploaded chunk file "1" of "3" with "AAAAA" to "/myChecksumFile.txt" with checksum "MD5:45a72715acdd5019c5be30bdbb75233e"
|
||||
And user "Alice" has uploaded chunk file "2" of "3" with "BBBBB" to "/myChecksumFile.txt" with checksum "MD5:45a72715acdd5019c5be30bdbb75233e"
|
||||
And user "Alice" has uploaded chunk file "3" of "3" with "CCCCC" to "/myChecksumFile.txt" with checksum "MD5:45a72715acdd5019c5be30bdbb75233e"
|
||||
When user "Alice" downloads file "/myChecksumFile.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "200"
|
||||
And the header checksum should match "SHA1:acfa6b1565f9710d4d497c6035d5c069bd35a8e8"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
|
||||
@skipOnOcV10 @personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
@local_storage @files_external-app-required @notToImplementOnOCIS
|
||||
Scenario Outline: Downloading a file from local storage has correct checksum
|
||||
Given using <dav_version> DAV path
|
||||
# Create the file directly in local storage, bypassing ownCloud
|
||||
And file "prueba_cksum.txt" with text "Test file for checksums" has been created in local storage on the server
|
||||
# Do a first download, which will trigger ownCloud to calculate a checksum for the file
|
||||
When user "Alice" downloads file "/local_storage/prueba_cksum.txt" using the WebDAV API
|
||||
# Now do a download that is expected to have a checksum with it
|
||||
And user "Alice" downloads file "/local_storage/prueba_cksum.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "200"
|
||||
And the header checksum should match "SHA1:a35b7605c8f586d735435535c337adc066c2ccb6"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@issue-ocis-reva-14
|
||||
Scenario Outline: Moving file with checksum should return the checksum in the download header
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a"
|
||||
When user "Alice" moves file "/myChecksumFile.txt" to "/myMovedChecksumFile.txt" using the WebDAV API
|
||||
And user "Alice" downloads file "/myMovedChecksumFile.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "200"
|
||||
And the header checksum should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@skipOnOcV10 @personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
@issue-ocis-reva-196
|
||||
Scenario Outline: Copying a file with checksum should return the checksum in the propfind using new DAV path
|
||||
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" copies file "/myChecksumFile.txt" to "/myChecksumFileCopy.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And as user "Alice" the webdav checksum of "/myChecksumFileCopy.txt" via propfind should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| new |
|
||||
|
||||
@skipOnOcV10 @personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
@issue-ocis-reva-98
|
||||
Scenario Outline: Copying file with checksum should return the checksum in the download header using new DAV path
|
||||
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" copies file "/myChecksumFile.txt" to "/myChecksumFileCopy.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And the header checksum when user "Alice" downloads file "/myChecksumFileCopy.txt" using the WebDAV API should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| new |
|
||||
|
||||
@skipOnOcV10 @personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
@files_sharing-app-required @issue-ocis-reva-196
|
||||
Scenario Outline: Sharing a file with checksum should return the checksum in the propfind using new DAV path
|
||||
Given the administrator has set the default folder for received shares to "Shares"
|
||||
And auto-accept shares has been disabled
|
||||
And using <dav_version> DAV path
|
||||
And user "Brian" has been created with default attributes and without skeleton files
|
||||
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a"
|
||||
And user "Alice" has shared file "/myChecksumFile.txt" with user "Brian"
|
||||
And user "Brian" has accepted share "/myChecksumFile.txt" offered by user "Alice"
|
||||
When user "Brian" requests the checksum of "/Shares/myChecksumFile.txt" via propfind
|
||||
Then the HTTP status code should be "207"
|
||||
And the webdav checksum should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| new |
|
||||
|
||||
@files_sharing-app-required @issue-ocis-reva-196 @skipOnOcV10
|
||||
Scenario Outline: Modifying a shared file should return correct checksum in the propfind using new DAV path
|
||||
Given the administrator has set the default folder for received shares to "Shares"
|
||||
And auto-accept shares has been disabled
|
||||
And using <dav_version> DAV path
|
||||
And user "Brian" has been created with default attributes and without skeleton files
|
||||
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a"
|
||||
And user "Alice" has shared file "/myChecksumFile.txt" with user "Brian"
|
||||
And user "Brian" has accepted share "/myChecksumFile.txt" offered by user "Alice"
|
||||
When user "Brian" uploads file with checksum "SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399" and content "Some Text" to "/Shares/myChecksumFile.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "204"
|
||||
And as user "Alice" the webdav checksum of "/myChecksumFile.txt" via propfind should match "<checksum>"
|
||||
Examples:
|
||||
| dav_version | checksum |
|
||||
| new | SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399 MD5:56e57920c3c8c727bfe7a5288cdf61c4 ADLER32:1048035a |
|
||||
|
||||
@issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321
|
||||
Scenario: Upload new DAV chunked file where checksum matches
|
||||
Given using new DAV path
|
||||
And user "Alice" has created a new chunking upload with id "chunking-42"
|
||||
When user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API
|
||||
And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API
|
||||
And user "Alice" moves new chunk file with id "chunking-42" to "/myChunkedFile.txt" with checksum "SHA1:5d84d61b03fdacf813640f5242d309721e0629b1" using the WebDAV API
|
||||
Then the HTTP status code of responses on all endpoints should be "201"
|
||||
|
||||
@issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321
|
||||
Scenario: Upload new DAV chunked file where checksum does not match
|
||||
Given using new DAV path
|
||||
And user "Alice" has created a new chunking upload with id "chunking-42"
|
||||
When user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API
|
||||
And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API
|
||||
And user "Alice" moves new chunk file with id "chunking-42" to "/myChunkedFile.txt" with checksum "SHA1:f005ba11" using the WebDAV API
|
||||
Then the HTTP status code of responses on each endpoint should be "201, 201, 400" respectively
|
||||
And user "Alice" should not see the following elements
|
||||
| /myChunkedFile.txt |
|
||||
|
||||
@issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321
|
||||
Scenario: Upload new DAV chunked file using async MOVE where checksum matches
|
||||
Given using new DAV path
|
||||
And the administrator has enabled async operations
|
||||
And user "Alice" has created a new chunking upload with id "chunking-42"
|
||||
When user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API
|
||||
And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API
|
||||
And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" with checksum "SHA1:5d84d61b03fdacf813640f5242d309721e0629b1" using the WebDAV API
|
||||
Then the HTTP status code of responses on each endpoint should be "201, 201, 202" respectively
|
||||
And the following headers should match these regular expressions for user "Alice"
|
||||
| OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ |
|
||||
And the oc job status values of last request for user "Alice" should match these regular expressions
|
||||
| status | /^finished$/ |
|
||||
| fileId | /^[0-9a-z]{20,}$/ |
|
||||
And the content of file "/myChunkedFile.txt" for user "Alice" should be "BBBBBCCCCC"
|
||||
|
||||
@issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321
|
||||
Scenario: Upload new DAV chunked file using async MOVE where checksum does not match
|
||||
Given using new DAV path
|
||||
And the administrator has enabled async operations
|
||||
And user "Alice" has created a new chunking upload with id "chunking-42"
|
||||
When user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API
|
||||
And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API
|
||||
And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" with checksum "SHA1:f005ba11" using the WebDAV API
|
||||
Then the HTTP status code of responses on each endpoint should be "201, 201, 202" respectively
|
||||
And the following headers should match these regular expressions for user "Alice"
|
||||
| OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ |
|
||||
And the oc job status values of last request for user "Alice" should match these regular expressions
|
||||
| status | /^error$/ |
|
||||
| errorCode | /^400$/ |
|
||||
| errorMessage | /^The computed checksum does not match the one received from the client.$/ |
|
||||
And user "Alice" should not see the following elements
|
||||
| /myChunkedFile.txt |
|
||||
|
||||
@issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321
|
||||
Scenario: Upload new DAV chunked file using async MOVE where checksum does not match - retry with correct checksum
|
||||
Given using new DAV path
|
||||
And the administrator has enabled async operations
|
||||
And user "Alice" has created a new chunking upload with id "chunking-42"
|
||||
When user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API
|
||||
And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API
|
||||
And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" with checksum "SHA1:f005ba11" using the WebDAV API
|
||||
And user "Alice" moves new chunk file with id "chunking-42" asynchronously to "/myChunkedFile.txt" with checksum "SHA1:5d84d61b03fdacf813640f5242d309721e0629b1" using the WebDAV API
|
||||
Then the HTTP status code of responses on each endpoint should be "201, 201, 202, 202" respectively
|
||||
And the following headers should match these regular expressions for user "Alice"
|
||||
| OC-JobStatus-Location | /%base_path%\/remote\.php\/dav\/job-status\/%username%\/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/ |
|
||||
And the oc job status values of last request for user "Alice" should match these regular expressions
|
||||
| status | /^finished$/ |
|
||||
| fileId | /^[0-9a-z]{20,}$/ |
|
||||
And the content of file "/myChunkedFile.txt" for user "Alice" should be "BBBBBCCCCC"
|
||||
|
||||
@issue-ocis-reva-99
|
||||
Scenario Outline: Upload a file where checksum does not match
|
||||
Given using <dav_version> DAV path
|
||||
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 "400"
|
||||
And user "Alice" should not see the following elements
|
||||
| /chksumtst.txt |
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@skipOnOcV10 @personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
|
||||
Scenario Outline: Upload a file where checksum does match
|
||||
Given using <dav_version> DAV path
|
||||
When user "Alice" uploads file with checksum "SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399" and content "Some Text" to "/chksumtst.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@skipOnOcV10 @personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
@issue-ocis-reva-99
|
||||
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 HTTP status code should be "200"
|
||||
And the following headers should be set
|
||||
| header | value |
|
||||
| OC-Checksum | SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399 |
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@skipOnOcV10 @personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
@local_storage @files_external-app-required @notToImplementOnOCIS @skipOnEncryptionType:user-keys @encryption-issue-42
|
||||
Scenario Outline: Uploaded file to external storage should have the same checksum when downloaded
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has uploaded file with checksum "SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399" and content "Some Text" to "/local_storage/chksumtst.txt"
|
||||
When user "Alice" downloads file "/local_storage/chksumtst.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "200"
|
||||
And the following headers should be set
|
||||
| header | value |
|
||||
| OC-Checksum | SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399 |
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
## Validation Plugin or Old Endpoint Specific
|
||||
@issue-ocis-reva-17
|
||||
Scenario Outline: Uploading an old method chunked file with checksum should fail using new DAV path
|
||||
Given using <dav_version> DAV path
|
||||
When user "Alice" uploads chunk file "1" of "3" with "AAAAA" to "/myChecksumFile.txt" with checksum "MD5:45a72715acdd5019c5be30bdbb75233e" using the WebDAV API
|
||||
Then the HTTP status code should be "503"
|
||||
And user "Alice" should not see the following elements
|
||||
| /myChecksumFile.txt |
|
||||
Examples:
|
||||
| dav_version |
|
||||
| new |
|
||||
|
||||
@skipOnOcV10 @personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
## upload overwriting
|
||||
@issue-ocis-reva-196
|
||||
Scenario Outline: Uploading a file with MD5 checksum overwriting an existing file
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has uploaded file with content "some data" to "textfile0.txt"
|
||||
When user "Alice" uploads file "filesForUpload/textfile.txt" to "/textfile0.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a" using the WebDAV API
|
||||
Then the HTTP status code should be "204"
|
||||
And as user "Alice" the webdav checksum of "/textfile0.txt" via propfind should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960"
|
||||
And the content of file "/textfile0.txt" for user "Alice" should be:
|
||||
"""
|
||||
This is a testfile.
|
||||
|
||||
Cheers.
|
||||
"""
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@skipOnOcV10 @personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
@issue-ocis-reva-196
|
||||
Scenario Outline: Uploading a file with SHA1 checksum overwriting an existing file
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has uploaded file with content "some data" to "textfile0.txt"
|
||||
When user "Alice" uploads file "filesForUpload/textfile.txt" to "/textfile0.txt" with checksum "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f" using the WebDAV API
|
||||
Then the HTTP status code should be "204"
|
||||
And as user "Alice" the webdav checksum of "/textfile0.txt" via propfind should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960"
|
||||
And the content of file "/textfile0.txt" for user "Alice" should be:
|
||||
"""
|
||||
This is a testfile.
|
||||
|
||||
Cheers.
|
||||
"""
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@skipOnOcV10 @personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
@skipOnStorage:ceph @skipOnStorage:scality @files_primary_s3-issue-224 @issue-ocis-reva-196
|
||||
Scenario Outline: Uploading a file with invalid SHA1 checksum overwriting an existing file
|
||||
Given using <dav_version> DAV path
|
||||
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
|
||||
When user "Alice" uploads file "filesForUpload/textfile.txt" to "/textfile0.txt" with checksum "SHA1:f005ba11f005ba11f005ba11f005ba11f005ba11" using the WebDAV API
|
||||
Then the HTTP status code should be "400"
|
||||
And as user "Alice" the webdav checksum of "/textfile0.txt" via propfind should match "SHA1:2052377dec0724bda0d57aeab67fa819278b7f74 MD5:096e350e9ff1339a997a14145f9fc4b9 ADLER32:7d5a0921"
|
||||
And the content of file "/textfile0.txt" for user "Alice" should be "ownCloud test text file 0"
|
||||
Examples:
|
||||
| dav_version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@skipOnOcV10 @personalSpace
|
||||
Examples:
|
||||
| dav_version |
|
||||
| spaces |
|
||||
|
||||
@issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321
|
||||
Scenario: Upload overwriting a file with new chunking and correct checksum
|
||||
Given using new DAV path
|
||||
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
|
||||
And user "Alice" has created a new chunking upload with id "chunking-42"
|
||||
When user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API
|
||||
And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API
|
||||
And user "Alice" moves new chunk file with id "chunking-42" to "/textfile0.txt" with checksum "SHA1:5d84d61b03fdacf813640f5242d309721e0629b1" using the WebDAV API
|
||||
Then the HTTP status code of responses on each endpoint should be "201, 201, 204" respectively
|
||||
And the content of file "/textfile0.txt" for user "Alice" should be "BBBBBCCCCC"
|
||||
|
||||
@skipOnStorage:ceph @skipOnStorage:scality @files_primary_s3-issue-224 @issue-ocis-reva-56 @notToImplementOnOCIS @newChunking @issue-ocis-1321
|
||||
Scenario: Upload overwriting a file with new chunking and invalid checksum
|
||||
Given using new DAV path
|
||||
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
|
||||
And user "Alice" has created a new chunking upload with id "chunking-42"
|
||||
When user "Alice" uploads new chunk file "2" with "BBBBB" to id "chunking-42" using the WebDAV API
|
||||
And user "Alice" uploads new chunk file "3" with "CCCCC" to id "chunking-42" using the WebDAV API
|
||||
And user "Alice" moves new chunk file with id "chunking-42" to "/textfile0.txt" with checksum "SHA1:f005ba11" using the WebDAV API
|
||||
Then the HTTP status code of responses on each endpoint should be "201, 201, 400" respectively
|
||||
And the content of file "/textfile0.txt" for user "Alice" should be "ownCloud test text file 0"
|
||||
|
||||
@issue-ocis-reva-214
|
||||
Scenario Outline: Uploading a file with checksum should work for file with special characters
|
||||
Given using <dav_version> DAV path
|
||||
When user "Alice" uploads file "filesForUpload/textfile.txt" to <renamed_file> with checksum "MD5:d70b40f177b14b470d1756a3c12b963a" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And the content of file <renamed_file> for user "Alice" should be:
|
||||
"""
|
||||
This is a testfile.
|
||||
|
||||
Cheers.
|
||||
"""
|
||||
Examples:
|
||||
| dav_version | renamed_file |
|
||||
| old | " oc?test=ab&cd " |
|
||||
| old | "# %ab ab?=ed" |
|
||||
| new | " oc?test=ab&cd " |
|
||||
| new | "# %ab ab?=ed" |
|
||||
|
||||
@skipOnOcV10 @personalSpace
|
||||
Examples:
|
||||
| dav_version | renamed_file |
|
||||
| spaces | " oc?test=ab&cd " |
|
||||
| spaces | "# %ab ab?=ed" |
|
||||
@@ -0,0 +1,114 @@
|
||||
@api @local_storage @files_external-app-required @notToImplementOnOCIS
|
||||
Feature: external-storage
|
||||
|
||||
Background:
|
||||
Given using OCS API version "1"
|
||||
And using old DAV path
|
||||
|
||||
@public_link_share-feature-required @files_sharing-app-required
|
||||
Scenario: Share by public link a file inside a local external storage
|
||||
Given these users have been created with default attributes and small skeleton files:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
And user "Alice" has created folder "/local_storage/foo"
|
||||
And user "Alice" has moved file "/textfile0.txt" to "/local_storage/foo/textfile0.txt"
|
||||
And user "Alice" has shared folder "/local_storage/foo" with user "Brian"
|
||||
When user "Brian" creates a public link share using the sharing API with settings
|
||||
| path | foo |
|
||||
Then the OCS status code should be "100"
|
||||
And the HTTP status code should be "200"
|
||||
And the fields of the last response to user "Brian" should include
|
||||
| id | A_NUMBER |
|
||||
| url | AN_URL |
|
||||
| token | A_TOKEN |
|
||||
| mimetype | httpd/unix-directory |
|
||||
|
||||
|
||||
Scenario: Move a file into storage
|
||||
Given these users have been created with default attributes and small skeleton files:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
And user "Alice" has created folder "/local_storage/foo1"
|
||||
When user "Alice" moves file "/textfile0.txt" to "/local_storage/foo1/textfile0.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And as "Brian" file "/local_storage/foo1/textfile0.txt" should exist
|
||||
And as "Alice" file "/local_storage/foo1/textfile0.txt" should exist
|
||||
|
||||
|
||||
Scenario: Move a file out of storage
|
||||
Given these users have been created with default attributes and small skeleton files:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
And user "Alice" has created folder "/local_storage/foo2"
|
||||
And user "Alice" has moved file "/textfile0.txt" to "/local_storage/foo2/textfile0.txt"
|
||||
When user "Brian" moves file "/local_storage/foo2/textfile0.txt" to "/local.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And as "Brian" file "/local_storage/foo2/textfile0.txt" should not exist
|
||||
And as "Alice" file "/local_storage/foo2/textfile0.txt" should not exist
|
||||
And as "Brian" file "/local.txt" should exist
|
||||
|
||||
@skipOnEncryptionType:user-keys
|
||||
Scenario: Copy a file into storage
|
||||
Given these users have been created with default attributes and small skeleton files:
|
||||
| username |
|
||||
| Alice |
|
||||
And user "Alice" has created folder "/local_storage/foo1"
|
||||
When user "Alice" copies file "/textfile0.txt" to "/local_storage/foo1/textfile0.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And as "Alice" file "/local_storage/foo1/textfile0.txt" should exist
|
||||
And as "Alice" file "/textfile0.txt" should exist
|
||||
|
||||
|
||||
Scenario: Copy a file out of storage
|
||||
Given these users have been created with default attributes and small skeleton files:
|
||||
| username |
|
||||
| Alice |
|
||||
And user "Alice" has created folder "/local_storage/foo1"
|
||||
And user "Alice" has uploaded file with content "ownCloud test text file inside localstorage" to "/local_storage/foo1/fileInsideLocalStorage.txt"
|
||||
When user "Alice" copies file "/local_storage/foo1/fileInsideLocalStorage.txt" to "/fileInsideLocalStorage.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And as "Alice" file "/fileInsideLocalStorage.txt" should exist
|
||||
And as "Alice" file "/local_storage/foo1/fileInsideLocalStorage.txt" should exist
|
||||
|
||||
|
||||
Scenario: Download a file that exists in filecache but not storage fails with 404
|
||||
Given user "Alice" has been created with default attributes and small skeleton files
|
||||
And user "Alice" has created folder "/local_storage/foo3"
|
||||
And user "Alice" has moved file "/textfile0.txt" to "/local_storage/foo3/textfile0.txt"
|
||||
And file "foo3/textfile0.txt" has been deleted from local storage on the server
|
||||
When user "Alice" downloads file "local_storage/foo3/textfile0.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "404"
|
||||
# See issue-37723 for discussion. In this case the server still reports the file exists
|
||||
# in the folder. The file cache will be cleared after the local storage is scanned.
|
||||
And as "Alice" file "local_storage/foo3/textfile0.txt" should exist
|
||||
|
||||
|
||||
Scenario: Upload a file to external storage while quota is set on home storage
|
||||
Given user "Alice" has been created with default attributes and small skeleton files
|
||||
And the quota of user "Alice" has been set to "1 B"
|
||||
When user "Alice" uploads file "filesForUpload/textfile.txt" to filenames based on "/local_storage/testquota.txt" with all mechanisms using the WebDAV API
|
||||
Then the HTTP status code of all upload responses should be "201"
|
||||
And as "Alice" the files uploaded to "/local_storage/testquota.txt" with all mechanisms should exist
|
||||
|
||||
|
||||
Scenario Outline: query OCS endpoint for information about the mount
|
||||
Given using OCS API version "<ocs_api_version>"
|
||||
And user "Alice" has been created with default attributes and small skeleton files
|
||||
When user "Alice" sends HTTP method "GET" to OCS API endpoint "<endpoint>"
|
||||
Then the OCS status code should be "<ocs-code>"
|
||||
And the HTTP status code should be "<http-code>"
|
||||
And the fields of the last response to user "Alice" should include
|
||||
| id | A_NUMBER |
|
||||
| name | local_storage |
|
||||
| type | dir |
|
||||
| backend | Local |
|
||||
| scope | system |
|
||||
| permissions | read |
|
||||
| class | local |
|
||||
Examples:
|
||||
| ocs_api_version | endpoint | ocs-code | http-code |
|
||||
| 1 | /apps/files_external/api/v1/mounts | 100 | 200 |
|
||||
| 2 | /apps/files_external/api/v1/mounts | 200 | 200 |
|
||||
@@ -0,0 +1,13 @@
|
||||
@api
|
||||
Feature: Other tests related to api
|
||||
|
||||
@issue-ocis-reva-100
|
||||
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 "200"
|
||||
And the content in the response should match the following content:
|
||||
"""
|
||||
User-agent: *
|
||||
Disallow: /
|
||||
|
||||
"""
|
||||
@@ -0,0 +1,393 @@
|
||||
@api @issue-ocis-reva-101 @skipOnGraph
|
||||
Feature: quota
|
||||
|
||||
Background:
|
||||
Given using OCS API version "1"
|
||||
And user "Alice" has been created with default attributes and without skeleton files
|
||||
|
||||
# Owner
|
||||
|
||||
Scenario: Uploading a file as owner having enough quota (except new chunking)
|
||||
Given the quota of user "Alice" has been set to "10 MB"
|
||||
When user "Alice" uploads file "filesForUpload/textfile.txt" to filenames based on "/testquota.txt" with all mechanisms except new chunking using the WebDAV API
|
||||
Then the HTTP status code of all upload responses should be "201"
|
||||
|
||||
@notToImplementOnOCIS @newChunking @issue-ocis-1321
|
||||
Scenario: Uploading a file as owner having enough quota (new chunking)
|
||||
Given the quota of user "Alice" has been set to "10 MB"
|
||||
And using new DAV path
|
||||
When user "Alice" uploads file "filesForUpload/textfile.txt" to "/testquota.txt" in 2 chunks with new chunking and using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
|
||||
@smokeTest
|
||||
Scenario: Uploading a file as owner having insufficient quota (except new chunking)
|
||||
Given the quota of user "Alice" has been set to "10 B"
|
||||
When user "Alice" uploads file "filesForUpload/textfile.txt" to filenames based on "/testquota.txt" with all mechanisms except new chunking using the WebDAV API
|
||||
Then the HTTP status code of all upload responses should be "507"
|
||||
And as "Alice" the files uploaded to "/testquota.txt" with all mechanisms except new chunking should not exist
|
||||
|
||||
@smokeTest @notToImplementOnOCIS @newChunking @issue-ocis-1321
|
||||
Scenario: Uploading a file as owner having insufficient quota (new chunking)
|
||||
Given the quota of user "Alice" has been set to "10 B"
|
||||
And using new DAV path
|
||||
When user "Alice" uploads file "filesForUpload/textfile.txt" to "/testquota.txt" in 2 chunks with new chunking and using the WebDAV API
|
||||
Then the HTTP status code should be "507"
|
||||
And as "Alice" file "/testquota.txt" should not exist
|
||||
|
||||
|
||||
Scenario: Overwriting a file as owner having enough quota (except new chunking)
|
||||
Given user "Alice" has uploaded file with content "test" to "/testquota.txt"
|
||||
And the quota of user "Alice" has been set to "10 MB"
|
||||
When user "Alice" overwrites from file "filesForUpload/textfile.txt" to file "/testquota.txt" with all mechanisms except new chunking using the WebDAV API
|
||||
Then the HTTP status code of all upload responses should be between "201" and "204"
|
||||
|
||||
@notToImplementOnOCIS @newChunking @issue-ocis-1321
|
||||
Scenario: Overwriting a file as owner having enough quota (new chunking)
|
||||
Given user "Alice" has uploaded file with content "test" to "/testquota.txt"
|
||||
And the quota of user "Alice" has been set to "10 MB"
|
||||
And using new DAV path
|
||||
When user "Alice" uploads file "filesForUpload/textfile.txt" to "/testquota.txt" in 2 chunks with new chunking and using the WebDAV API
|
||||
Then the HTTP status code should be between "201" and "204"
|
||||
|
||||
|
||||
Scenario: Overwriting a file as owner having insufficient quota (except new chunking)
|
||||
Given user "Alice" has uploaded file with content "test" to "/testquota.txt"
|
||||
And the quota of user "Alice" has been set to "10 B"
|
||||
When user "Alice" overwrites from file "filesForUpload/textfile.txt" to file "/testquota.txt" with all mechanisms except new chunking using the WebDAV API
|
||||
Then the HTTP status code of all upload responses should be "507"
|
||||
And the content of file "/testquota.txt" for user "Alice" should be "test"
|
||||
|
||||
@notToImplementOnOCIS @newChunking @issue-ocis-1321
|
||||
Scenario: Overwriting a file as owner having insufficient quota (new chunking)
|
||||
Given user "Alice" has uploaded file with content "test" to "/testquota.txt"
|
||||
And the quota of user "Alice" has been set to "10 B"
|
||||
And using new DAV path
|
||||
When user "Alice" uploads file "filesForUpload/textfile.txt" to "/testquota.txt" in 2 chunks with new chunking and using the WebDAV API
|
||||
Then the HTTP status code should be "507"
|
||||
And the content of file "/testquota.txt" for user "Alice" should be "test"
|
||||
|
||||
# Received shared folder
|
||||
|
||||
@files_sharing-app-required
|
||||
Scenario: Uploading a file in received folder having enough quota (except new chunking)
|
||||
Given user "Brian" has been created with default attributes and without skeleton files
|
||||
And user "Alice" has created folder "/testquota"
|
||||
And user "Alice" has shared folder "/testquota" with user "Brian" with permissions "all"
|
||||
And the quota of user "Brian" has been set to "10 B"
|
||||
And the quota of user "Alice" has been set to "10 MB"
|
||||
When user "Brian" uploads file "filesForUpload/textfile.txt" to filenames based on "/testquota/testquota.txt" with all mechanisms except new chunking using the WebDAV API
|
||||
Then the HTTP status code of all upload responses should be "201"
|
||||
|
||||
@files_sharing-app-required @notToImplementOnOCIS @newChunking @issue-ocis-1321
|
||||
Scenario: Uploading a file in received folder having enough quota (new chunking)
|
||||
Given user "Brian" has been created with default attributes and without skeleton files
|
||||
And user "Alice" has created folder "/testquota"
|
||||
And user "Alice" has shared folder "/testquota" with user "Brian" with permissions "all"
|
||||
And the quota of user "Brian" has been set to "10 B"
|
||||
And the quota of user "Alice" has been set to "10 MB"
|
||||
And using new DAV path
|
||||
When user "Brian" uploads file "filesForUpload/textfile.txt" to "/testquota/testquota.txt" in 2 chunks with new chunking and using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
|
||||
@files_sharing-app-required
|
||||
Scenario: Uploading a file in received folder having insufficient quota (except new chunking)
|
||||
Given user "Brian" has been created with default attributes and without skeleton files
|
||||
And user "Alice" has created folder "/testquota"
|
||||
And user "Alice" has shared folder "/testquota" with user "Brian" with permissions "all"
|
||||
And the quota of user "Brian" has been set to "10 MB"
|
||||
And the quota of user "Alice" has been set to "10 B"
|
||||
When user "Brian" uploads file "filesForUpload/textfile.txt" to filenames based on "/testquota/testquota.txt" with all mechanisms except new chunking using the WebDAV API
|
||||
Then the HTTP status code of all upload responses should be "507"
|
||||
And as "Brian" the files uploaded to "/testquota/testquota.txt" with all mechanisms except new chunking should not exist
|
||||
|
||||
@files_sharing-app-required @notToImplementOnOCIS @newChunking @issue-ocis-1321
|
||||
Scenario: Uploading a file in a received folder having insufficient quota (new chunking)
|
||||
Given user "Brian" has been created with default attributes and without skeleton files
|
||||
And user "Alice" has created folder "/testquota"
|
||||
And user "Alice" has shared folder "/testquota" with user "Brian" with permissions "all"
|
||||
And the quota of user "Brian" has been set to "10 MB"
|
||||
And the quota of user "Alice" has been set to "10 B"
|
||||
And using new DAV path
|
||||
When user "Brian" uploads file "filesForUpload/textfile.txt" to "/testquota/testquota.txt" in 2 chunks with new chunking and using the WebDAV API
|
||||
Then the HTTP status code should be "507"
|
||||
And as "Brian" file "/testquota/testquota.txt" should not exist
|
||||
|
||||
@files_sharing-app-required
|
||||
Scenario: Overwriting a file in received folder having enough quota (except new chunking)
|
||||
Given user "Brian" has been created with default attributes and without skeleton files
|
||||
And user "Alice" has created folder "/testquota"
|
||||
And user "Alice" has uploaded file with content "test" to "/testquota/testquota.txt"
|
||||
And user "Alice" has shared folder "/testquota" with user "Brian" with permissions "all"
|
||||
And the quota of user "Brian" has been set to "10 B"
|
||||
And the quota of user "Alice" has been set to "10 MB"
|
||||
When user "Brian" overwrites from file "filesForUpload/textfile.txt" to file "/testquota/testquota.txt" with all mechanisms except new chunking using the WebDAV API
|
||||
Then the HTTP status code of all upload responses should be between "201" and "204"
|
||||
|
||||
@files_sharing-app-required @notToImplementOnOCIS @newChunking @issue-ocis-1321
|
||||
Scenario: Overwriting a file in received folder having enough quota (new chunking)
|
||||
Given user "Brian" has been created with default attributes and without skeleton files
|
||||
And user "Alice" has created folder "/testquota"
|
||||
And user "Alice" has uploaded file with content "test" to "/testquota/testquota.txt"
|
||||
And user "Alice" has shared folder "/testquota" with user "Brian" with permissions "all"
|
||||
And the quota of user "Brian" has been set to "10 B"
|
||||
And the quota of user "Alice" has been set to "10 MB"
|
||||
And using new DAV path
|
||||
When user "Brian" uploads file "filesForUpload/textfile.txt" to "/testquota/testquota.txt" in 2 chunks with new chunking and using the WebDAV API
|
||||
Then the HTTP status code should be between "201" and "204"
|
||||
|
||||
@files_sharing-app-required
|
||||
Scenario: Overwriting a file in received folder having insufficient quota (except new chunking)
|
||||
Given user "Brian" has been created with default attributes and without skeleton files
|
||||
And user "Alice" has created folder "/testquota"
|
||||
And user "Alice" has uploaded file with content "test" to "/testquota/testquota.txt"
|
||||
And user "Alice" has shared folder "/testquota" with user "Brian" with permissions "all"
|
||||
And the quota of user "Brian" has been set to "10 MB"
|
||||
And the quota of user "Alice" has been set to "10 B"
|
||||
When user "Brian" overwrites from file "filesForUpload/textfile.txt" to file "/testquota/testquota.txt" with all mechanisms except new chunking using the WebDAV API
|
||||
Then the HTTP status code of all upload responses should be "507"
|
||||
And the content of file "/testquota/testquota.txt" for user "Alice" should be "test"
|
||||
|
||||
@files_sharing-app-required @notToImplementOnOCIS @newChunking @issue-ocis-1321
|
||||
Scenario: Overwriting a file in received folder having insufficient quota (new chunking)
|
||||
Given user "Brian" has been created with default attributes and without skeleton files
|
||||
And user "Alice" has created folder "/testquota"
|
||||
And user "Alice" has uploaded file with content "test" to "/testquota/testquota.txt"
|
||||
And user "Alice" has shared folder "/testquota" with user "Brian" with permissions "all"
|
||||
And the quota of user "Brian" has been set to "10 MB"
|
||||
And the quota of user "Alice" has been set to "10 B"
|
||||
And using new DAV path
|
||||
When user "Brian" uploads file "filesForUpload/textfile.txt" to "/testquota/testquota.txt" in 2 chunks with new chunking and using the WebDAV API
|
||||
Then the HTTP status code should be "507"
|
||||
And the content of file "/testquota/testquota.txt" for user "Alice" should be "test"
|
||||
|
||||
# Received shared file
|
||||
|
||||
@files_sharing-app-required
|
||||
Scenario: Overwriting a received file having enough quota (except new chunking)
|
||||
Given user "Brian" has been created with default attributes and without skeleton files
|
||||
And user "Alice" has uploaded file with content "test" to "/testquota.txt"
|
||||
And user "Alice" has shared file "/testquota.txt" with user "Brian" with permissions "share,update,read"
|
||||
And the quota of user "Brian" has been set to "10 B"
|
||||
And the quota of user "Alice" has been set to "10 MB"
|
||||
When user "Brian" overwrites from file "filesForUpload/textfile.txt" to file "/testquota.txt" with all mechanisms except new chunking using the WebDAV API
|
||||
Then the HTTP status code of all upload responses should be between "201" and "204"
|
||||
|
||||
@files_sharing-app-required @notToImplementOnOCIS @newChunking @issue-ocis-1321
|
||||
Scenario: Overwriting a received file having enough quota (new chunking)
|
||||
Given user "Brian" has been created with default attributes and without skeleton files
|
||||
And user "Alice" has uploaded file with content "test" to "/testquota.txt"
|
||||
And user "Alice" has shared file "/testquota.txt" with user "Brian" with permissions "share,update,read"
|
||||
And the quota of user "Brian" has been set to "10 B"
|
||||
And the quota of user "Alice" has been set to "10 MB"
|
||||
And using new DAV path
|
||||
When user "Brian" uploads file "filesForUpload/textfile.txt" to "/testquota.txt" in 2 chunks with new chunking and using the WebDAV API
|
||||
Then the HTTP status code should be between "201" and "204"
|
||||
|
||||
@files_sharing-app-required
|
||||
Scenario: Overwriting a received file having insufficient quota (except new chunking)
|
||||
Given user "Brian" has been created with default attributes and without skeleton files
|
||||
And user "Alice" has uploaded file with content "test" to "/testquota.txt"
|
||||
And user "Alice" has shared file "/testquota.txt" with user "Brian" with permissions "share,update,read"
|
||||
And the quota of user "Brian" has been set to "10 MB"
|
||||
And the quota of user "Alice" has been set to "10 B"
|
||||
When user "Brian" overwrites from file "filesForUpload/textfile.txt" to file "/testquota.txt" with all mechanisms except new chunking using the WebDAV API
|
||||
Then the HTTP status code of all upload responses should be "507"
|
||||
And the content of file "/testquota.txt" for user "Alice" should be "test"
|
||||
|
||||
@files_sharing-app-required @notToImplementOnOCIS @newChunking @issue-ocis-1321
|
||||
Scenario: Overwriting a received file having insufficient quota (new chunking)
|
||||
Given user "Brian" has been created with default attributes and without skeleton files
|
||||
And user "Alice" has uploaded file with content "test" to "/testquota.txt"
|
||||
And user "Alice" has shared file "/testquota.txt" with user "Brian" with permissions "share,update,read"
|
||||
And the quota of user "Brian" has been set to "10 MB"
|
||||
And the quota of user "Alice" has been set to "10 B"
|
||||
And using new DAV path
|
||||
When user "Brian" uploads file "filesForUpload/textfile.txt" to "/testquota.txt" in 2 chunks with new chunking and using the WebDAV API
|
||||
Then the HTTP status code should be "507"
|
||||
And the content of file "/testquota.txt" for user "Alice" should be "test"
|
||||
|
||||
|
||||
Scenario: User with zero quota cannot upload a file
|
||||
Given the quota of user "Alice" has been set to "0 B"
|
||||
When user "Alice" uploads file with content "uploaded content" to "testquota.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "507"
|
||||
And the DAV exception should be "Sabre\DAV\Exception\InsufficientStorage"
|
||||
|
||||
|
||||
Scenario: User with zero quota can create a folder
|
||||
Given the quota of user "Alice" has been set to "0 B"
|
||||
When user "Alice" creates folder "testQuota" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And as "Alice" folder "testQuota" should exist
|
||||
|
||||
@files_sharing-app-required
|
||||
Scenario: user cannot create file on shared folder by a user with zero quota
|
||||
Given the administrator has set the default folder for received shares to "Shares"
|
||||
And auto-accept shares has been disabled
|
||||
And user "Brian" has been created with default attributes and without skeleton files
|
||||
And the quota of user "Brian" has been set to "0 B"
|
||||
And the quota of user "Alice" has been set to "10 MB"
|
||||
And user "Brian" has created folder "shareFolder"
|
||||
And user "Brian" has shared file "/shareFolder" with user "Alice"
|
||||
And user "Alice" has accepted share "/shareFolder" offered by user "Brian"
|
||||
When user "Alice" uploads file with content "uploaded content" to "/Shares/shareFolder/newTextFile.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "507"
|
||||
And the DAV exception should be "Sabre\DAV\Exception\InsufficientStorage"
|
||||
And as "Brian" file "/shareFolder/newTextFile.txt" should not exist
|
||||
|
||||
@files_sharing-app-required
|
||||
Scenario: share receiver with 0 quota should not be able to move file from shared folder to home folder
|
||||
Given the administrator has set the default folder for received shares to "Shares"
|
||||
And auto-accept shares has been disabled
|
||||
And user "Brian" has been created with default attributes and without skeleton files
|
||||
And the quota of user "Brian" has been set to "0 B"
|
||||
And the quota of user "Alice" has been set to "10 MB"
|
||||
And user "Alice" has uploaded file with content "test" to "/testquota.txt"
|
||||
And user "Alice" has shared file "/testquota.txt" with user "Brian"
|
||||
And user "Brian" has accepted share "/testquota.txt" offered by user "Alice"
|
||||
When user "Brian" moves file "/Shares/testquota.txt" to "/testquota.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "507"
|
||||
And the DAV exception should be "Sabre\DAV\Exception\InsufficientStorage"
|
||||
|
||||
@files_sharing-app-required
|
||||
Scenario: sharer should be able to upload to a folder shared with user having zero quota
|
||||
Given the administrator has set the default folder for received shares to "Shares"
|
||||
And auto-accept shares has been disabled
|
||||
And user "Brian" has been created with default attributes and without skeleton files
|
||||
And the quota of user "Brian" has been set to "0 B"
|
||||
And the quota of user "Alice" has been set to "10 MB"
|
||||
And user "Alice" has created folder "shareFolder"
|
||||
And user "Alice" has uploaded file with content "test" to "/shareFolder/testquota.txt"
|
||||
And user "Alice" has shared file "/shareFolder" with user "Brian"
|
||||
And user "Brian" has accepted share "/shareFolder" offered by user "Alice"
|
||||
When user "Alice" moves file "/shareFolder/testquota.txt" to "/testquota.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And the content of file "/testquota.txt" for user "Alice" should be "test"
|
||||
And as "Brian" file "/Shares/testquota" should not exist
|
||||
|
||||
@files_sharing-app-required
|
||||
Scenario: share receiver with 0 quota should be able to upload on shared folder
|
||||
Given the administrator has set the default folder for received shares to "Shares"
|
||||
And auto-accept shares has been disabled
|
||||
And user "Brian" has been created with default attributes and without skeleton files
|
||||
And the quota of user "Brian" has been set to "0 B"
|
||||
And the quota of user "Alice" has been set to "10 MB"
|
||||
And user "Alice" has created folder "shareFolder"
|
||||
And user "Alice" has shared file "/shareFolder" with user "Brian"
|
||||
And user "Brian" has accepted share "/shareFolder" offered by user "Alice"
|
||||
When user "Brian" uploads file with content "uploaded content" to "/Shares/shareFolder/newTextFile.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And the content of file "/shareFolder/newTextFile.txt" for user "Alice" should be "uploaded content"
|
||||
|
||||
|
||||
Scenario: User should retain their old files even if their quota is set to 0
|
||||
Given user "Alice" has uploaded file with content "test" to "/testquota.txt"
|
||||
And the quota of user "Alice" has been set to "0 B"
|
||||
Then the content of file "/testquota.txt" for user "Alice" should be "test"
|
||||
|
||||
|
||||
Scenario: User should be able to restore their deleted file when their quota is set to zero
|
||||
Given user "Alice" has uploaded file with content "test" to "/testquota.txt"
|
||||
And user "Alice" has deleted file "/testquota.txt"
|
||||
And the quota of user "Alice" has been set to "0 B"
|
||||
When user "Alice" restores the file with original path "/testquota.txt" to "/testquota.txt" using the trashbin API
|
||||
Then the HTTP status code should be "201"
|
||||
And the content of file "/testquota.txt" for user "Alice" should be "test"
|
||||
|
||||
@files_sharing-app-required @skipOnOcV10.10
|
||||
Scenario: share receiver with 0 quota can copy empty file from shared folder to home folder
|
||||
Given the administrator has set the default folder for received shares to "Shares"
|
||||
And auto-accept shares has been disabled
|
||||
And user "Brian" has been created with default attributes and without skeleton files
|
||||
And the quota of user "Brian" has been set to "0 B"
|
||||
And the quota of user "Alice" has been set to "10 MB"
|
||||
And user "Alice" has created folder "shareFolder"
|
||||
And user "Alice" has uploaded file with content "" to "/shareFolder/testquota.txt"
|
||||
And user "Alice" has shared folder "/shareFolder" with user "Brian"
|
||||
And user "Brian" has accepted share "/shareFolder" offered by user "Alice"
|
||||
When user "Brian" copies file "/Shares/shareFolder/testquota.txt" to "/testquota.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And as "Brian" file "testquota.txt" should exist
|
||||
|
||||
|
||||
Scenario: User with zero quota can upload an empty file
|
||||
Given the quota of user "Alice" has been set to "0 B"
|
||||
When user "Alice" uploads file with content "" to "testquota.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And as "Alice" file "testquota.txt" should exist
|
||||
|
||||
@files_sharing-app-required @skipOnOcV10.10
|
||||
Scenario Outline: share receiver with insufficient quota should not be able to copy received shared file to home folder
|
||||
Given the administrator has set the default folder for received shares to "Shares"
|
||||
And auto-accept shares has been disabled
|
||||
And user "Brian" has been created with default attributes and without skeleton files
|
||||
And the quota of user "Brian" has been set to "<quota>"
|
||||
And the quota of user "Alice" has been set to "10 MB"
|
||||
And user "Alice" has uploaded file with content "<file-content>" to "/testquota.txt"
|
||||
And user "Alice" has shared file "/testquota.txt" with user "Brian"
|
||||
And user "Brian" has accepted share "/testquota.txt" offered by user "Alice"
|
||||
When user "Brian" copies file "/Shares/testquota.txt" to "/testquota.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "507"
|
||||
And the DAV exception should be "Sabre\DAV\Exception\InsufficientStorage"
|
||||
And as "Brian" file "/testquota.txt" should not exist
|
||||
Examples:
|
||||
| quota | file-content |
|
||||
| 0 B | four |
|
||||
| 10 B | test-content-15 |
|
||||
|
||||
@files_sharing-app-required @skipOnOcV10.10
|
||||
Scenario Outline: share receiver with insufficient quota should not be able to copy file from shared folder to home folder
|
||||
Given the administrator has set the default folder for received shares to "Shares"
|
||||
And auto-accept shares has been disabled
|
||||
And user "Brian" has been created with default attributes and without skeleton files
|
||||
And the quota of user "Brian" has been set to "<quota>"
|
||||
And the quota of user "Alice" has been set to "10 MB"
|
||||
And user "Alice" has created folder "shareFolder"
|
||||
And user "Alice" has uploaded file with content "<file-content>" to "/shareFolder/testquota.txt"
|
||||
And user "Alice" has shared folder "/shareFolder" with user "Brian"
|
||||
And user "Brian" has accepted share "/shareFolder" offered by user "Alice"
|
||||
When user "Brian" copies file "/Shares/shareFolder/testquota.txt" to "/testquota.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "507"
|
||||
And the DAV exception should be "Sabre\DAV\Exception\InsufficientStorage"
|
||||
And as "Brian" file "/testquota.txt" should not exist
|
||||
Examples:
|
||||
| quota | file-content |
|
||||
| 0 B | four |
|
||||
| 10 B | test-content-15 |
|
||||
|
||||
@files_sharing-app-required @skipOnOcV10.10 @skipOnEncryption @issue-encryption-357
|
||||
Scenario: share receiver of a share with insufficient quota should not be able to copy from home folder to the received shared file
|
||||
Given the administrator has set the default folder for received shares to "Shares"
|
||||
And auto-accept shares has been disabled
|
||||
And user "Brian" has been created with default attributes and without skeleton files
|
||||
And the quota of user "Brian" has been set to "10 MB"
|
||||
And the quota of user "Alice" has been set to "10 B"
|
||||
And user "Alice" has uploaded file with content "short" to "/testquota.txt"
|
||||
And user "Brian" has uploaded file with content "longer line of text" to "/testquota.txt"
|
||||
And user "Alice" has shared file "/testquota.txt" with user "Brian"
|
||||
And user "Brian" has accepted share "/testquota.txt" offered by user "Alice"
|
||||
When user "Brian" copies file "/testquota.txt" to "/Shares/testquota.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "507"
|
||||
And the DAV exception should be "Sabre\DAV\Exception\InsufficientStorage"
|
||||
And as "Brian" file "/Shares/testquota.txt" should exist
|
||||
And as "Alice" file "/testquota.txt" should exist
|
||||
# The copy should have failed, so Alice should still see the original content
|
||||
And the content of file "/testquota.txt" for user "Alice" should be "short"
|
||||
|
||||
@files_sharing-app-required @skipOnOcV10.10
|
||||
Scenario: share receiver of a share with insufficient quota should not be able to copy file from home folder to the received shared folder
|
||||
Given the administrator has set the default folder for received shares to "Shares"
|
||||
And auto-accept shares has been disabled
|
||||
And user "Brian" has been created with default attributes and without skeleton files
|
||||
And the quota of user "Brian" has been set to "10 MB"
|
||||
And the quota of user "Alice" has been set to "10 B"
|
||||
And user "Alice" has created folder "shareFolder"
|
||||
And user "Alice" has shared folder "/shareFolder" with user "Brian"
|
||||
And user "Brian" has accepted share "/shareFolder" offered by user "Alice"
|
||||
And user "Brian" has uploaded file with content "test-content-15" to "/testquota.txt"
|
||||
When user "Brian" copies file "/testquota.txt" to "/Shares/shareFolder/testquota.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "507"
|
||||
And the DAV exception should be "Sabre\DAV\Exception\InsufficientStorage"
|
||||
And as "Brian" file "/testquota.txt" should exist
|
||||
# The copy should have failed, so Alice should not see the file
|
||||
And as "Alice" file "/shareFolder/testquota.txt" should not exist
|
||||
@@ -0,0 +1,10 @@
|
||||
@api
|
||||
Feature: Status
|
||||
|
||||
@smokeTest
|
||||
Scenario: Status.php is correct
|
||||
When the administrator requests status.php
|
||||
Then the status.php response should include
|
||||
"""
|
||||
{"installed":true,"maintenance":false,"needsDbUpgrade":false,"version":"$CURRENT_VERSION","versionstring":"$CURRENT_VERSION_STRING","edition":"$EDITION","productname":"$PRODUCTNAME","product":"$PRODUCT"}
|
||||
"""
|
||||
@@ -0,0 +1,68 @@
|
||||
@api @notToImplementOnOCIS @issue-ocis-1241
|
||||
Feature: Users sync
|
||||
|
||||
Background:
|
||||
Given these users have been created with default attributes and without skeleton files:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
|
||||
|
||||
Scenario Outline: Trying to sync a user when there is no external user backend
|
||||
Given using OCS API version "<ocs-api-version>"
|
||||
When the administrator tries to sync user "Alice" using the OCS API
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "<ocs-status-code>"
|
||||
And the OCS status message should be ""
|
||||
Examples:
|
||||
| ocs-api-version | ocs-status-code |
|
||||
| 1 | 100 |
|
||||
| 2 | 200 |
|
||||
|
||||
|
||||
Scenario Outline: Trying to sync a user which does not exist
|
||||
Given using OCS API version "<ocs-api-version>"
|
||||
When the administrator tries to sync user "nonexistentuser" using the OCS API
|
||||
Then the HTTP status code should be "<http-status-code>"
|
||||
And the OCS status code should be "404"
|
||||
And the OCS status message should be "User is not known in any user backend: nonexistentuser"
|
||||
Examples:
|
||||
| ocs-api-version | http-status-code |
|
||||
| 1 | 200 |
|
||||
| 2 | 404 |
|
||||
|
||||
|
||||
Scenario Outline: Trying to sync a user as another user which does not exist
|
||||
Given using OCS API version "<ocs-api-version>"
|
||||
When user "nonexistentuser" tries to sync user "Brian" using the OCS API
|
||||
Then the HTTP status code should be "401"
|
||||
And the OCS status code should be "997"
|
||||
And the OCS status message should be "Unauthorised"
|
||||
Examples:
|
||||
| ocs-api-version |
|
||||
| 1 |
|
||||
| 2 |
|
||||
|
||||
@smokeTest
|
||||
Scenario Outline: Trying to sync a user by non admin user
|
||||
Given using OCS API version "<ocs-api-version>"
|
||||
When user "Alice" tries to sync user "Brian" using the OCS API
|
||||
Then the HTTP status code should be "<http-status-code>"
|
||||
And the OCS status code should be "<ocs-status-code>"
|
||||
And the OCS status message should be "Logged in user must be an admin"
|
||||
Examples:
|
||||
| ocs-api-version | ocs-status-code | http-status-code |
|
||||
| 1 | 403 | 200 |
|
||||
| 2 | 403 | 403 |
|
||||
|
||||
|
||||
Scenario Outline: Trying to sync a user by admin using an incorrect password
|
||||
Given using OCS API version "<ocs-api-version>"
|
||||
When the administrator tries to sync user "Brian" using password "invalid" and the OCS API
|
||||
Then the HTTP status code should be "401"
|
||||
And the OCS status code should be "997"
|
||||
And the OCS status message should be "Unauthorised"
|
||||
Examples:
|
||||
| ocs-api-version |
|
||||
| 1 |
|
||||
| 2 |
|
||||
Reference in New Issue
Block a user