sevenhill/QSfera
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

refactored feature files

Browse Source
This commit is contained in:
prajwol
2023-06-08 14:59:03 +05:45
parent b6b85baceb
commit edc8e96469
21 changed files with 236 additions and 191 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tests/acceptance/features/coreApiTrashbin/trashbinDelete.feature
+4 -4
View File
@@ -14,7 +14,7 @@ Feature: files and folders can be deleted from the trashbin
And user "Alice" has uploaded file with content "to delete" to "/PARENT/CHILD/child.txt"
@smokeTest
Scenario Outline: Trashbin can be emptied
Scenario Outline: trashbin can be emptied
Given using <dav-path> DAV path
And user "Alice" has uploaded file with content "file with comma" to "sample,0.txt"
And user "Alice" has uploaded file with content "file with comma" to "sample,1.txt"
@@ -85,7 +85,7 @@ Feature: files and folders can be deleted from the trashbin
| spaces |
Scenario Outline: User tries to delete another user's trashbin
Scenario Outline: user tries to delete another user's trashbin
Given using <dav-path> DAV path
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has deleted file "/textfile0.txt"
@@ -105,7 +105,7 @@ Feature: files and folders can be deleted from the trashbin
| spaces | 404 |
Scenario Outline: User tries to delete trashbin file using invalid password
Scenario Outline: user tries to delete trashbin file using invalid password
Given using <dav-path> DAV path
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has deleted file "/textfile0.txt"
@@ -128,7 +128,7 @@ Feature: files and folders can be deleted from the trashbin
| spaces |
Scenario Outline: User tries to delete trashbin file using no password
Scenario Outline: user tries to delete trashbin file using no password
Given using <dav-path> DAV path
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has deleted file "/textfile0.txt"
tests/acceptance/features/coreApiTrashbin/trashbinFilesFolders.feature
+7 -7
View File
@@ -159,7 +159,7 @@ Feature: files and folders exist in the trashbin after being deleted
| spaces |
@issue-3561
Scenario Outline: Listing other user's trashbin is prohibited
Scenario Outline: listing other user's trashbin is prohibited
Given using <dav-path> DAV path
And user "testtrashbin100" has been created with default attributes and without skeleton files
And user "testtrashbin100" has uploaded file "filesForUpload/textfile.txt" to "/textfile1.txt"
@@ -177,7 +177,7 @@ Feature: files and folders exist in the trashbin after being deleted
| spaces | 404 |
@issue-3561 @smokeTest
Scenario Outline: Listing other user's trashbin is prohibited with multiple files on trashbin
Scenario Outline: listing other user's trashbin is prohibited with multiple files on trashbin
Given using <dav-path> DAV path
And user "testtrashbin101" has been created with default attributes and without skeleton files
And user "testtrashbin101" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
@@ -198,7 +198,7 @@ Feature: files and folders exist in the trashbin after being deleted
| spaces | 404 |
@issue-3561 @provisioning_api-app-required
Scenario Outline: Listing other user's trashbin is prohibited for newly recreated user with same name
Scenario Outline: listing other user's trashbin is prohibited for newly recreated user with same name
Given using <dav-path> DAV path
And user "testtrashbin102" has been created with default attributes and without skeleton files
And user "testtrashbin102" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
@@ -224,7 +224,7 @@ Feature: files and folders exist in the trashbin after being deleted
| spaces | 404 |
@issue-3561
Scenario Outline: Listing other user's empty unused trashbin is prohibited
Scenario Outline: listing other user's empty unused trashbin is prohibited
Given using <dav-path> DAV path
And user "testtrashbinempty" has been created with default attributes and without skeleton files
And user "testtrashbinempty" has uploaded file "filesForUpload/textfile.txt" to "/textfile1.txt"
@@ -240,7 +240,7 @@ Feature: files and folders exist in the trashbin after being deleted
| spaces |
@issue-3561
Scenario Outline: Listing non-existent user's trashbin is prohibited
Scenario Outline: listing non-existent user's trashbin is prohibited
Given using <dav-path> DAV path
When user "Alice" tries to list the trashbin content for user "testtrashbinnotauser"
Then the HTTP status code should be "404"
@@ -254,7 +254,7 @@ Feature: files and folders exist in the trashbin after being deleted
| spaces |
@smokeTest
Scenario Outline: Get trashbin content with wrong password
Scenario Outline: get trashbin content with wrong password
Given using <dav-path> DAV path
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And user "Alice" has deleted file "/textfile0.txt"
@@ -273,7 +273,7 @@ Feature: files and folders exist in the trashbin after being deleted
| spaces |
@smokeTest
Scenario Outline: Get trashbin content without password
Scenario Outline: get trashbin content without password
Given using <dav-path> DAV path
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And user "Alice" has deleted file "/textfile0.txt"
tests/acceptance/features/coreApiTrashbin/trashbinSharingToShares.feature
+3
View File
@@ -1,5 +1,8 @@
@api
Feature: using trashbin together with sharing
As a user
I want the deletion of the resources that I shared to end up in my trashbin
So that I can restore the resources that were accidentally deleted
Background:
Given user "Alice" has been created with default attributes and without skeleton files
tests/acceptance/features/coreApiTrashbinRestore/trashbinRestore.feature
+20 -20
View File
@@ -1,5 +1,5 @@
@api @issue-1324
Feature: Restore deleted files/folders
Feature: restore deleted files/folders
As a user
I would like to restore files/folders
So that I can recover accidentally deleted files/folders in ownCloud
@@ -9,7 +9,7 @@ Feature: Restore deleted files/folders
And user "Alice" has uploaded file with content "file to delete" to "/textfile0.txt"
@smokeTest
Scenario Outline: A deleted file can be restored
Scenario Outline: deleted file can be restored
Given using <dav-path> DAV path
And user "Alice" has created folder "/FOLDER"
And user "Alice" has created folder "/PARENT"
@@ -35,7 +35,7 @@ Feature: Restore deleted files/folders
| new |
Scenario Outline: A file deleted from a folder can be restored to the original folder
Scenario Outline: file deleted from a folder can be restored to the original folder
Given using <dav-path> DAV path
And user "Alice" has created folder "/new-folder"
And user "Alice" has moved file "/textfile0.txt" to "/new-folder/new-file.txt"
@@ -51,7 +51,7 @@ Feature: Restore deleted files/folders
| new |
Scenario Outline: A file deleted from a folder is restored to the original folder if the original folder was deleted and restored
Scenario Outline: file deleted from a folder is restored to the original folder if the original folder was deleted and restored
Given using <dav-path> DAV path
And user "Alice" has created folder "/new-folder"
And user "Alice" has moved file "/textfile0.txt" to "/new-folder/new-file.txt"
@@ -69,7 +69,7 @@ Feature: Restore deleted files/folders
| new |
Scenario Outline: a file is deleted and restored to a new destination
Scenario Outline: file is deleted and restored to a new destination
Given using <dav-path> DAV path
And user "Alice" has created folder "/PARENT"
And user "Alice" has created folder "/PARENT/CHILD"
@@ -111,7 +111,7 @@ Feature: Restore deleted files/folders
| new | "/PARENT/.hiddenfile0.txt" | ".hiddenfile0.txt" |
Scenario Outline: A file deleted from a folder is restored to the original folder if the original folder was deleted and recreated
Scenario Outline: file deleted from a folder is restored to the original folder if the original folder was deleted and recreated
Given using <dav-path> DAV path
And user "Alice" has created folder "/new-folder"
And user "Alice" has moved file "/textfile0.txt" to "/new-folder/new-file.txt"
@@ -131,7 +131,7 @@ Feature: Restore deleted files/folders
| new |
@smokeTest
Scenario Outline: A deleted file cannot be restored by a different user
Scenario Outline: deleted file cannot be restored by a different user
Given using <dav-path> DAV path
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has deleted file "/textfile0.txt"
@@ -146,7 +146,7 @@ Feature: Restore deleted files/folders
| new | 404 |
@smokeTest
Scenario Outline: A deleted file cannot be restored with invalid password
Scenario Outline: deleted file cannot be restored with invalid password
Given using <dav-path> DAV path
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has deleted file "/textfile0.txt"
@@ -161,7 +161,7 @@ Feature: Restore deleted files/folders
| new |
@smokeTest
Scenario Outline: A deleted file cannot be restored without using a password
Scenario Outline: deleted file cannot be restored without using a password
Given using <dav-path> DAV path
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has deleted file "/textfile0.txt"
@@ -176,7 +176,7 @@ Feature: Restore deleted files/folders
| new |
Scenario Outline: Files with strange names can be restored
Scenario Outline: files with strange names can be restored
Given using <dav-path> DAV path
And user "Alice" has uploaded file with content "file original content" to "<file-to-upload>"
And user "Alice" has deleted file "<file-to-upload>"
@@ -195,7 +195,7 @@ Feature: Restore deleted files/folders
| new | sample,1.txt |
Scenario Outline: A file deleted from a multi level sub-folder can be restored to the original folder
Scenario Outline: file deleted from a multi level sub-folder can be restored to the original folder
Given using <dav-path> DAV path
And user "Alice" has created folder "/new-folder"
And user "Alice" has created folder "/new-folder/folder1/"
@@ -213,7 +213,7 @@ Feature: Restore deleted files/folders
| new |
Scenario Outline: A deleted multi level folder can be restored including the content
Scenario Outline: deleted multi level folder can be restored including the content
Given using <dav-path> DAV path
And user "Alice" has created folder "/new-folder"
And user "Alice" has created folder "/new-folder/folder1/"
@@ -231,7 +231,7 @@ Feature: Restore deleted files/folders
| new |
Scenario Outline: A subfolder from a deleted multi level folder can be restored including the content
Scenario Outline: subfolder from a deleted multi level folder can be restored including the content
Given using <dav-path> DAV path
And user "Alice" has created folder "/new-folder"
And user "Alice" has created folder "/new-folder/folder1"
@@ -251,7 +251,7 @@ Feature: Restore deleted files/folders
| new |
Scenario Outline: A file from a deleted multi level sub-folder can be restored
Scenario Outline: file from a deleted multi level sub-folder can be restored
Given using <dav-path> DAV path
And user "Alice" has created folder "/new-folder"
And user "Alice" has created folder "/new-folder/folder1/"
@@ -271,7 +271,7 @@ Feature: Restore deleted files/folders
| new |
Scenario Outline: A deleted hidden file can be restored
Scenario Outline: deleted hidden file can be restored
Given using <dav-path> DAV path
And user "Alice" has created folder "/FOLDER"
And user "Alice" has uploaded the following files with content "hidden file"
@@ -383,7 +383,7 @@ Feature: Restore deleted files/folders
| new |
Scenario Outline: A deleted file inside a nested folder can be restored to a different location
Scenario Outline: deleted file inside a nested folder can be restored to a different location
Given using <dav-path> DAV path
And user "Alice" has created folder "/parent_folder"
And user "Alice" has created folder "/parent_folder/sub"
@@ -401,7 +401,7 @@ Feature: Restore deleted files/folders
| new |
Scenario Outline: A deleted file inside a nested folder cannot be restored to the original location if the location doesn't exist
Scenario Outline: deleted file inside a nested folder cannot be restored to the original location if the location doesn't exist
Given using <dav-path> DAV path
And user "Alice" has created folder "/parent_folder"
And user "Alice" has created folder "/parent_folder/sub"
@@ -420,7 +420,7 @@ Feature: Restore deleted files/folders
| new |
Scenario Outline: A deleted file inside a nested folder can be restored to the original location if the location exists
Scenario Outline: deleted file inside a nested folder can be restored to the original location if the location exists
Given using <dav-path> DAV path
And user "Alice" has created folder "/parent_folder"
And user "Alice" has created folder "/parent_folder/sub"
@@ -444,7 +444,7 @@ Feature: Restore deleted files/folders
| new |
Scenario Outline: A deleted file inside a nested folder cannot be restored without the destination
Scenario Outline: deleted file inside a nested folder cannot be restored without the destination
Given using <dav-path> DAV path
And user "Alice" has created folder "/parent_folder"
And user "Alice" has created folder "/parent_folder/sub"
@@ -463,7 +463,7 @@ Feature: Restore deleted files/folders
| new |
Scenario Outline: A deleted file cannot be restored without the destination
Scenario Outline: deleted file cannot be restored without the destination
Given using <dav-path> DAV path
And user "Alice" has uploaded file with content "parent text" to "/parent.txt"
And user "Alice" has deleted file "parent.txt"
tests/acceptance/features/coreApiVersions/fileVersionAuthor.feature
+3
View File
@@ -1,5 +1,8 @@
@api @issue-2914
Feature: file versions remember the author of each version
As a user
I want to know the author of each version of a file
So that I can better understand the version history and choose a version to restore
Background:
Given using OCS API version "2"
tests/acceptance/features/coreApiVersions/fileVersions.feature
+33 -31
View File
@@ -1,6 +1,8 @@
@api
Feature: dav-versions
As a user
I want the versions of files to be available
So that I can manage the changes made to the files
Background:
Given using OCS API version "2"
@@ -8,13 +10,13 @@ Feature: dav-versions
And user "Alice" has been created with default attributes and without skeleton files
Scenario: Upload file and no version is available
Scenario: upload file and no version is available
When user "Alice" uploads file "filesForUpload/davtest.txt" to "/davtest.txt" using the WebDAV API
Then the HTTP status code should be "201"
And the version folder of file "/davtest.txt" for user "Alice" should contain "0" elements
Scenario: Upload file and no version is available using various chunking methods (except new chunking)
Scenario: upload file and no version is available using various chunking methods (except new chunking)
When user "Alice" uploads file "filesForUpload/davtest.txt" to filenames based on "/davtest.txt" with all mechanisms except new chunking using the WebDAV API
Then the HTTP status code should be "200"
And the version folder of file "/davtest.txt-olddav-regular" for user "Alice" should contain "0" elements
@@ -22,7 +24,7 @@ Feature: dav-versions
And the version folder of file "/davtest.txt-olddav-oldchunking" for user "Alice" should contain "0" elements
@smokeTest
Scenario: Upload a file twice and versions are available
Scenario: upload a file twice and versions are available
When user "Alice" uploads file "filesForUpload/davtest.txt" to "/davtest.txt" using the WebDAV API
And user "Alice" uploads file "filesForUpload/davtest.txt" to "/davtest.txt" using the WebDAV API
Then the HTTP status code of responses on each endpoint should be "201, 204" respectively
@@ -30,7 +32,7 @@ Feature: dav-versions
And the content length of file "/davtest.txt" with version index "1" for user "Alice" in versions folder should be "8"
Scenario: Upload a file twice and versions are available using various chunking methods (except new chunking)
Scenario: upload a file twice and versions are available using various chunking methods (except new chunking)
When user "Alice" uploads file "filesForUpload/davtest.txt" to filenames based on "/davtest.txt" with all mechanisms except new chunking using the WebDAV API
And user "Alice" uploads file "filesForUpload/davtest.txt" to filenames based on "/davtest.txt" with all mechanisms except new chunking using the WebDAV API
Then the HTTP status code of responses on all endpoints should be "200"
@@ -39,7 +41,7 @@ Feature: dav-versions
And the version folder of file "/davtest.txt-olddav-oldchunking" for user "Alice" should contain "1" element
@smokeTest
Scenario: Remove a file
Scenario: remove a file
Given user "Alice" has uploaded file "filesForUpload/davtest.txt" to "/davtest.txt"
And user "Alice" has uploaded file "filesForUpload/davtest.txt" to "/davtest.txt"
And the version folder of file "/davtest.txt" for user "Alice" should contain "1" element
@@ -49,7 +51,7 @@ Feature: dav-versions
And the version folder of file "/davtest.txt" for user "Alice" should contain "0" elements
@smokeTest
Scenario: Restore a file and check, if the content is now in the current file
Scenario: restore a file and check its content
Given user "Alice" has uploaded file with content "Test Content." to "/davtest.txt"
And user "Alice" has uploaded file with content "Content Test Updated." to "/davtest.txt"
And the version folder of file "/davtest.txt" for user "Alice" should contain "1" element
@@ -58,7 +60,7 @@ Feature: dav-versions
And the content of file "/davtest.txt" for user "Alice" should be "Test Content."
@smokeTest @skipOnStorage:ceph @skipOnStorage:scality
Scenario: Restore a file back to bigger content and check, if the content is now in the current file
Scenario: restore a file back to bigger content and check its content
Given user "Alice" has uploaded file with content "Back To The Future." to "/davtest.txt"
And user "Alice" has uploaded file with content "Update Content." to "/davtest.txt"
And the version folder of file "/davtest.txt" for user "Alice" should contain "1" element
@@ -67,7 +69,7 @@ Feature: dav-versions
And the content of file "/davtest.txt" for user "Alice" should be "Back To The Future."
@smokeTest @skipOnStorage:ceph
Scenario Outline: Uploading a chunked file does create the correct version that can be restored
Scenario Outline: uploading a chunked file does create the correct version that can be restored
Given using <dav-path> DAV path
And user "Alice" has uploaded file with content "textfile0" to "textfile0.txt"
When user "Alice" uploads file "filesForUpload/davtest.txt" to "/textfile0.txt" in 2 chunks using the WebDAV API
@@ -83,7 +85,7 @@ Feature: dav-versions
| old | 201 |
@skipOnStorage:ceph @skipOnStorage:scality
Scenario: Restore a file and check, if the content and correct checksum is now in the current file
Scenario: restore a file and check the content and checksum
Given user "Alice" has uploaded file with content "AAAAABBBBBCCCCC" and checksum "MD5:45a72715acdd5019c5be30bdbb75233e" to "/davtest.txt"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/davtest.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a"
And the version folder of file "/davtest.txt" for user "Alice" should contain "1" element
@@ -93,7 +95,7 @@ Feature: dav-versions
And as user "Alice" the webdav checksum of "/davtest.txt" via propfind should match "SHA1:acfa6b1565f9710d4d497c6035d5c069bd35a8e8 MD5:45a72715acdd5019c5be30bdbb75233e ADLER32:1ecd03df"
Scenario: User cannot access meta folder of a file which is owned by somebody else
Scenario: user cannot access meta folder of a file which is owned by somebody else
Given user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "123" to "/davtest.txt"
And we save it into "FILEID"
@@ -101,13 +103,13 @@ Feature: dav-versions
Then the HTTP status code should be "400" or "404"
Scenario: User cannot access meta folder of a file which does not exist
Scenario: user cannot access meta folder of a file which does not exist
Given user "Brian" has been created with default attributes and without skeleton files
When user "Brian" sends HTTP method "PROPFIND" to URL "/remote.php/dav/meta/MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU2OjhjY2QyNzUxLTkwYTQtNDBmMi1iOWYzLTYxZWRmODQ0MjFmNA=="
Then the HTTP status code should be "400" or "404"
Scenario Outline: User cannot access meta folder of a file with invalid fileid
Scenario Outline: user cannot access meta folder of a file with invalid fileid
Given user "Brian" has been created with default attributes and without skeleton files
When user "Brian" sends HTTP method "PROPFIND" to URL "/remote.php/dav/meta/<file-id>/v"
Then the HTTP status code should be "400" or "404"
@@ -119,7 +121,7 @@ Feature: dav-versions
| MTI4NGQyMzgtYWE5Mi00MmNlLWJkxzQtMGIwMDAwMDA5MTU2OjhjY2QyNzUxLTkwYTQtNDBmMi1iOWYzLTYxZWRmODQ0MjFmNA== | 1284d238-aa92-42ce-bd�4-0b0000009156:8ccd2751-90a4-40f2-b9f3-61edf84421f4 | with : and � sign |
Scenario: the version history is preserved when a file is renamed
Scenario: version history is preserved when a file is renamed
Given user "Alice" has uploaded file with content "old content" to "/textfile.txt"
And user "Alice" has uploaded file with content "new content" to "/textfile.txt"
And user "Alice" has moved file "/textfile.txt" to "/renamedfile.txt"
@@ -128,7 +130,7 @@ Feature: dav-versions
And the content of file "/renamedfile.txt" for user "Alice" should be "old content"
Scenario: User can access version number after moving a file
Scenario: user can access version number after moving a file
Given user "Alice" has created folder "testFolder"
And user "Alice" has uploaded file with content "uploaded content" to "textfile0.txt"
And user "Alice" has uploaded file with content "version 1" to "textfile0.txt"
@@ -140,14 +142,14 @@ Feature: dav-versions
And the number of versions should be "3"
Scenario: Original file has version number 0
Scenario: original file has version number 0
Given user "Alice" has uploaded file with content "uploaded content" to "textfile0.txt"
When user "Alice" gets the number of versions of file "textfile0.txt"
Then the HTTP status code should be "207"
And the number of versions should be "0"
Scenario: the number of etag elements in response changes according to version of the file
Scenario: number of etag elements in response changes according to version of the file
Given user "Alice" has uploaded file with content "uploaded content" 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"
@@ -194,20 +196,20 @@ Feature: dav-versions
And the downloaded content should be "uploaded content"
Scenario: User can retrieve meta information of a root folder
Scenario: user can retrieve meta information of a root folder
When user "Alice" retrieves the meta information of file "/" using the meta API
Then the HTTP status code should be "207"
And the single response should contain a property "oc:meta-path-for-user" with value "/"
Scenario: User can retrieve meta information of a file
Scenario: user can retrieve meta information of a file
Given user "Alice" has uploaded file with content "123" to "/davtest.txt"
When user "Alice" retrieves the meta information of file "/davtest.txt" using the meta API
Then the HTTP status code should be "207"
And the single response should contain a property "oc:meta-path-for-user" with value "/davtest.txt"
Scenario: User can retrieve meta information of a file inside folder
Scenario: user can retrieve meta information of a file inside folder
Given user "Alice" has created folder "testFolder"
And user "Alice" has uploaded file with content "123" to "/testFolder/davtest.txt"
When user "Alice" retrieves the meta information of file "/testFolder/davtest.txt" using the meta API
@@ -215,7 +217,7 @@ Feature: dav-versions
And the single response should contain a property "oc:meta-path-for-user" with value "/testFolder/davtest.txt"
Scenario: User cannot retrieve meta information of a file which is owned by somebody else
Scenario: user cannot retrieve meta information of a file which is owned by somebody else
Given user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "123" to "/davtest.txt "
And we save it into "FILEID"
@@ -223,7 +225,7 @@ Feature: dav-versions
Then the HTTP status code should be "404"
Scenario Outline: User cannot retrieve meta information of a file that does not exist
Scenario Outline: user cannot retrieve meta information of a file that does not exist
When user "Alice" retrieves the meta information of fileId "<file-id>" using the meta API
Then the HTTP status code should be "400" or "404"
Examples:
@@ -234,7 +236,7 @@ Feature: dav-versions
| MTI4NGQyMzgtYWE5Mi00MmNlLWJkxzQtMGIwMDAwMDA5MTU2OjhjY2QyNzUxLTkwYTQtNDBmMi1iOWYzLTYxZWRmODQ0MjFmNA== | 1284d238-aa92-42ce-bd�4-0b0000009156:8ccd2751-90a4-40f2-b9f3-61edf84421f4 | with : and � sign |
Scenario: File versions sets back after getting deleted and restored from trashbin
Scenario: file versions sets back after getting deleted and restored from trashbin
Given user "Alice" has uploaded file with content "Old Test Content." to "/davtest.txt"
And user "Alice" has uploaded file with content "New Test Content." to "/davtest.txt"
And the version folder of file "/davtest.txt" for user "Alice" should contain "1" element
@@ -250,14 +252,14 @@ Feature: dav-versions
And the content of file "/davtest.txt" for user "Alice" should be "Old Test Content."
Scenario: Upload the same file twice with the same mtime and a version is available
Scenario: upload the same file twice with the same mtime and a version is available
Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the WebDAV API
When user "Alice" uploads file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the WebDAV API
Then the HTTP status code should be "204"
And the version folder of file "/file.txt" for user "Alice" should contain "1" element
Scenario: Upload the same file more than twice with the same mtime and only one version is available
Scenario: upload the same file more than twice with the same mtime and only one version is available
Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the WebDAV API
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the WebDAV API
When user "Alice" uploads file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the WebDAV API
@@ -265,7 +267,7 @@ Feature: dav-versions
And the version folder of file "/file.txt" for user "Alice" should contain "1" element
Scenario: Upload the same file twice with the same mtime and no version after restoring
Scenario: upload the same file twice with the same mtime and no version after restoring
Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the WebDAV API
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "file.txt" with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the WebDAV API
When user "Alice" restores version index "1" of file "/file.txt" using the WebDAV API
@@ -369,7 +371,7 @@ Feature: dav-versions
And the content of file "/Shares/sharingfolder/sharefile.txt" for user "Carol" should be "First content"
Scenario Outline: Moving a file (with versions) into a shared folder as the sharee and as the sharer
Scenario Outline: moving a file (with versions) into a shared folder as the sharee and as the sharer
Given using <dav_version> DAV path
And user "Brian" has been created with default attributes and without skeleton files
And user "Brian" has created folder "/testshare"
@@ -394,7 +396,7 @@ Feature: dav-versions
| new | Brian | /testshare |
Scenario Outline: Moving a file (with versions) out of a shared folder as the sharee and as the sharer
Scenario Outline: moving a file (with versions) out of a shared folder as the sharee and as the sharer
Given using <dav_version> DAV path
And user "Brian" has been created with default attributes and without skeleton files
And user "Brian" has created folder "/testshare"
@@ -419,7 +421,7 @@ Feature: dav-versions
| new | Brian | /testshare |
Scenario: Receiver tries to get file versions of unshared file from the sharer
Scenario: receiver tries to get file versions of unshared 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 "textfile1" to "textfile1.txt"
@@ -430,7 +432,7 @@ Feature: dav-versions
And the value of the item "//s:exception" in the response about user "Alice" should be "Sabre\DAV\Exception\NotFound"
@skipOnStorage:ceph
Scenario: Receiver tries get file versions of shared file from the sharer
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"
@@ -442,7 +444,7 @@ Feature: dav-versions
Then the HTTP status code should be "403"
Scenario: Receiver tries get file versions of shared file before receiving it
Scenario: receiver tries get file versions of shared file before receiving it
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"
tests/acceptance/features/coreApiWebdavDelete/deleteFolderContents.feature
+1 -1
View File
@@ -8,7 +8,7 @@ Feature: delete folder contents
Given user "Alice" has been created with default attributes and without skeleton files
Scenario Outline: Removing everything of a folder
Scenario Outline: removing everything from a folder
Given using <dav_version> DAV path
And user "Alice" has created folder "/PARENT/"
And user "Alice" has created folder "/FOLDER/"
tests/acceptance/features/coreApiWebdavEtagPropagation1/deleteFileFolder.feature
+7 -4
View File
@@ -1,5 +1,8 @@
@api
Feature: propagation of etags when deleting a file or folder
As a client app
I want metadata (etags) of parent folders to change when a file or folder is deleted
So that the client app can know to re-scan and sync the content of the folder(s)
Background:
Given user "Alice" has been created with default attributes and without skeleton files
@@ -82,7 +85,7 @@ Feature: propagation of etags when deleting a file or folder
| spaces |
Scenario Outline: as share receiver deleting a file changes the etags of all parents for all collaborators
Scenario Outline: sharee deleting a file changes the etags of all parents for all collaborators
Given user "Brian" has been created with default attributes and without skeleton files
And using <dav_version> DAV path
And user "Alice" has created folder "/upload/sub"
@@ -113,7 +116,7 @@ Feature: propagation of etags when deleting a file or folder
| new |
Scenario Outline: as sharer deleting a file changes the etags of all parents for all collaborators
Scenario Outline: sharer deleting a file changes the etags of all parents for all collaborators
Given user "Brian" has been created with default attributes and without skeleton files
And using <dav_version> DAV path
And user "Alice" has created folder "/upload/sub"
@@ -144,7 +147,7 @@ Feature: propagation of etags when deleting a file or folder
| new |
@issue-product-280
Scenario Outline: as share receiver deleting a folder changes the etags of all parents for all collaborators
Scenario Outline: sharee deleting a folder changes the etags of all parents for all collaborators
Given user "Brian" has been created with default attributes and without skeleton files
And using <dav_version> DAV path
And user "Alice" has created folder "/upload/sub"
@@ -175,7 +178,7 @@ Feature: propagation of etags when deleting a file or folder
| new |
@issue-product-280
Scenario Outline: as sharer deleting a folder changes the etags of all parents for all collaborators
Scenario Outline: sharer deleting a folder changes the etags of all parents for all collaborators
Given user "Brian" has been created with default attributes and without skeleton files
And using <dav_version> DAV path
And user "Alice" has created folder "/upload/sub"
tests/acceptance/features/coreApiWebdavEtagPropagation1/moveFileFolder.feature
+9 -6
View File
@@ -1,5 +1,8 @@
@api
Feature: propagation of etags when moving files or folders
As a client app
I want metadata (etags) of parent folder(s) to change when a file or folder is moved
So that the client app can know to re-scan and sync the content of the folder(s)
Background:
Given user "Alice" has been created with default attributes and without skeleton files
@@ -155,7 +158,7 @@ Feature: propagation of etags when moving files or folders
| spaces |
Scenario Outline: as share receiver renaming a file inside a folder changes its etag for all collaborators
Scenario Outline: sharee renaming a file inside a folder changes its etag for all collaborators
Given user "Brian" has been created with default attributes and without skeleton files
And using <dav_version> DAV path
And user "Alice" has created folder "/upload"
@@ -182,7 +185,7 @@ Feature: propagation of etags when moving files or folders
| new |
Scenario Outline: as sharer renaming a file inside a folder changes its etag for all collaborators
Scenario Outline: sharer renaming a file inside a folder changes its etag for all collaborators
Given user "Brian" has been created with default attributes and without skeleton files
And using <dav_version> DAV path
And user "Alice" has created folder "/upload"
@@ -209,7 +212,7 @@ Feature: propagation of etags when moving files or folders
| new |
@issue-product-280
Scenario Outline: as sharer moving a file from one folder to an other changes the etags of both folders for all collaborators
Scenario Outline: sharer moving a file from one folder to an other changes the etags of both folders for all collaborators
Given user "Brian" has been created with default attributes and without skeleton files
And using <dav_version> DAV path
And user "Alice" has created folder "/src"
@@ -243,7 +246,7 @@ Feature: propagation of etags when moving files or folders
| new |
Scenario Outline: as share receiver moving a file from one folder to an other changes the etags of both folders for all collaborators
Scenario Outline: sharee moving a file from one folder to an other changes the etags of both folders for all collaborators
Given user "Brian" has been created with default attributes and without skeleton files
And using <dav_version> DAV path
And user "Alice" has created folder "/src"
@@ -277,7 +280,7 @@ Feature: propagation of etags when moving files or folders
| new |
@issue-product-280
Scenario Outline: as sharer moving a folder from one folder to an other changes the etags of both folders for all collaborators
Scenario Outline: sharer moving a folder from one folder to an other changes the etags of both folders for all collaborators
Given user "Brian" has been created with default attributes and without skeleton files
And using <dav_version> DAV path
And user "Alice" has created folder "/src"
@@ -311,7 +314,7 @@ Feature: propagation of etags when moving files or folders
| new |
Scenario Outline: as share receiver moving a folder from one folder to an other changes the etags of both folders for all collaborators
Scenario Outline: sharee moving a folder from one folder to an other changes the etags of both folders for all collaborators
Given user "Brian" has been created with default attributes and without skeleton files
And using <dav_version> DAV path
And user "Alice" has created folder "/src"
tests/acceptance/features/coreApiWebdavEtagPropagation2/copyFileFolder.feature
+5 -2
View File
@@ -1,5 +1,8 @@
@api
Feature: propagation of etags when copying files or folders
As a client app
I want metadata (etags) of parent folders to change when a file of folder is copied
So that the client app can know to re-scan and sync the content of the folder(s)
Background:
Given user "Alice" has been created with default attributes and without skeleton files
@@ -152,7 +155,7 @@ Feature: propagation of etags when copying files or folders
| spaces |
Scenario Outline: as share receiver copying a file inside a folder changes its etag for all collaborators
Scenario Outline: sharee copying a file inside a folder changes its etag for all collaborators
Given user "Brian" has been created with default attributes and without skeleton files
And using <dav_version> DAV path
And user "Alice" has created folder "/upload"
@@ -189,7 +192,7 @@ Feature: propagation of etags when copying files or folders
| new |
@issue-product-280
Scenario Outline: as sharer copying a file inside a folder changes its etag for all collaborators
Scenario Outline: sharer copying a file inside a folder changes its etag for all collaborators
Given user "Brian" has been created with default attributes and without skeleton files
And using <dav_version> DAV path
And user "Alice" has created folder "/upload"
tests/acceptance/features/coreApiWebdavEtagPropagation2/createFolder.feature
+5 -2
View File
@@ -1,5 +1,8 @@
@api
Feature: propagation of etags when creating folders
As a client app
I want metadata (etags) of parent folders to change when a sub-folder is created
So that the client app can know to re-scan and sync the content of the folder(s)
Background:
Given user "Alice" has been created with default attributes and without skeleton files
@@ -52,7 +55,7 @@ Feature: propagation of etags when creating folders
| spaces |
@issue-product-280
Scenario Outline: as share receiver creating a folder inside a folder received as a share changes its etag for all collaborators
Scenario Outline: sharee creating a folder inside a folder received as a share changes its etag for all collaborators
Given user "Brian" has been created with default attributes and without skeleton files
And using <dav_version> DAV path
And user "Alice" has created folder "/folder"
@@ -78,7 +81,7 @@ Feature: propagation of etags when creating folders
| new |
@issue-product-280
Scenario Outline: as a sharer creating a folder inside a shared folder changes etag for all collaborators
Scenario Outline: sharer creating a folder inside a shared folder changes etag for all collaborators
Given user "Brian" has been created with default attributes and without skeleton files
And using <dav_version> DAV path
And user "Alice" has created folder "/folder"
tests/acceptance/features/coreApiWebdavEtagPropagation2/restoreFromTrash.feature
+3
View File
@@ -1,5 +1,8 @@
@api
Feature: propagation of etags when restoring a file or folder from trash
As a client app
I want metadata (etags) of parent folders to change when a file or folder is restored
So that the client app can know to re-scan and sync the content of the folder(s)
Background:
Given user "Alice" has been created with default attributes and without skeleton files
tests/acceptance/features/coreApiWebdavEtagPropagation2/restoreVersion.feature
+4 -1
View File
@@ -1,5 +1,8 @@
@api @issue-product-280
Feature: propagation of etags when restoring a version of a file
As a client app
I want metadata (etags) of parent folders to change when a file version is restored
So that the client app can know to re-scan and sync the content of the folder(s)
Background:
Given using OCS API version "2"
@@ -7,7 +10,7 @@ Feature: propagation of etags when restoring a version of a file
And user "Alice" has been created with default attributes and without skeleton files
@skipOnStorage:ceph @skipOnStorage:scality
Scenario: Restoring a file changes the etags of all parents
Scenario: restoring a file changes the etags of all parents
Given user "Alice" has created folder "/upload"
And user "Alice" has created folder "/upload/sub"
And user "Alice" has uploaded file with content "uploaded content" to "/upload/sub/file.txt"
tests/acceptance/features/coreApiWebdavEtagPropagation2/upload.feature
+7 -4
View File
@@ -1,5 +1,8 @@
@api
Feature: propagation of etags when uploading data
As a client app
I want metadata (etags) of parent folders to change when a file is uploaded
So that the client app can know to re-scan and sync the content of the folder(s)
Background:
Given user "Alice" has been created with default attributes and without skeleton files
@@ -51,7 +54,7 @@ Feature: propagation of etags when uploading data
| spaces |
@issue-product-280
Scenario Outline: as share receiver uploading a file inside a received shared folder should update etags for all collaborators
Scenario Outline: sharee uploading a file inside a received shared folder should update etags for all collaborators
Given user "Brian" has been created with default attributes and without skeleton files
And using <dav_version> DAV path
And user "Alice" has shared folder "/upload" with user "Brian"
@@ -76,7 +79,7 @@ Feature: propagation of etags when uploading data
| new |
@issue-product-280
Scenario Outline: as sharer uploading a file inside a shared folder should update etags for all collaborators
Scenario Outline: sharer uploading a file inside a shared folder should update etags for all collaborators
Given user "Brian" has been created with default attributes and without skeleton files
And using <dav_version> DAV path
And user "Alice" has shared folder "/upload" with user "Brian"
@@ -101,7 +104,7 @@ Feature: propagation of etags when uploading data
| new |
Scenario Outline: as share receiver overwriting a file inside a received shared folder should update etags for all collaborators
Scenario Outline: sharee overwriting a file inside a received shared folder should update etags for all collaborators
Given user "Brian" has been created with default attributes and without skeleton files
And using <dav_version> DAV path
And user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt"
@@ -127,7 +130,7 @@ Feature: propagation of etags when uploading data
| new |
Scenario Outline: as sharer overwriting a file inside a shared folder should update etags for all collaborators
Scenario Outline: sharer overwriting a file inside a shared folder should update etags for all collaborators
Given user "Brian" has been created with default attributes and without skeleton files
And using <dav_version> DAV path
And user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt"
tests/acceptance/features/coreApiWebdavLocks/exclusiveLocks.feature
+7 -4
View File
@@ -1,11 +1,14 @@
@api @issue-1284
Feature: there can be only one exclusive lock on a resource
As a user
I want to lock a resource
So that other users cannot access or change that resource
Background:
Given user "Alice" has been created with default attributes and without skeleton files
Scenario Outline: a second lock cannot be set on a folder when its exclusively locked
Scenario Outline: second lock cannot be set on a folder when its exclusively locked
Given using <dav-path> DAV path
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
And user "Alice" has locked file "textfile0.txt" setting the following properties
@@ -28,7 +31,7 @@ Feature: there can be only one exclusive lock on a resource
| spaces | exclusive |
Scenario Outline: a share receiver cannot lock a resource exclusively locked by itself
Scenario Outline: sharee cannot lock a resource exclusively locked by itself
Given using <dav-path> 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 "textfile0.txt"
@@ -55,7 +58,7 @@ Feature: there can be only one exclusive lock on a resource
| spaces | exclusive |
Scenario Outline: a share receiver cannot lock a resource exclusively locked by the owner
Scenario Outline: sharee cannot lock a resource exclusively locked by the owner
Given using <dav-path> 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 "textfile0.txt"
@@ -82,7 +85,7 @@ Feature: there can be only one exclusive lock on a resource
| spaces | exclusive |
Scenario Outline: a share owner cannot lock a resource exclusively locked by a share receiver
Scenario Outline: sharer cannot lock a resource exclusively locked by a sharee
Given using <dav-path> 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 "textfile0.txt"
tests/acceptance/features/coreApiWebdavLocks/requestsWithToken.feature
+3
View File
@@ -1,5 +1,8 @@
@api @issue-1284
Feature: actions on a locked item are possible if the token is sent with the request
As a user
I want to share the lock token of a resource
So that the users or apps can access the resource that I have locked
Background:
Given user "Alice" has been created with default attributes and without skeleton files
tests/acceptance/features/coreApiWebdavLocks2/independentLocks.feature
+4 -2
View File
@@ -1,6 +1,8 @@
@api @issue-1284
Feature: independent locks
Make sure all locks are independent and don't interact with other items that have the same name
Feature: independent locks - make sure all locks are independent and don't interact with other items that have the same name
As a user
I want to lock resources independently
So that resources with same name in other parts of the file system will not be locked
Background:
Given user "Alice" has been created with default attributes and without skeleton files
tests/acceptance/features/coreApiWebdavLocks2/independentLocksShareToShares.feature
+4 -2
View File
@@ -1,6 +1,8 @@
@api @issue-1284
Feature: independent locks
Make sure all locks are independent and don't interact with other items that have the same name
Feature: independent locks - make sure all locks are independent and don't interact with other items that have the same name
As a user
I want to independently lock resources shared with me
So that resources with same name in other received shares will not be locked
Background:
Given user "Alice" has been created with default attributes and without skeleton files
tests/acceptance/features/coreApiWebdavLocksUnlock/unlock.feature
+5 -2
View File
@@ -1,5 +1,8 @@
@api @issue-1284
Feature: UNLOCK locked items
Feature: Unlock locked items
As a user
I want to unlock the resources previously locked by myself
So that other users can make changes to the resources
Background:
Given user "Alice" has been created with default attributes and without skeleton files
@@ -26,7 +29,7 @@ Feature: UNLOCK locked items
| spaces |
Scenario Outline: as public unlocking a file in a share that was locked by the file owner is not possible. To unlock use the owners locktoken
Scenario Outline: public unlocking a file in a share that was locked by the file owner is not possible. To unlock use the owners locktoken
Given user "Alice" has created folder "PARENT"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt"
And user "Alice" has created a public link share of folder "PARENT" with change permission
tests/acceptance/features/coreApiWebdavLocksUnlock/unlockSharingToShares.feature
+7 -4
View File
@@ -1,5 +1,8 @@
@api @issue-1284
Feature: UNLOCK locked items (sharing)
As a user
I want to unlock a shared resource that has been locked by me to be restricted
So that other users cannot unlock the shared resource
Background:
Given these users have been created with default attributes and without skeleton files:
@@ -10,7 +13,7 @@ Feature: UNLOCK locked items (sharing)
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt"
Scenario Outline: as share receiver unlocking a shared file locked by the file owner is not possible. To unlock use the owners locktoken
Scenario Outline: unlocking a shared file that has been locked by the file owner is not feasible unless the owner lock tocken is used
Given using <dav-path> DAV path
And user "Alice" has locked file "PARENT/parent.txt" setting the following properties
| lockscope | <lock-scope> |
@@ -34,7 +37,7 @@ Feature: UNLOCK locked items (sharing)
| spaces | exclusive | /parent.txt |
Scenario Outline: as share receiver unlocking a file in a share locked by the file owner is not possible. To unlock use the owners locktoken
Scenario Outline: sharee cannot unlock a file within a shared folder when it is locked by the file owner unless the owner lock token is used
Given using <dav-path> DAV path
And user "Alice" has locked file "PARENT/parent.txt" setting the following properties
| lockscope | <lock-scope> |
@@ -58,7 +61,7 @@ Feature: UNLOCK locked items (sharing)
| spaces | exclusive |
Scenario Outline: as share receiver unlock a shared file
Scenario Outline: sharee unlock a shared file
Given using <dav-path> DAV path
And user "Alice" has shared file "PARENT/parent.txt" with user "Brian"
And user "Brian" has accepted share "<pending_share_path>" offered by user "Alice"
@@ -106,7 +109,7 @@ Feature: UNLOCK locked items (sharing)
| spaces | exclusive | /parent.txt |
Scenario Outline: as owner unlocking a file in a share that was locked by the share receiver is not possible. To unlock use the receivers locktoken
Scenario Outline: unlocking a file in a shared folder, which was locked by the sharee is not possible for the owner unless the receiver's locktoken is used
Given using <dav-path> DAV path
And user "Alice" has shared folder "PARENT" with user "Brian"
And user "Brian" has accepted share "/PARENT" offered by user "Alice"