Initial QSfera import
This commit is contained in:
Курнат Андрей
@@ -0,0 +1,72 @@
|
||||
Feature: change shared resource
|
||||
As a user
|
||||
I want to change the shared resource
|
||||
So that I can organize them as per my necessity
|
||||
|
||||
Background:
|
||||
Given using spaces DAV path
|
||||
And these users have been created with default attributes:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
|
||||
@issue-4421
|
||||
Scenario: move files between shares by different users
|
||||
Given user "Carol" has been created with default attributes
|
||||
And user "Alice" has uploaded file with content "some data" to "/textfile0.txt"
|
||||
And user "Alice" has created folder "/PARENT"
|
||||
And user "Brian" has created folder "/PARENT"
|
||||
And user "Alice" has moved file "textfile0.txt" to "PARENT/from_alice.txt" in space "Personal"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | PARENT |
|
||||
| space | Personal |
|
||||
| sharee | Carol |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Carol" has a share "PARENT" synced
|
||||
And user "Brian" has sent the following resource share invitation:
|
||||
| resource | PARENT |
|
||||
| space | Personal |
|
||||
| sharee | Carol |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Carol" has a share "PARENT (1)" synced
|
||||
When user "Carol" moves file "PARENT/from_alice.txt" to "PARENT (1)/from_alice.txt" in space "Shares" using the WebDAV API
|
||||
Then the HTTP status code should be "502"
|
||||
And for user "Carol" folder "PARENT" of the space "Shares" should contain these entries:
|
||||
| from_alice.txt |
|
||||
And for user "Carol" folder "PARENT (1)" of the space "Shares" should not contain these entries:
|
||||
| from_alice.txt |
|
||||
|
||||
|
||||
Scenario Outline: overwrite a received file share
|
||||
Given the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
|
||||
And user "Alice" has uploaded file with content "old content version 1" to "/textfile1.txt"
|
||||
And user "Alice" has uploaded file with content "old content version 2" to "/textfile1.txt"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | textfile1.txt |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | File Editor |
|
||||
And user "Brian" has a share "textfile1.txt" synced
|
||||
When user "Brian" uploads a file inside space "Shares" with content "this is a new content" to "textfile1.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "204"
|
||||
And for user "Brian" the space "Shares" should contain these entries:
|
||||
| textfile1.txt |
|
||||
And for user "Brian" the content of the file "/textfile1.txt" of the space "Shares" should be "this is a new content"
|
||||
And for user "Alice" the content of the file "/textfile1.txt" of the space "Personal" should be "this is a new content"
|
||||
When user "Alice" downloads version of the file "/textfile1.txt" with the index "2" of the space "Personal" using the WebDAV API
|
||||
Then the HTTP status code should be "200"
|
||||
And the downloaded content should be "old content version 1"
|
||||
When user "Alice" downloads version of the file "/textfile1.txt" with the index "1" of the space "Personal" using the WebDAV API
|
||||
Then the HTTP status code should be "200"
|
||||
And the downloaded content should be "old content version 2"
|
||||
When user "Brian" tries to get versions of the file "/textfile1.txt" from the space "Shares" using the WebDAV API
|
||||
Then the HTTP status code should be "403"
|
||||
Examples:
|
||||
| user-role |
|
||||
| Admin |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
@@ -0,0 +1,37 @@
|
||||
Feature: checksums
|
||||
As a user
|
||||
I want to upload files with checksum
|
||||
So that I can make sure that the files are uploaded with correct checksums
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes
|
||||
And using spaces DAV path
|
||||
And user "Brian" has been created with default attributes
|
||||
|
||||
@issue-1291
|
||||
Scenario: sharing a file with checksum should return the checksum in the propfind using new DAV path
|
||||
Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | myChecksumFile.txt |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Viewer |
|
||||
And user "Brian" has a share "myChecksumFile.txt" synced
|
||||
When user "Brian" requests the checksum of file "/myChecksumFile.txt" in space "Shares" via propfind using the WebDAV API
|
||||
Then the HTTP status code should be "207"
|
||||
And the webdav checksum should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960"
|
||||
|
||||
@issue-1291
|
||||
Scenario: modifying a shared file should return correct checksum in the propfind using new DAV path
|
||||
Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | myChecksumFile.txt |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | File Editor |
|
||||
And user "Brian" has a share "myChecksumFile.txt" synced
|
||||
When user "Brian" uploads file with checksum "SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399" and content "Some Text" to "/myChecksumFile.txt" in space "Shares" 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 "SHA1:ce5582148c6f0c1282335b87df5ed4be4b781399 MD5:56e57920c3c8c727bfe7a5288cdf61c4 ADLER32:1048035a"
|
||||
File diff suppressed because it is too large
Load Diff
+63
@@ -0,0 +1,63 @@
|
||||
Feature: create file or folder named similar to Shares folder
|
||||
As a user
|
||||
I want to be able to create files and folders when the Shares folder exists
|
||||
So that I can organise the files in my file system
|
||||
|
||||
Background:
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
And user "Alice" has created folder "/FOLDER"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | FOLDER |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Viewer |
|
||||
And user "Brian" has a share "FOLDER" synced
|
||||
|
||||
|
||||
Scenario Outline: create a folder with a name similar to Shares
|
||||
Given using spaces DAV path
|
||||
When user "Brian" creates folder "<folder-name>" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And for user "Brian" the space "Personal" should contain these entries:
|
||||
| <folder-name>/ |
|
||||
Examples:
|
||||
| folder-name |
|
||||
| Share |
|
||||
| shares |
|
||||
| Share1 |
|
||||
|
||||
|
||||
Scenario Outline: create a file with a name similar to Shares
|
||||
Given using spaces DAV path
|
||||
When user "Brian" uploads file with content "some text" to "<file-name>" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And the content of file "<file-name>" for user "Brian" should be "some text"
|
||||
And for user "Brian" the space "Personal" should contain these entries:
|
||||
| <file-name> |
|
||||
And for user "Brian" the space "Shares" should contain these entries:
|
||||
| FOLDER/ |
|
||||
Examples:
|
||||
| file-name |
|
||||
| Share |
|
||||
| shares |
|
||||
| Share1 |
|
||||
|
||||
|
||||
Scenario: try to create a folder named Shares
|
||||
Given using spaces DAV path
|
||||
When user "Brian" creates folder "/Shares" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And for user "Brian" the space "Shares" should contain these entries:
|
||||
| FOLDER/ |
|
||||
|
||||
|
||||
Scenario: try to create a file named Shares
|
||||
Given using spaces DAV path
|
||||
When user "Brian" uploads file with content "some text" to "/Shares" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And for user "Brian" the space "Shares" should contain these entries:
|
||||
| FOLDER/ |
|
||||
@@ -0,0 +1,469 @@
|
||||
Feature: check etag propagation after different file alterations
|
||||
As a user
|
||||
I want to check the etag
|
||||
So that I can make sure that they are correct after different file alterations
|
||||
|
||||
Background:
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
And using spaces DAV path
|
||||
And user "Alice" has created folder "/upload"
|
||||
|
||||
|
||||
Scenario: copying a file inside a folder as a share receiver changes its etag for all collaborators
|
||||
Given user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | upload |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "upload" synced
|
||||
And user "Alice" has stored etag of element "/" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload/file.txt" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload/file.txt" on path "/upload/renamed.txt" inside space "Personal"
|
||||
And user "Brian" has stored etag of element "/" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload/file.txt" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "upload/file.txt" on path "/upload/renamed.txt" inside space "Shares"
|
||||
When user "Brian" copies file "/upload/file.txt" to "/upload/renamed.txt" inside space "Shares" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And these etags should have changed
|
||||
| user | path | space |
|
||||
| Alice | / | Personal |
|
||||
| Alice | /upload | Personal |
|
||||
| Alice | /upload/renamed.txt | Personal |
|
||||
| Brian | / | Shares |
|
||||
| Brian | /upload | Shares |
|
||||
| Brian | /upload/renamed.txt | Shares |
|
||||
And these etags should not have changed
|
||||
| user | path | space |
|
||||
| Alice | /upload/file.txt | Personal |
|
||||
| Brian | /upload/file.txt | Shares |
|
||||
|
||||
|
||||
Scenario: copying a file inside a folder as a sharer changes its etag for all collaborators
|
||||
Given user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | upload |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "upload" synced
|
||||
And user "Alice" has stored etag of element "/" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload/file.txt" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload/file.txt" on path "/upload/renamed.txt" inside space "Personal"
|
||||
And user "Brian" has stored etag of element "/" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload/file.txt" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload/file.txt" on path "/upload/renamed.txt" inside space "Shares"
|
||||
When user "Alice" copies file "/upload/file.txt" to "/upload/renamed.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And these etags should have changed
|
||||
| user | path | space |
|
||||
| Alice | / | Personal |
|
||||
| Alice | /upload | Personal |
|
||||
| Alice | /upload/renamed.txt | Personal |
|
||||
| Brian | / | Shares |
|
||||
| Brian | /upload | Shares |
|
||||
| Brian | /upload/renamed.txt | Shares |
|
||||
And these etags should not have changed
|
||||
| user | path | space |
|
||||
| Alice | /upload/file.txt | Personal |
|
||||
| Brian | /upload/file.txt | Shares |
|
||||
|
||||
|
||||
Scenario: share receiver renaming a file inside a folder changes its etag for all collaborators
|
||||
Given user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | upload |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "upload" synced
|
||||
And user "Alice" has stored etag of element "/" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload/file.txt" on path "/upload/renamed.txt" inside space "Personal"
|
||||
And user "Brian" has stored etag of element "/" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload/file.txt" on path "/upload/renamed.txt" inside space "Shares"
|
||||
When user "Brian" moves file "/upload/file.txt" to "/upload/renamed.txt" in space "Shares" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And these etags should have changed
|
||||
| user | path | space |
|
||||
| Alice | / | Personal |
|
||||
| Alice | /upload | Personal |
|
||||
| Brian | / | Shares |
|
||||
| Brian | /upload | Shares |
|
||||
And these etags should not have changed
|
||||
| user | path | space |
|
||||
| Alice | /upload/renamed.txt | Personal |
|
||||
| Brian | /upload/renamed.txt | Shares |
|
||||
|
||||
|
||||
Scenario: sharer renaming a file inside a folder changes its etag for all collaborators
|
||||
Given user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | upload |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "upload" synced
|
||||
And user "Alice" has stored etag of element "/" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload/file.txt" on path "/upload/renamed.txt" inside space "Personal"
|
||||
And user "Brian" has stored etag of element "/" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload/file.txt" on path "/upload/renamed.txt" inside space "Shares"
|
||||
When user "Alice" moves file "/upload/file.txt" to "/upload/renamed.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And these etags should have changed
|
||||
| user | path | space |
|
||||
| Alice | / | Personal |
|
||||
| Alice | /upload | Personal |
|
||||
| Brian | / | Shares |
|
||||
| Brian | /upload | Shares |
|
||||
And these etags should not have changed
|
||||
| user | path | space |
|
||||
| Alice | /upload/renamed.txt | Personal |
|
||||
| Brian | /upload/renamed.txt | Shares |
|
||||
|
||||
|
||||
Scenario: sharer moving a file from one folder to an other changes the etags of both folders for all collaborators
|
||||
Given user "Alice" has created folder "/dst"
|
||||
And user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | upload |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "upload" synced
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | dst |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "dst" synced
|
||||
And user "Alice" has stored etag of element "/" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/dst" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload/file.txt" on path "/dst/file.txt" inside space "Personal"
|
||||
And user "Brian" has stored etag of element "/" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/dst" inside space "Shares"
|
||||
When user "Alice" moves file "/upload/file.txt" to "/dst/file.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And these etags should have changed
|
||||
| user | path | space |
|
||||
| Alice | / | Personal |
|
||||
| Alice | /upload | Personal |
|
||||
| Alice | /dst | Personal |
|
||||
| Brian | / | Shares |
|
||||
| Brian | /upload | Shares |
|
||||
| Brian | /dst | Shares |
|
||||
|
||||
|
||||
Scenario: sharer moving a folder from one folder to an other changes the etags of both folders for all collaborators
|
||||
Given user "Alice" has created folder "/dst"
|
||||
And user "Alice" has created folder "/upload/toMove"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | upload |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "upload" synced
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | dst |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "dst" synced
|
||||
And user "Alice" has stored etag of element "/" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/dst" inside space "Personal"
|
||||
And user "Brian" has stored etag of element "/" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/dst" inside space "Shares"
|
||||
When user "Alice" moves file "/upload/toMove" to "/dst/toMove" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And these etags should have changed
|
||||
| user | path | space |
|
||||
| Alice | / | Personal |
|
||||
| Alice | /upload | Personal |
|
||||
| Alice | /dst | Personal |
|
||||
| Brian | / | Shares |
|
||||
| Brian | /upload | Shares |
|
||||
| Brian | /dst | Shares |
|
||||
|
||||
|
||||
Scenario: share receiver creating a folder inside a folder received as a share changes its etag for all collaborators
|
||||
Given user "Alice" has sent the following resource share invitation:
|
||||
| resource | upload |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "upload" synced
|
||||
And user "Alice" has stored etag of element "/" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload" inside space "Personal"
|
||||
And user "Brian" has stored etag of element "/" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload" inside space "Shares"
|
||||
When user "Brian" creates a subfolder "/upload/new" in space "Shares" using the WebDav Api
|
||||
Then the HTTP status code should be "201"
|
||||
And these etags should have changed
|
||||
| user | path | space |
|
||||
| Alice | / | Personal |
|
||||
| Alice | /upload | Personal |
|
||||
| Brian | / | Shares |
|
||||
| Brian | /upload | Shares |
|
||||
|
||||
|
||||
Scenario: sharer creating a folder inside a shared folder changes etag for all collaborators
|
||||
Given user "Alice" has sent the following resource share invitation:
|
||||
| resource | upload |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "upload" synced
|
||||
And user "Alice" has stored etag of element "/" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload" inside space "Personal"
|
||||
And user "Brian" has stored etag of element "/" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload" inside space "Shares"
|
||||
When user "Alice" creates folder "/upload/new" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And these etags should have changed
|
||||
| user | path | space |
|
||||
| Alice | / | Personal |
|
||||
| Alice | /upload | Personal |
|
||||
| Brian | / | Shares |
|
||||
| Brian | /upload | Shares |
|
||||
|
||||
|
||||
Scenario: share receiver uploading a file inside a folder received as a share changes its etag for all collaborators
|
||||
Given user "Alice" has sent the following resource share invitation:
|
||||
| resource | upload |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "upload" synced
|
||||
And user "Alice" has stored etag of element "/" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload" inside space "Personal"
|
||||
And user "Brian" has stored etag of element "/" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload" inside space "Shares"
|
||||
When user "Brian" uploads a file inside space "Shares" with content "uploaded content" to "/upload/file.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And these etags should have changed
|
||||
| user | path | space |
|
||||
| Alice | / | Personal |
|
||||
| Alice | /upload | Personal |
|
||||
| Brian | / | Shares |
|
||||
| Brian | /upload | Shares |
|
||||
|
||||
|
||||
Scenario: sharer uploading a file inside a shared folder should update etags for all collaborators
|
||||
Given user "Alice" has sent the following resource share invitation:
|
||||
| resource | upload |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "upload" synced
|
||||
And user "Alice" has stored etag of element "/" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload" inside space "Personal"
|
||||
And user "Brian" has stored etag of element "/" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload" inside space "Shares"
|
||||
When user "Alice" uploads file with content "uploaded content" to "/upload/file.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And these etags should have changed
|
||||
| user | path | space |
|
||||
| Alice | / | Personal |
|
||||
| Alice | /upload | Personal |
|
||||
| Brian | / | Shares |
|
||||
| Brian | /upload | Shares |
|
||||
|
||||
|
||||
Scenario: share receiver overwriting a file inside a received shared folder should update etags for all collaborators
|
||||
Given user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | upload |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "upload" synced
|
||||
And user "Alice" has stored etag of element "/" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload" inside space "Personal"
|
||||
And user "Brian" has stored etag of element "/" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload" inside space "Shares"
|
||||
When user "Brian" uploads a file inside space "Shares" with content "new content" to "/upload/file.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "204"
|
||||
And these etags should have changed
|
||||
| user | path | space |
|
||||
| Alice | / | Personal |
|
||||
| Alice | /upload | Personal |
|
||||
| Brian | / | Shares |
|
||||
| Brian | /upload | Shares |
|
||||
|
||||
|
||||
Scenario: sharer overwriting a file inside a shared folder should update etags for all collaborators
|
||||
Given user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | upload |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "upload" synced
|
||||
And user "Alice" has stored etag of element "/" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload" inside space "Personal"
|
||||
And user "Brian" has stored etag of element "/" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload" inside space "Shares"
|
||||
When user "Alice" uploads file with content "new content" to "/upload/file.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "204"
|
||||
And these etags should have changed
|
||||
| user | path | space |
|
||||
| Alice | / | Personal |
|
||||
| Alice | /upload | Personal |
|
||||
| Brian | / | Shares |
|
||||
| Brian | /upload | Shares |
|
||||
|
||||
|
||||
Scenario: share receiver deleting (removing) a file changes the etags of all parents for all collaborators
|
||||
Given user "Alice" has created folder "/upload/sub"
|
||||
And user "Alice" has uploaded file with content "uploaded content" to "/upload/sub/file.txt"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | upload |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "upload" synced
|
||||
And user "Alice" has stored etag of element "/" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload/sub" inside space "Personal"
|
||||
And user "Brian" has stored etag of element "/" inside space "Personal"
|
||||
And user "Brian" has stored etag of element "/" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload/sub" inside space "Shares"
|
||||
When user "Brian" removes the file "upload/sub/file.txt" from space "Shares"
|
||||
Then the HTTP status code should be "204"
|
||||
And these etags should have changed
|
||||
| user | path | space |
|
||||
| Alice | / | Personal |
|
||||
| Alice | /upload | Personal |
|
||||
| Alice | /upload/sub | Personal |
|
||||
| Brian | / | Shares |
|
||||
| Brian | /upload | Shares |
|
||||
| Brian | /upload/sub | Shares |
|
||||
And these etags should not have changed
|
||||
| user | path | space |
|
||||
| Brian | / | Personal |
|
||||
|
||||
|
||||
Scenario: sharer deleting (removing) a file changes the etags of all parents for all collaborators
|
||||
Given user "Alice" has created folder "/upload/sub"
|
||||
And user "Alice" has uploaded file with content "uploaded content" to "/upload/sub/file.txt"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | upload |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "upload" synced
|
||||
And user "Alice" has stored etag of element "/" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload/sub" inside space "Personal"
|
||||
And user "Brian" has stored etag of element "/" inside space "Personal"
|
||||
And user "Brian" has stored etag of element "/" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload/sub" inside space "Shares"
|
||||
When user "Alice" removes the file "upload/sub/file.txt" from space "Personal"
|
||||
Then the HTTP status code should be "204"
|
||||
And these etags should have changed
|
||||
| user | path | space |
|
||||
| Alice | / | Personal |
|
||||
| Alice | /upload | Personal |
|
||||
| Alice | /upload/sub | Personal |
|
||||
| Brian | / | Shares |
|
||||
| Brian | /upload | Shares |
|
||||
| Brian | /upload/sub | Shares |
|
||||
And these etags should not have changed
|
||||
| user | path | space |
|
||||
| Brian | / | Personal |
|
||||
|
||||
|
||||
Scenario: share receiver deleting (removing) a folder changes the etags of all parents for all collaborators
|
||||
Given user "Alice" has created folder "/upload/sub"
|
||||
And user "Alice" has created folder "/upload/sub/toDelete"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | upload |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "upload" synced
|
||||
And user "Alice" has stored etag of element "/" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload/sub" inside space "Personal"
|
||||
And user "Brian" has stored etag of element "/" inside space "Personal"
|
||||
And user "Brian" has stored etag of element "/" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload/sub" inside space "Shares"
|
||||
When user "Brian" removes the file "upload/sub/toDelete" from space "Shares"
|
||||
Then the HTTP status code should be "204"
|
||||
And these etags should have changed
|
||||
| user | path | space |
|
||||
| Alice | / | Personal |
|
||||
| Alice | /upload | Personal |
|
||||
| Alice | /upload/sub | Personal |
|
||||
| Brian | / | Shares |
|
||||
| Brian | /upload | Shares |
|
||||
| Brian | /upload/sub | Shares |
|
||||
And these etags should not have changed
|
||||
| user | path | space |
|
||||
| Brian | / | Personal |
|
||||
|
||||
|
||||
Scenario: sharer deleting (removing) a folder changes the etags of all parents for all collaborators
|
||||
Given user "Alice" has created folder "/upload/sub"
|
||||
And user "Alice" has created folder "/upload/sub/toDelete"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | upload |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "upload" synced
|
||||
And user "Alice" has stored etag of element "/" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload" inside space "Personal"
|
||||
And user "Alice" has stored etag of element "/upload/sub" inside space "Personal"
|
||||
And user "Brian" has stored etag of element "/" inside space "Personal"
|
||||
And user "Brian" has stored etag of element "/" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload" inside space "Shares"
|
||||
And user "Brian" has stored etag of element "/upload/sub" inside space "Shares"
|
||||
When user "Alice" removes the file "upload/sub/toDelete" from space "Personal"
|
||||
Then the HTTP status code should be "204"
|
||||
And these etags should have changed
|
||||
| user | path | space |
|
||||
| Alice | / | Personal |
|
||||
| Alice | /upload | Personal |
|
||||
| Alice | /upload/sub | Personal |
|
||||
| Brian | / | Shares |
|
||||
| Brian | /upload | Shares |
|
||||
| Brian | /upload/sub | Shares |
|
||||
And these etags should not have changed
|
||||
| user | path | space |
|
||||
| Brian | / | Personal |
|
||||
@@ -0,0 +1,440 @@
|
||||
Feature: move (rename) file
|
||||
As a user
|
||||
I want to be able to move and rename files
|
||||
So that I can manage my file system
|
||||
|
||||
Background:
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
And using spaces DAV path
|
||||
|
||||
|
||||
Scenario Outline: moving a file within same space project with role Manager and editor
|
||||
Given the administrator has assigned the role "Space Admin" to user "Brian" using the Graph API
|
||||
And user "Brian" has created a space "Project" with the default quota using the Graph API
|
||||
And user "Brian" has created a folder "newfolder" in space "Project"
|
||||
And user "Brian" has uploaded a file inside space "Project" with content "some content" to "insideSpace.txt"
|
||||
And user "Brian" has sent the following space share invitation:
|
||||
| space | Project |
|
||||
| sharee | Alice |
|
||||
| shareType | user |
|
||||
| permissionsRole | <space-role> |
|
||||
When user "Alice" moves file "insideSpace.txt" to "newfolder/insideSpace.txt" in space "Project" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And for user "Alice" folder "newfolder" of the space "Project" should contain these entries:
|
||||
| insideSpace.txt |
|
||||
But for user "Alice" the space "Project" should not contain these entries:
|
||||
| insideSpace.txt |
|
||||
Examples:
|
||||
| space-role |
|
||||
| Manager |
|
||||
| Space Editor |
|
||||
|
||||
|
||||
Scenario: moving a file within same space project with role viewer
|
||||
Given the administrator has assigned the role "Space Admin" to user "Brian" using the Graph API
|
||||
And user "Brian" has created a space "Project" with the default quota using the Graph API
|
||||
And user "Brian" has created a folder "newfolder" in space "Project"
|
||||
And user "Brian" has uploaded a file inside space "Project" with content "some content" to "insideSpace.txt"
|
||||
And user "Brian" has sent the following space share invitation:
|
||||
| space | Project |
|
||||
| sharee | Alice |
|
||||
| shareType | user |
|
||||
| permissionsRole | Space Viewer |
|
||||
When user "Alice" moves file "insideSpace.txt" to "newfolder/insideSpace.txt" in space "Project" using the WebDAV API
|
||||
Then the HTTP status code should be "403"
|
||||
And for user "Alice" folder "newfolder" of the space "Project" should not contain these entries:
|
||||
| insideSpace.txt |
|
||||
But for user "Alice" the space "Project" should contain these entries:
|
||||
| insideSpace.txt |
|
||||
|
||||
@issue-1976
|
||||
Scenario Outline: try to move a file within a project space into a folder with same name
|
||||
Given the administrator has assigned the role "Space Admin" to user "Brian" using the Graph API
|
||||
And user "Brian" has created a space "Project" with the default quota using the Graph API
|
||||
And user "Brian" has uploaded a file inside space "Project" with content "some content" to "insideSpace.txt"
|
||||
And user "Brian" has sent the following space share invitation:
|
||||
| space | Project |
|
||||
| sharee | Alice |
|
||||
| shareType | user |
|
||||
| permissionsRole | <space-role> |
|
||||
When user "Alice" moves file "insideSpace.txt" from space "Project" to "insideSpace.txt" inside space "Project" using the WebDAV API
|
||||
Then the HTTP status code should be "403"
|
||||
And as "Brian" file "insideSpace.txt" should not exist in the trashbin of the space "Project"
|
||||
And for user "Alice" the content of the file "insideSpace.txt" of the space "Project" should be "some content"
|
||||
Examples:
|
||||
| space-role |
|
||||
| Manager |
|
||||
| Space Editor |
|
||||
| Space Viewer |
|
||||
|
||||
@issue-8116
|
||||
Scenario Outline: user moves a file from a space project with different a role to a space project with different role
|
||||
Given the administrator has assigned the role "Space Admin" to user "Brian" using the Graph API
|
||||
And user "Brian" has created a space "Project1" with the default quota using the Graph API
|
||||
And user "Brian" has created a space "Project2" with the default quota using the Graph API
|
||||
And user "Brian" has uploaded a file inside space "Project1" with content "Project1 content" to "project1.txt"
|
||||
And user "Brian" has sent the following space share invitation:
|
||||
| space | Project1 |
|
||||
| sharee | Alice |
|
||||
| shareType | user |
|
||||
| permissionsRole | <to-space-role> |
|
||||
And user "Brian" has sent the following space share invitation:
|
||||
| space | Project2 |
|
||||
| sharee | Alice |
|
||||
| shareType | user |
|
||||
| permissionsRole | <from-space-role> |
|
||||
When user "Alice" moves file "project1.txt" from space "Project1" to "project1.txt" inside space "Project2" using the WebDAV API
|
||||
Then the HTTP status code should be "<http-status-code>"
|
||||
And for user "Alice" the space "Project1" should contain these entries:
|
||||
| project1.txt |
|
||||
And for user "Alice" the space "Project2" should not contain these entries:
|
||||
| project1.txt |
|
||||
Examples:
|
||||
| from-space-role | to-space-role | http-status-code |
|
||||
| Manager | Manager | 502 |
|
||||
| Space Editor | Manager | 502 |
|
||||
| Manager | Space Editor | 502 |
|
||||
| Space Editor | Space Editor | 502 |
|
||||
| Manager | Space Viewer | 403 |
|
||||
| Space Editor | Space Viewer | 403 |
|
||||
| Space Viewer | Manager | 403 |
|
||||
| Space Viewer | Space Editor | 403 |
|
||||
| Space Viewer | Space Viewer | 403 |
|
||||
|
||||
@issue-7618
|
||||
Scenario Outline: user moves a file from a space project with different role to a space personal
|
||||
Given the administrator has assigned the role "Space Admin" to user "Brian" using the Graph API
|
||||
And user "Brian" has created a space "Project" with the default quota using the Graph API
|
||||
And user "Brian" has uploaded a file inside space "Project" with content "Project content" to "project.txt"
|
||||
And user "Brian" has sent the following space share invitation:
|
||||
| space | Project |
|
||||
| sharee | Alice |
|
||||
| shareType | user |
|
||||
| permissionsRole | <space-role> |
|
||||
When user "Alice" moves file "project.txt" from space "Project" to "project.txt" inside space "Personal" using the WebDAV API
|
||||
Then the HTTP status code should be "<http-status-code>"
|
||||
And for user "Alice" the space "Project" should contain these entries:
|
||||
| project.txt |
|
||||
And for user "Alice" the space "Personal" should not contain these entries:
|
||||
| project.txt |
|
||||
Examples:
|
||||
| space-role | http-status-code |
|
||||
| Manager | 502 |
|
||||
| Space Editor | 502 |
|
||||
| Space Viewer | 403 |
|
||||
|
||||
|
||||
Scenario Outline: user moves a file from space project with different role to space Shares with different role (permission)
|
||||
Given the administrator has assigned the role "Space Admin" to user "Brian" using the Graph API
|
||||
And user "Brian" has created a space "Project" with the default quota using the Graph API
|
||||
And user "Brian" has created folder "/testshare"
|
||||
And user "Brian" has uploaded a file inside space "Project" with content "Project content" to "project.txt"
|
||||
And user "Brian" has sent the following space share invitation:
|
||||
| space | Project |
|
||||
| sharee | Alice |
|
||||
| shareType | user |
|
||||
| permissionsRole | <space-role> |
|
||||
And user "Brian" has sent the following resource share invitation:
|
||||
| resource | testshare |
|
||||
| space | Personal |
|
||||
| sharee | Alice |
|
||||
| shareType | user |
|
||||
| permissionsRole | <permissions-role> |
|
||||
And user "Alice" has a share "testshare" synced
|
||||
When user "Alice" moves file "project.txt" from space "Project" to "/testshare/project.txt" inside space "Shares" using the WebDAV API
|
||||
Then the HTTP status code should be "502"
|
||||
And for user "Alice" the space "Project" should contain these entries:
|
||||
| project.txt |
|
||||
But for user "Alice" folder "testshare" of the space "Shares" should not contain these entries:
|
||||
| project.txt |
|
||||
Examples:
|
||||
| space-role | permissions-role |
|
||||
| Manager | Editor |
|
||||
| Space Editor | Editor |
|
||||
| Space Viewer | Editor |
|
||||
| Manager | Uploader |
|
||||
| Space Editor | Uploader |
|
||||
| Space Viewer | Uploader |
|
||||
| Manager | Viewer |
|
||||
| Space Editor | Viewer |
|
||||
| Space Viewer | Viewer |
|
||||
|
||||
@issue-7618
|
||||
Scenario Outline: user moves a file from space personal to space project with different role
|
||||
Given the administrator has assigned the role "Space Admin" to user "Brian" using the Graph API
|
||||
And user "Brian" has created a space "Project" with the default quota using the Graph API
|
||||
And user "Brian" has sent the following space share invitation:
|
||||
| space | Project |
|
||||
| sharee | Alice |
|
||||
| shareType | user |
|
||||
| permissionsRole | <space-role> |
|
||||
And user "Alice" has uploaded file with content "personal space content" to "/personal.txt"
|
||||
When user "Alice" moves file "personal.txt" from space "Personal" to "personal.txt" inside space "Project" using the WebDAV API
|
||||
Then the HTTP status code should be "<http-status-code>"
|
||||
And for user "Alice" the space "Personal" should contain these entries:
|
||||
| personal.txt |
|
||||
And for user "Alice" the space "Project" should not contain these entries:
|
||||
| personal.txt |
|
||||
Examples:
|
||||
| space-role | http-status-code |
|
||||
| Manager | 502 |
|
||||
| Space Editor | 502 |
|
||||
| Space Viewer | 403 |
|
||||
|
||||
|
||||
Scenario Outline: user moves a file from space personal to space Shares with different role (permission)
|
||||
Given user "Brian" has created folder "/testshare"
|
||||
And user "Brian" has sent the following resource share invitation:
|
||||
| resource | testshare |
|
||||
| space | Personal |
|
||||
| sharee | Alice |
|
||||
| shareType | user |
|
||||
| permissionsRole | <permissions-role> |
|
||||
And user "Alice" has a share "testshare" synced
|
||||
And user "Alice" has uploaded file with content "personal content" to "personal.txt"
|
||||
When user "Alice" moves file "personal.txt" from space "Personal" to "/testshare/personal.txt" inside space "Shares" using the WebDAV API
|
||||
Then the HTTP status code should be "502"
|
||||
And for user "Alice" the space "Personal" should contain these entries:
|
||||
| personal.txt |
|
||||
But for user "Alice" folder "testshare" of the space "Shares" should not contain these entries:
|
||||
| personal.txt |
|
||||
Examples:
|
||||
| permissions-role |
|
||||
| Editor |
|
||||
| Uploader |
|
||||
| Viewer |
|
||||
|
||||
|
||||
Scenario Outline: user moves a file from space Shares with different role (permissions) to space personal
|
||||
Given user "Brian" has created folder "/testshare"
|
||||
And user "Brian" has uploaded file with content "testshare content" to "/testshare/testshare.txt"
|
||||
And user "Brian" has sent the following resource share invitation:
|
||||
| resource | testshare |
|
||||
| space | Personal |
|
||||
| sharee | Alice |
|
||||
| shareType | user |
|
||||
| permissionsRole | <permissions-role> |
|
||||
And user "Alice" has a share "testshare" synced
|
||||
When user "Alice" moves file "/testshare/testshare.txt" from space "Shares" to "testshare.txt" inside space "Personal" using the WebDAV API
|
||||
Then the HTTP status code should be "502"
|
||||
And for user "Alice" the space "Personal" should not contain these entries:
|
||||
| testshare.txt |
|
||||
And for user "Alice" folder "testshare" of the space "Shares" should contain these entries:
|
||||
| testshare.txt |
|
||||
Examples:
|
||||
| permissions-role |
|
||||
| Editor |
|
||||
| Uploader |
|
||||
| Viewer |
|
||||
|
||||
|
||||
Scenario Outline: user moves a file from space Shares with different role (permissions) to space project with different role
|
||||
Given the administrator has assigned the role "Space Admin" to user "Brian" using the Graph API
|
||||
And user "Brian" has created a space "Project" with the default quota using the Graph API
|
||||
And user "Brian" has sent the following space share invitation:
|
||||
| space | Project |
|
||||
| sharee | Alice |
|
||||
| shareType | user |
|
||||
| permissionsRole | <space-role> |
|
||||
And user "Brian" has created folder "/testshare"
|
||||
And user "Brian" has uploaded file with content "testshare content" to "/testshare/testshare.txt"
|
||||
And user "Brian" has sent the following resource share invitation:
|
||||
| resource | testshare |
|
||||
| space | Personal |
|
||||
| sharee | Alice |
|
||||
| shareType | user |
|
||||
| permissionsRole | <permissions-role> |
|
||||
And user "Alice" has a share "testshare" synced
|
||||
When user "Alice" moves file "/testshare/testshare.txt" from space "Shares" to "testshare.txt" inside space "Project" using the WebDAV API
|
||||
Then the HTTP status code should be "502"
|
||||
And for user "Alice" the space "Project" should not contain these entries:
|
||||
| /testshare.txt |
|
||||
And for user "Alice" folder "testshare" of the space "Shares" should contain these entries:
|
||||
| testshare.txt |
|
||||
Examples:
|
||||
| space-role | permissions-role |
|
||||
| Manager | Editor |
|
||||
| Space Editor | Editor |
|
||||
| Space Viewer | Editor |
|
||||
| Manager | Uploader |
|
||||
| Space Editor | Uploader |
|
||||
| Space Viewer | Uploader |
|
||||
| Manager | Viewer |
|
||||
| Space Editor | Viewer |
|
||||
| Space Viewer | Viewer |
|
||||
|
||||
|
||||
Scenario Outline: user moves a file from space Shares to another space Shares with different role (permissions)
|
||||
Given user "Brian" has created folder "/testshare1"
|
||||
And user "Brian" has created folder "/testshare2"
|
||||
And user "Brian" has uploaded file with content "testshare1 content" to "/testshare1/testshare1.txt"
|
||||
And user "Brian" has sent the following resource share invitation:
|
||||
| resource | testshare1 |
|
||||
| space | Personal |
|
||||
| sharee | Alice |
|
||||
| shareType | user |
|
||||
| permissionsRole | <from-permissions-role> |
|
||||
And user "Alice" has a share "testshare1" synced
|
||||
And user "Brian" has sent the following resource share invitation:
|
||||
| resource | testshare2 |
|
||||
| space | Personal |
|
||||
| sharee | Alice |
|
||||
| shareType | user |
|
||||
| permissionsRole | <to-permissions-role> |
|
||||
And user "Alice" has a share "testshare2" synced
|
||||
When user "Alice" moves file "/testshare1/testshare1.txt" from space "Shares" to "/testshare2/testshare1.txt" inside space "Shares" using the WebDAV API
|
||||
Then the HTTP status code should be "502"
|
||||
And for user "Alice" folder "testshare1" of the space "Shares" should contain these entries:
|
||||
| testshare1.txt |
|
||||
But for user "Alice" folder "testshare2" of the space "Shares" should not contain these entries:
|
||||
| testshare1.txt |
|
||||
Examples:
|
||||
| from-permissions-role | to-permissions-role |
|
||||
| Editor | Editor |
|
||||
| Editor | Uploader |
|
||||
| Editor | Viewer |
|
||||
| Uploader | Editor |
|
||||
| Uploader | Uploader |
|
||||
| Uploader | Viewer |
|
||||
| Viewer | Editor |
|
||||
| Viewer | Uploader |
|
||||
| Viewer | Viewer |
|
||||
|
||||
|
||||
Scenario Outline: moving a file out of a shared folder as a sharer
|
||||
Given user "Brian" has created folder "/testshare"
|
||||
And user "Brian" has uploaded file with content "test data" to "/testshare/testfile.txt"
|
||||
And user "Brian" has sent the following resource share invitation:
|
||||
| resource | testshare |
|
||||
| space | Personal |
|
||||
| sharee | Alice |
|
||||
| shareType | user |
|
||||
| permissionsRole | <permissions-role> |
|
||||
And user "Alice" has a share "testshare" synced
|
||||
When user "Brian" moves file "/testshare/testfile.txt" from space "Personal" to "/testfile.txt" inside space "Personal" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And the content of file "/testfile.txt" for user "Brian" should be "test data"
|
||||
And for user "Alice" folder "testshare" of the space "Shares" should not contain these entries:
|
||||
| testfile.txt |
|
||||
And for user "Brian" folder "testshare" of the space "Personal" should not contain these entries:
|
||||
| testfile.txt |
|
||||
Examples:
|
||||
| permissions-role |
|
||||
| Editor |
|
||||
| Uploader |
|
||||
| Viewer |
|
||||
|
||||
|
||||
Scenario Outline: moving a folder out of a shared folder as a sharer
|
||||
Given user "Brian" has created the following folders
|
||||
| path |
|
||||
| /testshare |
|
||||
| /testshare/testsubfolder |
|
||||
And user "Brian" has uploaded file with content "test data" to "/testshare/testsubfolder/testfile.txt"
|
||||
And user "Brian" has sent the following resource share invitation:
|
||||
| resource | testshare |
|
||||
| space | Personal |
|
||||
| sharee | Alice |
|
||||
| shareType | user |
|
||||
| permissionsRole | <permissions-role> |
|
||||
And user "Alice" has a share "testshare" synced
|
||||
When user "Brian" moves folder "/testshare/testsubfolder" from space "Personal" to "/testsubfolder" inside space "Personal" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And the content of file "/testsubfolder/testfile.txt" for user "Brian" should be "test data"
|
||||
And for user "Alice" folder "testshare" of the space "Shares" should not contain these entries:
|
||||
| testsubfolder |
|
||||
And for user "Brian" folder "testshare" of the space "Personal" should not contain these entries:
|
||||
| testsubfolder |
|
||||
Examples:
|
||||
| permissions-role |
|
||||
| Editor |
|
||||
| Uploader |
|
||||
| Viewer |
|
||||
|
||||
|
||||
Scenario Outline: sharee moves a file within a Shares space (Editor/Uploader permissions)
|
||||
Given user "Brian" has created folder "testshare"
|
||||
And user "Brian" has created folder "testshare/child"
|
||||
And user "Brian" has uploaded file with content "test file content" to "/testshare/testfile.txt"
|
||||
And user "Brian" has sent the following resource share invitation:
|
||||
| resource | testshare |
|
||||
| space | Personal |
|
||||
| sharee | Alice |
|
||||
| shareType | user |
|
||||
| permissionsRole | <permissions-role> |
|
||||
And user "Alice" has a share "testshare" synced
|
||||
When user "Alice" moves file "testshare/testfile.txt" from space "Shares" to "testshare/child/testfile.txt" inside space "Shares" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And for user "Alice" the content of the file "testshare/child/testfile.txt" of the space "Shares" should be "test file content"
|
||||
And for user "Alice" folder "testshare" of the space "Shares" should not contain these entries:
|
||||
| testfile.txt |
|
||||
Examples:
|
||||
| permissions-role |
|
||||
| Editor |
|
||||
| Uploader |
|
||||
|
||||
|
||||
Scenario: sharee moves a file within a Shares space (viewer permissions)
|
||||
Given user "Brian" has created folder "testshare"
|
||||
And user "Brian" has created folder "testshare/child"
|
||||
And user "Brian" has uploaded file with content "test file content" to "/testshare/testfile.txt"
|
||||
And user "Brian" has sent the following resource share invitation:
|
||||
| resource | testshare |
|
||||
| space | Personal |
|
||||
| sharee | Alice |
|
||||
| shareType | user |
|
||||
| permissionsRole | Viewer |
|
||||
And user "Alice" has a share "testshare" synced
|
||||
When user "Alice" moves file "testshare/testfile.txt" from space "Shares" to "testshare/child/testfile.txt" inside space "Shares" using the WebDAV API
|
||||
Then the HTTP status code should be "403"
|
||||
And for user "Alice" folder "testshare/child" of the space "Shares" should not contain these entries:
|
||||
| testfile.txt |
|
||||
But for user "Alice" folder "testshare" of the space "Shares" should contain these entries:
|
||||
| testfile.txt |
|
||||
|
||||
@issue-1976
|
||||
Scenario Outline: sharee tries to move a file into same shared folder with same name
|
||||
Given user "Brian" has created folder "testshare"
|
||||
And user "Brian" has uploaded file with content "test file content" to "testshare/testfile.txt"
|
||||
And user "Brian" has sent the following resource share invitation:
|
||||
| resource | testshare |
|
||||
| space | Personal |
|
||||
| sharee | Alice |
|
||||
| shareType | user |
|
||||
| permissionsRole | <permissions-role> |
|
||||
And user "Alice" has a share "testshare" synced
|
||||
When user "Alice" moves file "testshare/testfile.txt" from space "Shares" to "testshare/testfile.txt" inside space "Shares" using the WebDAV API
|
||||
Then the HTTP status code should be "403"
|
||||
And as "Brian" file "testfile.txt" should not exist in the trashbin of the space "Personal"
|
||||
And for user "Alice" the content of the file "testshare/testfile.txt" of the space "Shares" should be "test file content"
|
||||
And for user "Brian" the content of the file "testshare/testfile.txt" of the space "Personal" should be "test file content"
|
||||
Examples:
|
||||
| permissions-role |
|
||||
| Editor |
|
||||
| Uploader |
|
||||
| Viewer |
|
||||
|
||||
|
||||
Scenario: overwrite a file while moving in project space
|
||||
Given the administrator has assigned the role "Space Admin" to user "Brian" using the Graph API
|
||||
And user "Brian" has created a space "Project" with the default quota using the Graph API
|
||||
And user "Brian" has created a folder "folder" in space "Project"
|
||||
And user "Brian" has uploaded a file inside space "Project" with content "root file v1" to "testfile.txt"
|
||||
And user "Brian" has uploaded a file inside space "Project" with content "root file v2" to "testfile.txt"
|
||||
And user "Brian" has uploaded a file inside space "Project" with content "same name file" to "folder/testfile.txt"
|
||||
And user "Brian" has sent the following space share invitation:
|
||||
| space | Project |
|
||||
| sharee | Alice |
|
||||
| shareType | user |
|
||||
| permissionsRole | Space Editor |
|
||||
When user "Alice" overwrites file "testfile.txt" from space "Project" to "folder/testfile.txt" inside space "Project" while moving using the WebDAV API
|
||||
Then the HTTP status code should be "204"
|
||||
And for user "Alice" the content of the file "folder/testfile.txt" of the space "Project" should be "root file v2"
|
||||
And for user "Alice" the space "Project" should not contain these entries:
|
||||
| testfile.txt |
|
||||
When user "Brian" downloads version of the file "folder/testfile.txt" with the index "1" of the space "Project" using the WebDAV API
|
||||
Then the HTTP status code should be "200"
|
||||
And the downloaded content should be "root file v1"
|
||||
@@ -0,0 +1,47 @@
|
||||
Feature: Public can download folders from project space public link
|
||||
As a public
|
||||
I want to be able to download folder from public link
|
||||
So that I can gain access to it's contents
|
||||
|
||||
Background:
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
And using spaces DAV path
|
||||
And the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
|
||||
And user "Alice" has created a space "new-space" with the default quota using the Graph API
|
||||
|
||||
@env-config @issue-9724 @issue-10331
|
||||
Scenario: download a folder from public link of a space
|
||||
Given the config "OC_SHARING_PUBLIC_SHARE_MUST_HAVE_PASSWORD" has been set to "false"
|
||||
And using SharingNG
|
||||
And user "Alice" has created a folder "NewFolder" in space "new-space"
|
||||
And user "Alice" has uploaded a file inside space "new-space" with content "some content" to "NewFolder/test.txt"
|
||||
And user "Alice" has created the following space link share:
|
||||
| space | new-space |
|
||||
| displayName | someName |
|
||||
| permissionsRole | view |
|
||||
When public downloads the folder "NewFolder" from the last created public link using the public files API
|
||||
Then the HTTP status code should be "200"
|
||||
And the downloaded zip archive should contain these files:
|
||||
| name | content |
|
||||
| NewFolder/test.txt | some content |
|
||||
|
||||
@env-config @issue-5229 @issue-9724 @issue-10331
|
||||
Scenario: download a folder from public link of a folder inside a space
|
||||
Given the config "OC_SHARING_PUBLIC_SHARE_MUST_HAVE_PASSWORD" has been set to "false"
|
||||
And using SharingNG
|
||||
And user "Alice" has created a folder "NewFolder" in space "new-space"
|
||||
And user "Alice" has created a folder "NewFolder/folder" in space "new-space"
|
||||
And user "Alice" has uploaded a file inside space "new-space" with content "some content" to "NewFolder/folder/test.txt"
|
||||
And user "Alice" has created the following resource link share:
|
||||
| resource | NewFolder |
|
||||
| space | new-space |
|
||||
| displayName | public link |
|
||||
| permissionsRole | view |
|
||||
When public downloads the folder "folder" from the last created public link using the public files API
|
||||
Then the HTTP status code should be "200"
|
||||
And the downloaded zip archive should contain these files:
|
||||
| name | content |
|
||||
| folder/test.txt | some content |
|
||||
@@ -0,0 +1,485 @@
|
||||
Feature: sharing
|
||||
As a user
|
||||
I want to share resources with different permissions
|
||||
So that I can manage the access to the resource
|
||||
|
||||
Background:
|
||||
Given using OCS API version "1"
|
||||
And these users have been created with default attributes:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
And using spaces DAV path
|
||||
|
||||
|
||||
Scenario: correct webdav share-permissions for received file with edit permissions
|
||||
Given user "Alice" has uploaded file with content "foo" to "/tmp.txt"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | tmp.txt |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | File Editor |
|
||||
And user "Brian" has a share "tmp.txt" synced
|
||||
When user "Brian" gets the following properties of file "/tmp.txt" inside space "Shares" using the WebDAV API
|
||||
| propertyName |
|
||||
| ocs:share-permissions |
|
||||
Then the HTTP status code should be "207"
|
||||
And the single response should contain a property "ocs:share-permissions" with value "3"
|
||||
|
||||
|
||||
Scenario: correct webdav share-permissions for received group shared file with edit permissions
|
||||
Given group "grp1" has been created
|
||||
And user "Brian" has been added to group "grp1"
|
||||
And user "Alice" has uploaded file with content "foo" to "/tmp.txt"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | tmp.txt |
|
||||
| space | Personal |
|
||||
| sharee | grp1 |
|
||||
| shareType | group |
|
||||
| permissionsRole | File Editor |
|
||||
And user "Brian" has a share "tmp.txt" synced
|
||||
When user "Brian" gets the following properties of file "/tmp.txt" inside space "Shares" using the WebDAV API
|
||||
| propertyName |
|
||||
| ocs:share-permissions |
|
||||
Then the HTTP status code should be "207"
|
||||
And the single response should contain a property "ocs:share-permissions" with value "3"
|
||||
|
||||
|
||||
Scenario: correct webdav share-permissions for received file with read permissions
|
||||
Given user "Alice" has uploaded file with content "foo" to "/tmp.txt"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | tmp.txt |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Viewer |
|
||||
And user "Brian" has a share "tmp.txt" synced
|
||||
When user "Brian" gets the following properties of file "/tmp.txt" inside space "Shares" using the WebDAV API
|
||||
| propertyName |
|
||||
| ocs:share-permissions |
|
||||
Then the HTTP status code should be "207"
|
||||
And the single response should contain a property "ocs:share-permissions" with value "1"
|
||||
|
||||
|
||||
Scenario: correct webdav share-permissions for received group shared file with read permissions
|
||||
Given group "grp1" has been created
|
||||
And user "Brian" has been added to group "grp1"
|
||||
And user "Alice" has uploaded file with content "foo" to "/tmp.txt"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | tmp.txt |
|
||||
| space | Personal |
|
||||
| sharee | grp1 |
|
||||
| shareType | group |
|
||||
| permissionsRole | Viewer |
|
||||
And user "Brian" has a share "tmp.txt" synced
|
||||
When user "Brian" gets the following properties of file "/tmp.txt" inside space "Shares" using the WebDAV API
|
||||
| propertyName |
|
||||
| ocs:share-permissions |
|
||||
Then the HTTP status code should be "207"
|
||||
And the single response should contain a property "ocs:share-permissions" with value "1"
|
||||
|
||||
|
||||
Scenario: correct webdav share-permissions for received folder with all permissions
|
||||
Given user "Alice" has created folder "/tmp"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | tmp |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "tmp" synced
|
||||
When user "Brian" gets the following properties of folder "/tmp" inside space "Shares" using the WebDAV API
|
||||
| propertyName |
|
||||
| ocs:share-permissions |
|
||||
Then the HTTP status code should be "207"
|
||||
And the single response should contain a property "ocs:share-permissions" with value "15"
|
||||
|
||||
|
||||
Scenario: correct webdav share-permissions for received group shared folder with all permissions
|
||||
Given group "grp1" has been created
|
||||
And user "Brian" has been added to group "grp1"
|
||||
And user "Alice" has created folder "/tmp"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | tmp |
|
||||
| space | Personal |
|
||||
| sharee | grp1 |
|
||||
| shareType | group |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "tmp" synced
|
||||
When user "Brian" gets the following properties of folder "/tmp" inside space "Shares" using the WebDAV API
|
||||
| propertyName |
|
||||
| ocs:share-permissions |
|
||||
Then the HTTP status code should be "207"
|
||||
And the single response should contain a property "ocs:share-permissions" with value "15"
|
||||
|
||||
|
||||
Scenario: correct webdav share-permissions for received folder with all permissions but edit
|
||||
Given user "Alice" has created folder "/tmp"
|
||||
And using SharingNG
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | tmp |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "tmp" synced
|
||||
When user "Alice" updates the last share using the sharing API with
|
||||
| permissions | delete,create,read |
|
||||
Then the HTTP status code should be "200"
|
||||
And as user "Brian" folder "/tmp" inside space "Shares" should contain a property "ocs:share-permissions" with value "13"
|
||||
|
||||
|
||||
Scenario: correct webdav share-permissions for received group shared folder with all permissions but edit
|
||||
Given group "grp1" has been created
|
||||
And user "Brian" has been added to group "grp1"
|
||||
And user "Alice" has created folder "/tmp"
|
||||
And using SharingNG
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | tmp |
|
||||
| space | Personal |
|
||||
| sharee | grp1 |
|
||||
| shareType | group |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "tmp" synced
|
||||
When user "Alice" updates the last share using the sharing API with
|
||||
| permissions | delete,create,read |
|
||||
Then the HTTP status code should be "200"
|
||||
And as user "Brian" folder "/tmp" inside space "Shares" should contain a property "ocs:share-permissions" with value "13"
|
||||
|
||||
|
||||
Scenario: correct webdav share-permissions for received folder with all permissions but create
|
||||
Given user "Alice" has created folder "/tmp"
|
||||
And using SharingNG
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | tmp |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "tmp" synced
|
||||
When user "Alice" updates the last share using the sharing API with
|
||||
| permissions | delete,update,read |
|
||||
Then the HTTP status code should be "200"
|
||||
And as user "Brian" folder "/tmp" inside space "Shares" should contain a property "ocs:share-permissions" with value "11"
|
||||
|
||||
|
||||
Scenario: correct webdav share-permissions for received group shared folder with all permissions but create
|
||||
Given group "grp1" has been created
|
||||
And user "Brian" has been added to group "grp1"
|
||||
And user "Alice" has created folder "/tmp"
|
||||
And using SharingNG
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | tmp |
|
||||
| space | Personal |
|
||||
| sharee | grp1 |
|
||||
| shareType | group |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "tmp" synced
|
||||
When user "Alice" updates the last share using the sharing API with
|
||||
| permissions | delete,update,read |
|
||||
Then the HTTP status code should be "200"
|
||||
And as user "Brian" folder "/tmp" inside space "Shares" should contain a property "ocs:share-permissions" with value "11"
|
||||
|
||||
|
||||
Scenario: correct webdav share-permissions for received folder with all permissions but delete
|
||||
Given user "Alice" has created folder "/tmp"
|
||||
And using SharingNG
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | tmp |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "tmp" synced
|
||||
When user "Alice" updates the last share using the sharing API with
|
||||
| permissions | create,update,read |
|
||||
Then the HTTP status code should be "200"
|
||||
And as user "Brian" folder "/tmp" inside space "Shares" should contain a property "ocs:share-permissions" with value "7"
|
||||
|
||||
|
||||
Scenario: correct webdav share-permissions for received group shared folder with all permissions but delete
|
||||
Given group "grp1" has been created
|
||||
And user "Brian" has been added to group "grp1"
|
||||
And user "Alice" has created folder "/tmp"
|
||||
And using SharingNG
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | tmp |
|
||||
| space | Personal |
|
||||
| sharee | grp1 |
|
||||
| shareType | group |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "tmp" synced
|
||||
When user "Alice" updates the last share using the sharing API with
|
||||
| permissions | create,update,read |
|
||||
Then the HTTP status code should be "200"
|
||||
And as user "Brian" folder "/tmp" inside space "Shares" should contain a property "ocs:share-permissions" with value "7"
|
||||
|
||||
|
||||
Scenario: uploading a file to a folder received as a read-only user share
|
||||
Given user "Alice" has created folder "FOLDER"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | FOLDER |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Viewer |
|
||||
And user "Brian" has a share "FOLDER" synced
|
||||
When user "Brian" uploads a file inside space "Shares" with content "new description" to "/FOLDER/textfile.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "403"
|
||||
And as "Alice" file "/FOLDER/textfile.txt" should not exist
|
||||
|
||||
|
||||
Scenario: uploading a file to a folder received as a read-only group share
|
||||
Given group "grp1" has been created
|
||||
And user "Brian" has been added to group "grp1"
|
||||
And user "Alice" has created folder "FOLDER"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | FOLDER |
|
||||
| space | Personal |
|
||||
| sharee | grp1 |
|
||||
| shareType | group |
|
||||
| permissionsRole | Viewer |
|
||||
And user "Brian" has a share "FOLDER" synced
|
||||
When user "Brian" uploads a file inside space "Shares" with content "new description" to "/FOLDER/textfile.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "403"
|
||||
And as "Alice" file "/FOLDER/textfile.txt" should not exist
|
||||
|
||||
|
||||
Scenario: uploading a file to a folder received as a upload-only user share
|
||||
Given user "Alice" has created folder "FOLDER"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | FOLDER |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Uploader |
|
||||
And user "Brian" has a share "FOLDER" synced
|
||||
When user "Brian" uploads a file inside space "Shares" with content "new description" to "/FOLDER/textfile.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And the following headers should match these regular expressions for user "Brian"
|
||||
| ETag | /^"[a-f0-9:\.]{1,32}"$/ |
|
||||
And the content of file "/FOLDER/textfile.txt" for user "Alice" should be:
|
||||
"""
|
||||
new description
|
||||
"""
|
||||
|
||||
|
||||
Scenario: uploading a file to a folder received as a upload-only group share
|
||||
Given group "grp1" has been created
|
||||
And user "Brian" has been added to group "grp1"
|
||||
And user "Alice" has created folder "FOLDER"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | FOLDER |
|
||||
| space | Personal |
|
||||
| sharee | grp1 |
|
||||
| shareType | group |
|
||||
| permissionsRole | Uploader |
|
||||
And user "Brian" has a share "FOLDER" synced
|
||||
When user "Brian" uploads a file inside space "Shares" with content "new description" to "/FOLDER/textfile.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And the following headers should match these regular expressions for user "Brian"
|
||||
| ETag | /^"[a-f0-9:\.]{1,32}"$/ |
|
||||
And the content of file "/FOLDER/textfile.txt" for user "Alice" should be:
|
||||
"""
|
||||
new description
|
||||
"""
|
||||
|
||||
|
||||
Scenario: uploading a file to a folder received as a read/write user share
|
||||
Given user "Alice" has created folder "FOLDER"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | FOLDER |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "FOLDER" synced
|
||||
When user "Brian" uploads a file inside space "Shares" with content "new description" to "/FOLDER/textfile.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And the content of file "/FOLDER/textfile.txt" for user "Alice" should be:
|
||||
"""
|
||||
new description
|
||||
"""
|
||||
|
||||
|
||||
Scenario: uploading a file to a folder received as a read/write group share
|
||||
Given group "grp1" has been created
|
||||
And user "Brian" has been added to group "grp1"
|
||||
And user "Alice" has created folder "FOLDER"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | FOLDER |
|
||||
| space | Personal |
|
||||
| sharee | grp1 |
|
||||
| shareType | group |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "FOLDER" synced
|
||||
When user "Brian" uploads a file inside space "Shares" with content "new description" to "/FOLDER/textfile.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And the content of file "/FOLDER/textfile.txt" for user "Alice" should be:
|
||||
"""
|
||||
new description
|
||||
"""
|
||||
|
||||
|
||||
Scenario: uploading to a user shared folder with read/write permission when the sharer has insufficient quota
|
||||
Given user "Alice" has created folder "FOLDER"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | FOLDER |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "FOLDER" synced
|
||||
And user "Admin" has changed the quota of the personal space of user "Alice" to "1"
|
||||
When user "Brian" uploads a file inside space "Shares" with content "new description" to "/FOLDER/textfile.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "507"
|
||||
And as "Alice" file "/FOLDER/textfile.txt" should not exist
|
||||
|
||||
|
||||
Scenario: uploading to a user shared folder with read/write permission when the sharer has insufficient quota
|
||||
Given group "grp1" has been created
|
||||
And user "Brian" has been added to group "grp1"
|
||||
And user "Alice" has created folder "FOLDER"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | FOLDER |
|
||||
| space | Personal |
|
||||
| sharee | grp1 |
|
||||
| shareType | group |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "FOLDER" synced
|
||||
And user "Admin" has changed the quota of the personal space of user "Alice" to "1"
|
||||
When user "Brian" uploads a file inside space "Shares" with content "new description" to "/FOLDER/textfile.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "507"
|
||||
And as "Alice" file "/FOLDER/textfile.txt" should not exist
|
||||
|
||||
|
||||
Scenario: uploading to a user shared folder with upload-only permission when the sharer has insufficient quota
|
||||
Given user "Alice" has created folder "FOLDER"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | FOLDER |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Uploader |
|
||||
And user "Brian" has a share "FOLDER" synced
|
||||
And user "Admin" has changed the quota of the personal space of user "Alice" to "1"
|
||||
When user "Brian" uploads a file inside space "Shares" with content "new description" to "/FOLDER/textfile.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "507"
|
||||
And as "Alice" file "/FOLDER/textfile.txt" should not exist
|
||||
|
||||
|
||||
Scenario: uploading a file to a group shared folder with upload-only permission when the sharer has insufficient quota
|
||||
Given group "grp1" has been created
|
||||
And user "Brian" has been added to group "grp1"
|
||||
And user "Alice" has created folder "FOLDER"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | FOLDER |
|
||||
| space | Personal |
|
||||
| sharee | grp1 |
|
||||
| shareType | group |
|
||||
| permissionsRole | Uploader |
|
||||
And user "Brian" has a share "FOLDER" synced
|
||||
And user "Admin" has changed the quota of the personal space of user "Alice" to "10"
|
||||
When user "Brian" uploads a file inside space "Shares" with content "new descriptionfgshsywhhh" to "/FOLDER/textfile.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "507"
|
||||
And as "Alice" file "/FOLDER/textfile.txt" should not exist
|
||||
|
||||
|
||||
Scenario Outline: sharer can download file uploaded with different permission by sharee to a shared folder
|
||||
Given user "Alice" has created folder "FOLDER"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | FOLDER |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <permissions-role> |
|
||||
And user "Brian" has a share "FOLDER" synced
|
||||
When user "Brian" uploads a file inside space "Shares" with content "some content" to "/FOLDER/textfile.txt" using the WebDAV API
|
||||
And user "Alice" downloads file "/FOLDER/textfile.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "200"
|
||||
And the downloaded content should be "some content"
|
||||
Examples:
|
||||
| permissions-role |
|
||||
| Editor |
|
||||
| Uploader |
|
||||
|
||||
@env-config
|
||||
Scenario: sharee cannot download file shared with Secure viewer permission by sharee
|
||||
Given using old DAV path
|
||||
And the administrator has enabled the permissions role "Secure Viewer"
|
||||
And user "Alice" has uploaded file with content "hello world" to "textfile.txt"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | textfile.txt |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Secure Viewer |
|
||||
And user "Brian" has a share "textfile.txt" synced
|
||||
And user "Brian" downloads file "/Shares/textfile.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "403"
|
||||
|
||||
@env-config
|
||||
Scenario: sharee cannot download file inside folder shared with Secure viewer permission by sharee
|
||||
Given using old DAV path
|
||||
And the administrator has enabled the permissions role "Secure Viewer"
|
||||
And user "Alice" has created folder "FolderToShare"
|
||||
And user "Alice" has uploaded file with content "hello world" to "FolderToShare/textfile.txt"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | FolderToShare |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Secure Viewer |
|
||||
And user "Brian" has a share "FolderToShare" synced
|
||||
And user "Brian" downloads file "/Shares/FolderToShare/textfile.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "403"
|
||||
|
||||
|
||||
Scenario Outline: space admin tries to remove password of a public link share (change/create permission)
|
||||
Given using spaces DAV path
|
||||
And using OCS API version "<ocs-api-version>"
|
||||
And the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
|
||||
And user "Alice" has created folder "FOLDER"
|
||||
And using SharingNG
|
||||
And user "Alice" has created the following resource link share:
|
||||
| resource | FOLDER |
|
||||
| space | Personal |
|
||||
| permissionsRole | <permissions-role> |
|
||||
| password | %public% |
|
||||
When user "Alice" updates the last public link share using the sharing API with
|
||||
| path | /FOLDER |
|
||||
| permissions | <permissions> |
|
||||
| password | |
|
||||
Then the HTTP status code should be "<http-status-code>"
|
||||
And the OCS status code should be "400"
|
||||
And the OCS status message should be "missing required password"
|
||||
Examples:
|
||||
| ocs-api-version | permissions-role | permissions | http-status-code |
|
||||
| 1 | edit | change | 200 |
|
||||
| 2 | edit | change | 400 |
|
||||
| 1 | createOnly | create | 200 |
|
||||
| 2 | createOnly | create | 400 |
|
||||
|
||||
|
||||
Scenario Outline: space admin removes password of a public link share (read permission)
|
||||
Given using spaces DAV path
|
||||
And using OCS API version "<ocs-api-version>"
|
||||
And the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
|
||||
And user "Alice" has created folder "FOLDER"
|
||||
And using SharingNG
|
||||
And user "Alice" has created the following resource link share:
|
||||
| resource | FOLDER |
|
||||
| space | Personal |
|
||||
| permissionsRole | view |
|
||||
| password | %public% |
|
||||
When user "Alice" updates the last public link share using the sharing API with
|
||||
| path | /FOLDER |
|
||||
| permissions | read |
|
||||
| password | |
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "<ocs-status-code>"
|
||||
Examples:
|
||||
| ocs-api-version | ocs-status-code |
|
||||
| 1 | 100 |
|
||||
| 2 | 200 |
|
||||
@@ -0,0 +1,509 @@
|
||||
Feature: Share spaces
|
||||
As the owner of a space
|
||||
I want to be able to add members to a space, and to remove access for them
|
||||
So that I can manage the access to the space
|
||||
|
||||
Background:
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
| Bob |
|
||||
And the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
|
||||
And user "Alice" has created a space "share space" with the default quota using the Graph API
|
||||
And using spaces DAV path
|
||||
|
||||
|
||||
Scenario Outline: space admin can share a space to another user
|
||||
When user "Alice" shares a space "share space" with settings:
|
||||
| shareWith | Brian |
|
||||
| role | <space-role> |
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "200"
|
||||
And the OCS status message should be "OK"
|
||||
And the user "Brian" should have a space called "share space"
|
||||
Examples:
|
||||
| space-role |
|
||||
| manager |
|
||||
| editor |
|
||||
| viewer |
|
||||
|
||||
|
||||
Scenario: user can see who has been granted access
|
||||
When user "Alice" shares a space "share space" with settings:
|
||||
| shareWith | Brian |
|
||||
| role | viewer |
|
||||
Then the user "Alice" should have a space called "share space" granted to user "Brian" with role "viewer"
|
||||
|
||||
|
||||
Scenario: user can see that the group has been granted access
|
||||
Given group "sales" has been created
|
||||
When user "Alice" shares a space "share space" with settings:
|
||||
| shareWith | sales |
|
||||
| shareType | 8 |
|
||||
| role | viewer |
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "200"
|
||||
And the user "Alice" should have a space called "share space" granted to group "sales" with role "viewer"
|
||||
|
||||
|
||||
Scenario: user can see a file in a received shared space
|
||||
Given user "Alice" has uploaded a file inside space "share space" with content "Test" to "test.txt"
|
||||
And user "Alice" has created a folder "Folder Main" in space "share space"
|
||||
When user "Alice" shares a space "share space" with settings:
|
||||
| shareWith | Brian |
|
||||
| role | viewer |
|
||||
Then for user "Brian" the space "share space" should contain these entries:
|
||||
| test.txt |
|
||||
| Folder Main |
|
||||
|
||||
|
||||
Scenario: user unshares a space
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Space Viewer |
|
||||
When user "Alice" unshares a space "share space" to user "Brian"
|
||||
Then the HTTP status code should be "200"
|
||||
But the user "Brian" should not have a space called "share space"
|
||||
|
||||
|
||||
Scenario Outline: owner of a space cannot see the space after removing his access to the space
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Manager |
|
||||
When user "<user>" unshares a space "share space" to user "Alice"
|
||||
Then the HTTP status code should be "200"
|
||||
But the user "Alice" should not have a space called "share space"
|
||||
Examples:
|
||||
| user |
|
||||
| Alice |
|
||||
| Brian |
|
||||
|
||||
|
||||
Scenario: user can add another user to the space managers to enable him
|
||||
Given user "Alice" has uploaded a file inside space "share space" with content "Test" to "test.txt"
|
||||
When user "Alice" shares a space "share space" with settings:
|
||||
| shareWith | Brian |
|
||||
| role | manager |
|
||||
Then the user "Brian" should have a space called "share space" granted to "Brian" with role "manager"
|
||||
When user "Brian" shares a space "share space" with settings:
|
||||
| shareWith | Bob |
|
||||
| role | viewer |
|
||||
Then the user "Bob" should have a space called "share space" granted to "Bob" with role "viewer"
|
||||
And for user "Bob" the space "share space" should contain these entries:
|
||||
| test.txt |
|
||||
|
||||
|
||||
Scenario Outline: user cannot share a disabled space to another user
|
||||
Given user "Alice" has disabled a space "share space"
|
||||
When user "Alice" shares a space "share space" with settings:
|
||||
| shareWith | Brian |
|
||||
| role | <space-role> |
|
||||
Then the HTTP status code should be "404"
|
||||
And the OCS status code should be "404"
|
||||
And the OCS status message should be "Wrong path, file/folder doesn't exist"
|
||||
But the user "Brian" should not have a space called "share space"
|
||||
Examples:
|
||||
| space-role |
|
||||
| manager |
|
||||
| editor |
|
||||
| viewer |
|
||||
|
||||
|
||||
Scenario Outline: user with manager role can share a space to another user
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Manager |
|
||||
When user "Brian" shares a space "share space" with settings:
|
||||
| shareWith | Bob |
|
||||
| role | <space-role> |
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "200"
|
||||
And the OCS status message should be "OK"
|
||||
And the user "Bob" should have a space called "share space"
|
||||
Examples:
|
||||
| space-role |
|
||||
| manager |
|
||||
| editor |
|
||||
| viewer |
|
||||
|
||||
|
||||
Scenario Outline: user with editor or viewer role cannot share a space to another user
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <space-role> |
|
||||
When user "Brian" shares a space "share space" with settings:
|
||||
| shareWith | Bob |
|
||||
| role | <share-space-role> |
|
||||
Then the HTTP status code should be "403"
|
||||
And the OCS status code should be "403"
|
||||
And the OCS status message should be "No share permission"
|
||||
And the user "Bob" should not have a space called "share space"
|
||||
Examples:
|
||||
| space-role | share-space-role |
|
||||
| Space Editor | manager |
|
||||
| Space Editor | editor |
|
||||
| Space Editor | viewer |
|
||||
| Space Viewer | manager |
|
||||
| Space Viewer | editor |
|
||||
| Space Viewer | viewer |
|
||||
|
||||
|
||||
Scenario Outline: space manager can change the role of space members
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <space-role> |
|
||||
When user "Alice" shares a space "share space" with settings:
|
||||
| shareWith | Brian |
|
||||
| role | <share-space-role> |
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "200"
|
||||
And the user "Alice" should have a space called "share space" granted to "Brian" with role "<share-space-role>"
|
||||
Examples:
|
||||
| space-role | share-space-role |
|
||||
| Space Editor | manager |
|
||||
| Space Editor | viewer |
|
||||
| Space Viewer | manager |
|
||||
| Space Viewer | editor |
|
||||
| Manager | editor |
|
||||
| Manager | viewer |
|
||||
|
||||
|
||||
Scenario Outline: user without manager role cannot change the role of space members
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <space-role> |
|
||||
And user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | Bob |
|
||||
| shareType | user |
|
||||
| permissionsRole | Space Viewer |
|
||||
When user "Brian" updates the space "share space" with settings:
|
||||
| shareWith | Bob |
|
||||
| role | <share-space-role> |
|
||||
Then the HTTP status code should be "403"
|
||||
And the OCS status code should be "403"
|
||||
And the user "Alice" should have a space called "share space" granted to "Bob" with role "viewer"
|
||||
Examples:
|
||||
| space-role | share-space-role |
|
||||
| Space Editor | manager |
|
||||
| Space Editor | viewer |
|
||||
| Space Viewer | manager |
|
||||
| Space Viewer | editor |
|
||||
|
||||
|
||||
Scenario Outline: user shares a space with a group
|
||||
Given group "group2" has been created
|
||||
And the administrator has added a user "Brian" to the group "group2" using the Graph API
|
||||
And the administrator has added a user "Bob" to the group "group2" using the Graph API
|
||||
When user "Alice" shares a space "share space" with settings:
|
||||
| shareWith | group2 |
|
||||
| shareType | 8 |
|
||||
| role | <space-role> |
|
||||
Then the HTTP status code should be "200"
|
||||
And the user "Brian" should have a space called "share space"
|
||||
And the user "Bob" should have a space called "share space"
|
||||
Examples:
|
||||
| space-role |
|
||||
| manager |
|
||||
| editor |
|
||||
| viewer |
|
||||
|
||||
|
||||
Scenario Outline: user has no access to the space if access for the group has been removed
|
||||
Given group "group2" has been created
|
||||
And the administrator has added a user "Brian" to the group "group2" using the Graph API
|
||||
And user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | group2 |
|
||||
| shareType | group |
|
||||
| permissionsRole | <space-role> |
|
||||
When user "Alice" unshares a space "share space" to group "group2"
|
||||
Then the HTTP status code should be "200"
|
||||
And the user "Brian" should not have a space called "share space"
|
||||
Examples:
|
||||
| space-role |
|
||||
| Manager |
|
||||
| Space Editor |
|
||||
| Space Viewer |
|
||||
|
||||
|
||||
Scenario: user has no access to the space if he has been removed from the group
|
||||
Given group "group2" has been created
|
||||
And the administrator has added a user "Brian" to the group "group2" using the Graph API
|
||||
And the administrator has added a user "Bob" to the group "group2" using the Graph API
|
||||
And user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | group2 |
|
||||
| shareType | group |
|
||||
| permissionsRole | Space Editor |
|
||||
When the administrator removes the following users from the following groups using the Graph API
|
||||
| username | groupname |
|
||||
| Brian | group2 |
|
||||
Then the HTTP status code of responses on all endpoints should be "204"
|
||||
And the user "Brian" should not have a space called "share space"
|
||||
But the user "Bob" should have a space called "share space"
|
||||
|
||||
|
||||
Scenario: users don't have access to the space if the group has been deleted
|
||||
Given group "group2" has been created
|
||||
And the administrator has added a user "Brian" to the group "group2" using the Graph API
|
||||
And the administrator has added a user "Bob" to the group "group2" using the Graph API
|
||||
And user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | group2 |
|
||||
| shareType | group |
|
||||
| permissionsRole | Space Editor |
|
||||
When the administrator deletes group "group2" using the Graph API
|
||||
Then the HTTP status code should be "204"
|
||||
And the user "Bob" should not have a space called "share space"
|
||||
And the user "Brian" should not have a space called "share space"
|
||||
|
||||
|
||||
Scenario: user increases permissions for one member of the group or for the entire group
|
||||
Given group "sales" has been created
|
||||
And the administrator has added a user "Brian" to the group "sales" using the Graph API
|
||||
And user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | sales |
|
||||
| shareType | group |
|
||||
| permissionsRole | Space Viewer |
|
||||
When user "Brian" uploads a file inside space "share space" with content "Test" to "test.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "403"
|
||||
When user "Alice" shares a space "share space" with settings:
|
||||
| shareWith | Brian |
|
||||
| role | editor |
|
||||
Then the HTTP status code should be "200"
|
||||
When user "Brian" uploads a file inside space "share space" with content "Test" to "test.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
|
||||
|
||||
Scenario: user increases permissions for the group, so the user's permissions are increased
|
||||
Given group "sales" has been created
|
||||
And the administrator has added a user "Brian" to the group "sales" using the Graph API
|
||||
And user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Space Viewer |
|
||||
When user "Brian" uploads a file inside space "share space" with content "Test" to "test.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "403"
|
||||
When user "Alice" shares a space "share space" with settings:
|
||||
| shareWith | sales |
|
||||
| shareType | 8 |
|
||||
| role | editor |
|
||||
Then the HTTP status code should be "200"
|
||||
When user "Brian" uploads a file inside space "share space" with content "Test" to "test.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
|
||||
|
||||
Scenario Outline: space Admin can share a space to the user with an expiration date
|
||||
When user "Alice" shares a space "share space" with settings:
|
||||
| shareWith | Brian |
|
||||
| role | <space-role> |
|
||||
| expireDate | 2042-03-25T23:59:59+0100 |
|
||||
Then the HTTP status code should be "200"
|
||||
And the user "Brian" should have a space called "share space" granted to user "Brian" with role "<space-role>" and expiration date "2042-03-25"
|
||||
Examples:
|
||||
| space-role |
|
||||
| manager |
|
||||
| editor |
|
||||
| viewer |
|
||||
|
||||
|
||||
Scenario Outline: space Admin can share a space to the group with an expiration date
|
||||
Given group "sales" has been created
|
||||
And the administrator has added a user "Brian" to the group "sales" using the Graph API
|
||||
When user "Alice" shares a space "share space" with settings:
|
||||
| shareWith | sales |
|
||||
| shareType | 8 |
|
||||
| role | <space-role> |
|
||||
| expireDate | 2042-03-25T23:59:59+0100 |
|
||||
Then the HTTP status code should be "200"
|
||||
And the user "Brian" should have a space called "share space" granted to group "sales" with role "<space-role>" and expiration date "2042-03-25"
|
||||
Examples:
|
||||
| space-role |
|
||||
| manager |
|
||||
| editor |
|
||||
| viewer |
|
||||
|
||||
|
||||
Scenario Outline: update the expiration date of a space in user share
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <space-role> |
|
||||
| expirationDateTime | 2042-03-25T23:59:59.000Z |
|
||||
When user "Alice" updates the space "share space" with settings:
|
||||
| shareWith | Brian |
|
||||
| expireDate | 2044-01-01T23:59:59.999+01:00 |
|
||||
| role | <share-space-role> |
|
||||
Then the HTTP status code should be "200"
|
||||
And the user "Brian" should have a space called "share space" granted to user "Brian" with role "<share-space-role>" and expiration date "2044-01-01"
|
||||
Examples:
|
||||
| space-role | share-space-role |
|
||||
| Manager | manager |
|
||||
| Space Editor | editor |
|
||||
| Space Viewer | viewer |
|
||||
|
||||
|
||||
Scenario Outline: update the expiration date of a space in group share
|
||||
Given group "sales" has been created
|
||||
And the administrator has added a user "Brian" to the group "sales" using the Graph API
|
||||
And user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | sales |
|
||||
| shareType | group |
|
||||
| permissionsRole | <space-role> |
|
||||
| expirationDateTime | 2042-03-25T23:59:59.000Z |
|
||||
When user "Alice" updates the space "share space" with settings:
|
||||
| shareWith | sales |
|
||||
| shareType | 8 |
|
||||
| expireDate | 2044-01-01T23:59:59.999+01:00 |
|
||||
| role | <share-space-role> |
|
||||
Then the HTTP status code should be "200"
|
||||
And the user "Brian" should have a space called "share space" granted to group "sales" with role "<share-space-role>" and expiration date "2044-01-01"
|
||||
Examples:
|
||||
| space-role | share-space-role |
|
||||
| Manager | manager |
|
||||
| Space Editor | editor |
|
||||
| Space Viewer | viewer |
|
||||
|
||||
|
||||
Scenario Outline: delete the expiration date of a space in user share
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <space-role> |
|
||||
| expirationDateTime | 2042-03-25T23:59:59.000Z |
|
||||
When user "Alice" updates the space "share space" with settings:
|
||||
| shareWith | Brian |
|
||||
| expireDate | |
|
||||
| role | <share-space-role> |
|
||||
Then the HTTP status code should be "200"
|
||||
And the user "Brian" should have a space called "share space" granted to user "Brian" with role "<share-space-role>" and expiration date ""
|
||||
Examples:
|
||||
| space-role | share-space-role |
|
||||
| Manager | manager |
|
||||
| Space Editor | editor |
|
||||
| Space Viewer | viewer |
|
||||
|
||||
|
||||
Scenario Outline: delete the expiration date of a space in group share
|
||||
Given group "sales" has been created
|
||||
And the administrator has added a user "Brian" to the group "sales" using the Graph API
|
||||
And user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | sales |
|
||||
| shareType | group |
|
||||
| permissionsRole | <space-role> |
|
||||
| expirationDateTime | 2042-03-25T23:59:59.000Z |
|
||||
When user "Alice" updates the space "share space" with settings:
|
||||
| shareWith | sales |
|
||||
| shareType | 8 |
|
||||
| expireDate | |
|
||||
| role | <share-space-role> |
|
||||
Then the HTTP status code should be "200"
|
||||
And the user "Brian" should have a space called "share space" granted to group "sales" with role "<share-space-role>" and expiration date ""
|
||||
Examples:
|
||||
| space-role | share-space-role |
|
||||
| Manager | manager |
|
||||
| Space Editor | editor |
|
||||
| Space Viewer | viewer |
|
||||
|
||||
|
||||
Scenario Outline: check the end of expiration of a space in user share
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <space-role> |
|
||||
| expirationDateTime | 2042-03-25T23:59:59.000Z |
|
||||
When user "Alice" expires the user share of space "share space" for user "Brian"
|
||||
Then the HTTP status code should be "200"
|
||||
And the user "Brian" should not have a space called "share space"
|
||||
Examples:
|
||||
| space-role |
|
||||
| Manager |
|
||||
| Space Editor |
|
||||
| Space Viewer |
|
||||
|
||||
|
||||
Scenario Outline: check the end of expiration of a space in group share
|
||||
Given group "sales" has been created
|
||||
And the administrator has added a user "Brian" to the group "sales" using the Graph API
|
||||
And user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | sales |
|
||||
| shareType | group |
|
||||
| permissionsRole | <space-role> |
|
||||
| expirationDateTime | 2042-03-25T23:59:59.000Z |
|
||||
When user "Alice" expires the group share of space "share space" for group "sales"
|
||||
Then the HTTP status code should be "200"
|
||||
And the user "Brian" should not have a space called "share space"
|
||||
Examples:
|
||||
| space-role |
|
||||
| Manager |
|
||||
| Space Editor |
|
||||
| Space Viewer |
|
||||
|
||||
|
||||
Scenario Outline: user cannot share the personal space to an other user
|
||||
Given the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
|
||||
When user "Brian" shares a space "Brian Murphy" with settings:
|
||||
| shareWith | Bob |
|
||||
| role | viewer |
|
||||
Then the HTTP status code should be "400"
|
||||
And the OCS status message should be "can not add members to personal spaces"
|
||||
And the user "Bob" should not have a space called "Brian Murphy"
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| Admin |
|
||||
| User |
|
||||
|
||||
|
||||
Scenario: user cannot share the personal space to a group
|
||||
Given group "sales" has been created
|
||||
And the administrator has added a user "Brian" to the group "sales" using the Graph API
|
||||
When user "Alice" shares a space "Alice Hansen" with settings:
|
||||
| shareWith | sales |
|
||||
| shareType | 8 |
|
||||
| role | manager |
|
||||
Then the HTTP status code should be "400"
|
||||
And the OCS status message should be "can not add members to personal spaces"
|
||||
And the user "Brian" should not have a space called "Alice Hansen"
|
||||
|
||||
|
||||
Scenario: last space manager cannot change his role
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Manager |
|
||||
When user "Alice" updates the space "share space" with settings:
|
||||
| shareWith | Alice |
|
||||
| role | editor |
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "200"
|
||||
When user "Brian" updates the space "share space" with settings:
|
||||
| shareWith | Brian |
|
||||
| role | editor |
|
||||
Then the HTTP status code should be "403"
|
||||
And the OCS status code should be "403"
|
||||
And the user "Alice" should have a space called "share space" granted to "Brian" with role "manager"
|
||||
And the user "Alice" should have a space called "share space" granted to "Alice" with role "editor"
|
||||
@@ -0,0 +1,306 @@
|
||||
Feature: Share spaces via link
|
||||
As the manager of a space
|
||||
I want to be able to share a space via public link
|
||||
So that an anonymous user can have access to certain resources
|
||||
|
||||
Background:
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
And using spaces DAV path
|
||||
And the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
|
||||
And user "Alice" has created a space "share space" with the default quota using the Graph API
|
||||
And user "Alice" has uploaded a file inside space "share space" with content "some content" to "test.txt"
|
||||
|
||||
@issue-9724 @issue-10331
|
||||
Scenario Outline: manager can share a space to public via link with different permissions
|
||||
When user "Alice" creates a public link share of the space "share space" with settings:
|
||||
| permissions | <permissions> |
|
||||
| password | <password> |
|
||||
| name | <link-name> |
|
||||
| expireDate | <expire-date> |
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "200"
|
||||
And the OCS status message should be "OK"
|
||||
And the fields of the last response to user "Alice" should include
|
||||
| item_type | folder |
|
||||
| mimetype | httpd/unix-directory |
|
||||
| file_target | / |
|
||||
| path | / |
|
||||
| permissions | <expected-permissions> |
|
||||
| share_type | public_link |
|
||||
| displayname_owner | %displayname% |
|
||||
| uid_owner | %username% |
|
||||
| name | <link-name> |
|
||||
When the public downloads file "/test.txt" from inside the last public link shared folder with password "<password>" using the public WebDAV API
|
||||
Then the HTTP status code should be "200"
|
||||
And the downloaded content should be "some content"
|
||||
But the public should not be able to download file "/test.txt" from inside the last public link shared folder using the public WebDAV API with password "wrong pass"
|
||||
Examples:
|
||||
| permissions | expected-permissions | password | link-name | expire-date |
|
||||
| 1 | read | %public% | link | 2042-03-25T23:59:59+0100 |
|
||||
| 5 | read,create | %public% | | 2042-03-25T23:59:59+0100 |
|
||||
| 15 | read,update,create,delete | %public% | link | |
|
||||
|
||||
|
||||
Scenario: manager can create internal link without password
|
||||
When user "Alice" creates a public link share of the space "share space" with settings:
|
||||
| permissions | 0 |
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "200"
|
||||
And the OCS status message should be "OK"
|
||||
And the fields of the last response to user "Alice" should include
|
||||
| permissions | 0 |
|
||||
| share_type | public_link |
|
||||
|
||||
@issue-10331
|
||||
Scenario: uploader should be able to upload a file
|
||||
When user "Alice" creates a public link share of the space "share space" with settings:
|
||||
| permissions | 4 |
|
||||
| password | %public% |
|
||||
| name | forUpload |
|
||||
| expireDate | 2042-03-25T23:59:59+0100 |
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "200"
|
||||
And the OCS status message should be "OK"
|
||||
And the fields of the last response to user "Alice" should include
|
||||
| item_type | folder |
|
||||
| mimetype | httpd/unix-directory |
|
||||
| file_target | / |
|
||||
| path | / |
|
||||
| permissions | create |
|
||||
| share_type | public_link |
|
||||
| displayname_owner | %displayname% |
|
||||
| uid_owner | %username% |
|
||||
| name | forUpload |
|
||||
And the public should be able to upload file "lorem.txt" into the last public link shared folder using the public WebDAV API with password "%public%"
|
||||
And for user "Alice" the space "share space" should contain these entries:
|
||||
| lorem.txt |
|
||||
|
||||
|
||||
Scenario Outline: user without manager role cannot share a space to public via link
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <space-role> |
|
||||
When user "Brian" creates a public link share of the space "share space" with settings:
|
||||
| permissions | 1 |
|
||||
Then the HTTP status code should be "403"
|
||||
And the OCS status code should be "403"
|
||||
And the OCS status message should be "No share permission"
|
||||
And for user "Alice" the space "share space" should not contain the last created public link
|
||||
Examples:
|
||||
| space-role |
|
||||
| Space Viewer |
|
||||
| Space Editor |
|
||||
|
||||
|
||||
Scenario: user with manager role can share a space to public via link
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Manager |
|
||||
When user "Brian" creates a public link share of the space "share space" with settings:
|
||||
| permissions | 1 |
|
||||
| password | %public% |
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "200"
|
||||
And for user "Alice" the space "share space" should contain the last created public link
|
||||
|
||||
|
||||
Scenario: user cannot share a disabled space to public via link
|
||||
Given user "Alice" has disabled a space "share space"
|
||||
When user "Alice" creates a public link share of the space "share space" with settings:
|
||||
| permissions | 1 |
|
||||
| password | %public% |
|
||||
Then the HTTP status code should be "404"
|
||||
And the OCS status code should be "404"
|
||||
And the OCS status message should be "Wrong path, file/folder doesn't exist"
|
||||
And for user "Alice" the space "share space" should not contain the last created public link
|
||||
|
||||
|
||||
Scenario: user cannot create a public link from the personal space
|
||||
When user "Alice" creates a public link share of the space "Alice Hansen" with settings:
|
||||
| permissions | 1 |
|
||||
| password | %public% |
|
||||
Then the HTTP status code should be "400"
|
||||
And the OCS status message should be "Can not share space root"
|
||||
And for user "Alice" the space "Alice Hansen" should not contain the last created public link
|
||||
|
||||
|
||||
Scenario Outline: space admin removes password of a public link share of a space (read/invite permission)
|
||||
Given using OCS API version "<ocs-api-version>"
|
||||
And using SharingNG
|
||||
And user "Alice" has created the following space link share:
|
||||
| space | share space |
|
||||
| permissionsRole | view |
|
||||
| password | %public% |
|
||||
When user "Alice" updates the last public link share using the sharing API with
|
||||
| permissions | 1 |
|
||||
| password | |
|
||||
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 "OK"
|
||||
Examples:
|
||||
| ocs-api-version | ocs-status-code |
|
||||
| 1 | 100 |
|
||||
| 2 | 200 |
|
||||
|
||||
|
||||
Scenario Outline: space admin tries to remove password of a public link share of a space (various permission)
|
||||
Given using OCS API version "<ocs-api-version>"
|
||||
And using SharingNG
|
||||
And user "Alice" has created the following space link share:
|
||||
| space | share space |
|
||||
| permissionsRole | <permissions-role> |
|
||||
| password | %public% |
|
||||
When user "Alice" updates the last public link share using the sharing API with
|
||||
| permissions | <permissions> |
|
||||
| password | |
|
||||
Then the HTTP status code should be "<http-status-code>"
|
||||
And the OCS status code should be "400"
|
||||
And the OCS status message should be "missing required password"
|
||||
Examples:
|
||||
| ocs-api-version | permissions | http-status-code | permissions-role |
|
||||
| 1 | 5 | 200 | upload |
|
||||
| 2 | 5 | 400 | upload |
|
||||
| 1 | 15 | 200 | edit |
|
||||
| 2 | 15 | 400 | edit |
|
||||
| 1 | 4 | 200 | createOnly |
|
||||
| 2 | 4 | 400 | createOnly |
|
||||
|
||||
|
||||
Scenario Outline: space admin removes password of a public link share of a space (invite permission)
|
||||
Given using OCS API version "<ocs-api-version>"
|
||||
And using SharingNG
|
||||
And user "Alice" has created the following space link share:
|
||||
| space | share space |
|
||||
| permissionsRole | view |
|
||||
| password | %public% |
|
||||
When user "Alice" updates the last public link share using the sharing API with
|
||||
| permissions | 0 |
|
||||
| password | |
|
||||
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 "OK"
|
||||
Examples:
|
||||
| ocs-api-version | ocs-status-code |
|
||||
| 1 | 100 |
|
||||
| 2 | 200 |
|
||||
|
||||
|
||||
Scenario Outline: space manager tries to remove password of a public link share of a space (read permission)
|
||||
Given using OCS API version "<ocs-api-version>"
|
||||
And using SharingNG
|
||||
And user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Manager |
|
||||
And user "Brian" has created the following space link share:
|
||||
| space | share space |
|
||||
| permissionsRole | view |
|
||||
| password | %public% |
|
||||
When user "Brian" updates the last public link share using the sharing API with
|
||||
| permissions | 1 |
|
||||
| password | |
|
||||
Then the HTTP status code should be "<http-status-code>"
|
||||
And the OCS status code should be "104"
|
||||
And the OCS status message should be "user is not allowed to delete the password from the public link"
|
||||
Examples:
|
||||
| ocs-api-version | http-status-code |
|
||||
| 1 | 200 |
|
||||
| 2 | 403 |
|
||||
|
||||
|
||||
Scenario Outline: space manager tries to remove password of a public link share of a space (various permission)
|
||||
Given using OCS API version "<ocs-api-version>"
|
||||
And using SharingNG
|
||||
And user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Manager |
|
||||
And user "Brian" has created the following space link share:
|
||||
| space | share space |
|
||||
| permissionsRole | <permissions-role> |
|
||||
| password | %public% |
|
||||
When user "Brian" updates the last public link share using the sharing API with
|
||||
| permissions | <permissions> |
|
||||
| password | |
|
||||
Then the HTTP status code should be "<http-status-code>"
|
||||
And the OCS status code should be "400"
|
||||
And the OCS status message should be "missing required password"
|
||||
Examples:
|
||||
| ocs-api-version | permissions | http-status-code | permissions-role |
|
||||
| 1 | 5 | 200 | upload |
|
||||
| 2 | 5 | 400 | upload |
|
||||
| 1 | 15 | 200 | edit |
|
||||
| 2 | 15 | 400 | edit |
|
||||
| 1 | 4 | 200 | createOnly |
|
||||
| 2 | 4 | 400 | createOnly |
|
||||
|
||||
|
||||
Scenario Outline: space manager removes password of a public link share of a space (invite permission)
|
||||
Given using OCS API version "<ocs-api-version>"
|
||||
And using SharingNG
|
||||
And user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Manager |
|
||||
And user "Brian" has created the following space link share:
|
||||
| space | share space |
|
||||
| permissionsRole | view |
|
||||
| password | %public% |
|
||||
When user "Brian" updates the last public link share using the sharing API with
|
||||
| permissions | 0 |
|
||||
| password | |
|
||||
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 "OK"
|
||||
Examples:
|
||||
| ocs-api-version | ocs-status-code |
|
||||
| 1 | 100 |
|
||||
| 2 | 200 |
|
||||
|
||||
|
||||
Scenario Outline: space member tries to remove the password of a public link share of a space
|
||||
Given using OCS API version "<ocs-api-version>"
|
||||
And using SharingNG
|
||||
And user "Alice" has sent the following space share invitation:
|
||||
| space | share space |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <space-role> |
|
||||
And user "Alice" has created the following space link share:
|
||||
| space | share space |
|
||||
| permissionsRole | <permissions-role> |
|
||||
| password | %public% |
|
||||
When user "Brian" updates the last public link share using the sharing API with
|
||||
| permissions | <permissions> |
|
||||
| password | |
|
||||
Then the HTTP status code should be "<http-status-code>"
|
||||
And the OCS status code should be "997"
|
||||
And the OCS status message should be "missing permissions to update share"
|
||||
Examples:
|
||||
| ocs-api-version | http-status-code | space-role | permissions | permissions-role |
|
||||
| 1 | 200 | Space Viewer | 1 | view |
|
||||
| 2 | 401 | Space Viewer | 1 | view |
|
||||
| 1 | 200 | Space Viewer | 5 | upload |
|
||||
| 2 | 401 | Space Viewer | 5 | upload |
|
||||
| 1 | 200 | Space Viewer | 15 | edit |
|
||||
| 2 | 401 | Space Viewer | 15 | edit |
|
||||
| 1 | 200 | Space Viewer | 4 | createOnly |
|
||||
| 2 | 401 | Space Viewer | 4 | createOnly |
|
||||
| 1 | 200 | Space Editor | 1 | view |
|
||||
| 2 | 401 | Space Editor | 1 | view |
|
||||
| 1 | 200 | Space Editor | 5 | upload |
|
||||
| 2 | 401 | Space Editor | 5 | upload |
|
||||
| 1 | 200 | Space Editor | 15 | edit |
|
||||
| 2 | 401 | Space Editor | 15 | edit |
|
||||
| 1 | 200 | Space Editor | 4 | createOnly |
|
||||
| 2 | 401 | Space Editor | 4 | createOnly |
|
||||
@@ -0,0 +1,198 @@
|
||||
Feature: Share a file or folder that is inside a space
|
||||
As a user with manager space role
|
||||
I want to be able to share the data inside the space
|
||||
So that other users can have access to it
|
||||
|
||||
Background:
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
| Bob |
|
||||
And using spaces DAV path
|
||||
And the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
|
||||
And user "Alice" has created a space "share sub-item" with the default quota using the Graph API
|
||||
And user "Alice" has created a folder "folder" in space "share sub-item"
|
||||
And user "Alice" has uploaded a file inside space "share sub-item" with content "some content" to "file.txt"
|
||||
And using new DAV path
|
||||
|
||||
|
||||
Scenario Outline: manager of the space can share an entity inside project space to another user with role
|
||||
When user "Alice" creates a share inside of space "share sub-item" with settings:
|
||||
| path | <resource> |
|
||||
| shareWith | Brian |
|
||||
| role | <space-role> |
|
||||
| expireDate | <expire-date> |
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "200"
|
||||
And the OCS status message should be "OK"
|
||||
And as "Brian" <resource-type> "Shares/<resource>" should exist
|
||||
And as user "Brian" the last share should include the following properties:
|
||||
| expiration | <expiration> |
|
||||
Examples:
|
||||
| resource | resource-type | space-role | expire-date | expiration |
|
||||
| folder | folder | viewer | | |
|
||||
| folder | folder | editor | 2042-03-25T23:59:59+0100 | 2042-03-25 |
|
||||
| file.txt | file | viewer | | |
|
||||
| file.txt | file | editor | 2042-03-25T23:59:59+0100 | 2042-03-25 |
|
||||
|
||||
|
||||
Scenario Outline: user participant of the project space with manager role can share an entity to another user
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | share sub-item |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Manager |
|
||||
When user "Brian" creates a share inside of space "share sub-item" with settings:
|
||||
| path | <resource> |
|
||||
| shareWith | Bob |
|
||||
| role | <space-role> |
|
||||
| expireDate | <expire-date> |
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "200"
|
||||
And the OCS status message should be "OK"
|
||||
And as "Bob" <resource-type> "Shares/<resource>" should exist
|
||||
And as user "Brian" the last share should include the following properties:
|
||||
| expiration | <expiration> |
|
||||
Examples:
|
||||
| resource | resource-type | space-role | expire-date | expiration |
|
||||
| folder | folder | viewer | 2042-03-25T23:59:59+0100 | 2042-03-25 |
|
||||
| folder | folder | editor | | |
|
||||
| file.txt | file | viewer | 2042-03-25T23:59:59+0100 | 2042-03-25 |
|
||||
| file.txt | file | editor | | |
|
||||
|
||||
|
||||
Scenario Outline: user participant of the project space without space manager role cannot share an entity to another user
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | share sub-item |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <space-role> |
|
||||
When user "Brian" creates a share inside of space "share sub-item" with settings:
|
||||
| path | <resource> |
|
||||
| shareWith | Bob |
|
||||
| role | editor |
|
||||
Then the HTTP status code should be "403"
|
||||
And the OCS status code should be "403"
|
||||
And the OCS status message should be "No share permission"
|
||||
Examples:
|
||||
| resource | space-role |
|
||||
| folder | Space Editor |
|
||||
| file.txt | Space Editor |
|
||||
| file.txt | Space Viewer |
|
||||
| folder | Space Viewer |
|
||||
|
||||
|
||||
Scenario Outline: user participant of the project space can see the created resources share
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | share sub-item |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <space-role> |
|
||||
When user "Alice" creates a share inside of space "share sub-item" with settings:
|
||||
| path | file.txt |
|
||||
| shareWith | Bob |
|
||||
| role | editor |
|
||||
Then for user "Alice" the space "share sub-item" should contain the last created share of the file "file.txt"
|
||||
And for user "Brian" the space "share sub-item" should contain the last created share of the file "file.txt"
|
||||
Examples:
|
||||
| space-role |
|
||||
| Space Editor |
|
||||
| Space Viewer |
|
||||
| Manager |
|
||||
|
||||
|
||||
Scenario: user shares the folder to the group
|
||||
Given group "sales" has been created
|
||||
And the administrator has added a user "Brian" to the group "sales" using the Graph API
|
||||
When user "Alice" creates a share inside of space "share sub-item" with settings:
|
||||
| path | folder |
|
||||
| shareWith | sales |
|
||||
| shareType | 1 |
|
||||
| role | viewer |
|
||||
| expireDate | 2042-01-01T23:59:59+0100 |
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "200"
|
||||
And the OCS status message should be "OK"
|
||||
And as "Brian" folder "Shares/folder" should exist
|
||||
And as user "Brian" the last share should include the following properties:
|
||||
| expiration | 2042-01-01 |
|
||||
|
||||
|
||||
Scenario: user changes the expiration date
|
||||
Given using SharingNG
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | folder |
|
||||
| space | share sub-item |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Viewer |
|
||||
| expirationDateTime | 2042-01-01T23:59:59.000Z |
|
||||
When user "Alice" changes the last share with settings:
|
||||
| expireDate | 2044-01-01T23:59:59.999+01:00 |
|
||||
| role | viewer |
|
||||
Then the HTTP status code should be "200"
|
||||
And as user "Brian" the last share should include the following properties:
|
||||
| expiration | 2044-01-01 |
|
||||
|
||||
|
||||
Scenario: user deletes the expiration date
|
||||
Given using SharingNG
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | folder |
|
||||
| space | share sub-item |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Viewer |
|
||||
| expirationDateTime | 2042-01-01T23:59:59.000Z |
|
||||
When user "Alice" changes the last share with settings:
|
||||
| expireDate | |
|
||||
| role | viewer |
|
||||
Then the HTTP status code should be "200"
|
||||
And as user "Brian" the last share should include the following properties:
|
||||
| expiration | |
|
||||
|
||||
@issue-8747
|
||||
Scenario: user cannot delete share role
|
||||
Given using OCS API version "<ocs_api_version>"
|
||||
And using SharingNG
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | folder |
|
||||
| space | share sub-item |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Viewer |
|
||||
| expirationDateTime | 2042-01-01T23:59:59.000Z |
|
||||
When user "Alice" changes the last share with settings:
|
||||
| role | |
|
||||
Then the HTTP status code should be "400"
|
||||
|
||||
|
||||
Scenario: check the end of expiration date in user share
|
||||
Given using SharingNG
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | folder |
|
||||
| space | share sub-item |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Viewer |
|
||||
| expirationDateTime | 2042-01-01T23:59:59.000Z |
|
||||
When user "Alice" expires the last share of resource "folder" inside of the space "share sub-item"
|
||||
Then the HTTP status code should be "200"
|
||||
And as "Brian" folder "Shares/folder" should not exist
|
||||
|
||||
@issue-5823
|
||||
Scenario: check the end of expiration date in group share
|
||||
Given group "sales" has been created
|
||||
And using SharingNG
|
||||
And the administrator has added a user "Brian" to the group "sales" using the Graph API
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | folder |
|
||||
| space | share sub-item |
|
||||
| sharee | sales |
|
||||
| shareType | group |
|
||||
| permissionsRole | Viewer |
|
||||
| expirationDateTime | 2042-01-01T23:59:59.000Z |
|
||||
When user "Alice" expires the last share of resource "folder" inside of the space "share sub-item"
|
||||
Then the HTTP status code should be "200"
|
||||
And as "Brian" folder "Shares/folder" should not exist
|
||||
+178
@@ -0,0 +1,178 @@
|
||||
Feature: Share a file or folder that is inside a space via public link
|
||||
As a user with manager space role
|
||||
I want to be able to share the data inside the space via public link
|
||||
So that an anonymous user can have access to certain resources
|
||||
|
||||
folder permissions:
|
||||
| role | permissions |
|
||||
| internal | 0 |
|
||||
| viewer | 1 |
|
||||
| uploader | 4 |
|
||||
| contributor | 5 |
|
||||
| editor | 15 |
|
||||
|
||||
file permissions:
|
||||
| role | permissions |
|
||||
| internal | 0 |
|
||||
| viewer | 1 |
|
||||
| editor | 3 |
|
||||
|
||||
Background:
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
And using spaces DAV path
|
||||
And the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
|
||||
And user "Alice" has created a space "share sub-item" with the default quota using the Graph API
|
||||
And user "Alice" has created a folder "folder" in space "share sub-item"
|
||||
And user "Alice" has uploaded a file inside space "share sub-item" with content "some content" to "folder/file.txt"
|
||||
|
||||
@issue-5139
|
||||
Scenario Outline: manager of the space can share an entity inside project space via public link
|
||||
When user "Alice" creates a public link share inside of space "share sub-item" with settings:
|
||||
| path | <resource> |
|
||||
| shareType | 3 |
|
||||
| permissions | <permissions> |
|
||||
| password | <password> |
|
||||
| name | <link-name> |
|
||||
| expireDate | <expire-date> |
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "200"
|
||||
And the OCS status message should be "OK"
|
||||
And the fields of the last response to user "Alice" and space "share sub-item" should include
|
||||
| item_type | <resource-type> |
|
||||
| mimetype | <mime-type> |
|
||||
| file_target | <file-target> |
|
||||
| path | /<resource> |
|
||||
| permissions | <permissions> |
|
||||
| share_type | public_link |
|
||||
| displayname_owner | %displayname% |
|
||||
| name | <link-name> |
|
||||
| uid_file_owner | %space_id% |
|
||||
| space_id | %space_id% |
|
||||
Examples:
|
||||
| resource | file-target | permissions | password | link-name | expire-date | resource-type | mime-type |
|
||||
| folder | /folder | 0 | | link | | folder | httpd/unix-directory |
|
||||
| folder | /folder | 1 | %public% | link | 2042-03-25T23:59:59+0100 | folder | httpd/unix-directory |
|
||||
| folder | /folder | 4 | %public% | | | folder | httpd/unix-directory |
|
||||
| folder | /folder | 5 | %public% | | 2042-03-25T23:59:59+0100 | folder | httpd/unix-directory |
|
||||
| folder | /folder | 15 | %public% | link | | folder | httpd/unix-directory |
|
||||
| folder/file.txt | /file.txt | 0 | | link | 2042-03-25T23:59:59+0100 | file | text/plain |
|
||||
| folder/file.txt | /file.txt | 1 | %public% | link | 2042-03-25T23:59:59+0100 | file | text/plain |
|
||||
| folder/file.txt | /file.txt | 3 | %public% | link | 2042-03-25T23:59:59+0100 | file | text/plain |
|
||||
|
||||
@issue-5139
|
||||
Scenario Outline: user participant of the project space with space manager role can share an entity inside project space via public link
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | share sub-item |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Manager |
|
||||
When user "Brian" creates a public link share inside of space "share sub-item" with settings:
|
||||
| path | <resource> |
|
||||
| shareType | 3 |
|
||||
| permissions | 1 |
|
||||
| password | %public% |
|
||||
| name | public link |
|
||||
| expireDate | 2042-03-25T23:59:59+0100 |
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "200"
|
||||
And the OCS status message should be "OK"
|
||||
And the fields of the last response to user "Brian" and space "share sub-item" should include
|
||||
| item_type | <resource-type> |
|
||||
| mimetype | <mime-type> |
|
||||
| file_target | <file-target> |
|
||||
| path | /<resource> |
|
||||
| share_type | public_link |
|
||||
| displayname_owner | %displayname% |
|
||||
| name | public link |
|
||||
| uid_file_owner | %space_id% |
|
||||
| space_id | %space_id% |
|
||||
Examples:
|
||||
| resource | file-target | resource-type | mime-type |
|
||||
| folder | /folder | folder | httpd/unix-directory |
|
||||
| folder/file.txt | /file.txt | file | text/plain |
|
||||
|
||||
|
||||
Scenario Outline: user participant of the project space without space manager role cannot share an entity inside project space via public link
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | share sub-item |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <space-role> |
|
||||
When user "Brian" creates a public link share inside of space "share sub-item" with settings:
|
||||
| path | <resource> |
|
||||
| shareType | 3 |
|
||||
| permissions | 1 |
|
||||
| password | %public% |
|
||||
| name | public link |
|
||||
| expireDate | 2042-03-25T23:59:59+0100 |
|
||||
Then the HTTP status code should be "403"
|
||||
And the OCS status code should be "403"
|
||||
And the OCS status message should be "No share permission"
|
||||
Examples:
|
||||
| resource | space-role |
|
||||
| folder | Space Editor |
|
||||
| folder | Space Viewer |
|
||||
| folder/file.txt | Space Editor |
|
||||
| folder/file.txt | Space Viewer |
|
||||
|
||||
@issue-9724 @issue-10331
|
||||
Scenario Outline: user creates a new public link share of a file inside the personal space with edit permissions
|
||||
Given using OCS API version "<ocs-api-version>"
|
||||
And user "Alice" has uploaded file with content "Random data" to "/file.txt"
|
||||
When user "Alice" creates a public link share using the sharing API with settings
|
||||
| path | file.txt |
|
||||
| permissions | read,update |
|
||||
| password | %public% |
|
||||
Then the OCS status code should be "<ocs-status-code>"
|
||||
And the HTTP status code should be "200"
|
||||
And the fields of the last response to user "Alice" should include
|
||||
| item_type | file |
|
||||
| mimetype | text/plain |
|
||||
| file_target | /file.txt |
|
||||
| path | /file.txt |
|
||||
| permissions | read,update |
|
||||
| share_type | public_link |
|
||||
| displayname_file_owner | %displayname% |
|
||||
| displayname_owner | %displayname% |
|
||||
| uid_file_owner | %username% |
|
||||
| uid_owner | %username% |
|
||||
And the public should be able to download the last publicly shared file using the public WebDAV API with password "%public%" and the content should be "Random data"
|
||||
And the public upload to the last publicly shared file using the public WebDAV API with password "%public%" should pass with HTTP status code "204"
|
||||
Examples:
|
||||
| ocs-api-version | ocs-status-code |
|
||||
| 1 | 100 |
|
||||
| 2 | 200 |
|
||||
|
||||
@issue-5139
|
||||
Scenario Outline: user participant of the project space can see the created public resources link
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | share sub-item |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <space-role> |
|
||||
When user "Alice" creates a public link share inside of space "share sub-item" with settings:
|
||||
| path | folder/file.txt |
|
||||
| shareType | 3 |
|
||||
| permissions | 1 |
|
||||
| password | %public% |
|
||||
Then the fields of the last response to user "Alice" and space "share sub-item" should include
|
||||
| item_type | file |
|
||||
| mimetype | text/plain |
|
||||
| file_target | /file.txt |
|
||||
| path | /folder/file.txt |
|
||||
| permissions | 1 |
|
||||
| share_type | public_link |
|
||||
| displayname_file_owner | |
|
||||
| displayname_owner | %displayname% |
|
||||
| uid_owner | %username% |
|
||||
| uid_file_owner | %space_id% |
|
||||
| space_id | %space_id% |
|
||||
And for user "Brian" the space "share sub-item" should contain the last created public link of the file "folder/file.txt"
|
||||
Examples:
|
||||
| space-role |
|
||||
| Space Editor |
|
||||
| Space Viewer |
|
||||
| Manager |
|
||||
@@ -0,0 +1,404 @@
|
||||
Feature: upload resources on share using TUS protocol
|
||||
As a user
|
||||
I want to be able to upload files
|
||||
So that I can store and share files between multiple client systems
|
||||
|
||||
Background:
|
||||
Given using spaces DAV path
|
||||
And these users have been created with default attributes:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
|
||||
|
||||
Scenario: upload file with mtime to a received share
|
||||
Given user "Alice" has created folder "/toShare"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | toShare |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "toShare" synced
|
||||
When user "Brian" uploads a file "filesForUpload/textfile.txt" to "toShare/file.txt" with mtime "Thu, 08 Aug 2012 04:18:13 GMT" via TUS inside of the space "Shares" using the WebDAV API
|
||||
Then for user "Brian" folder "toShare" of the space "Shares" should contain these entries:
|
||||
| file.txt |
|
||||
And as "Brian" the mtime of the file "/toShare/file.txt" in space "Shares" should be "Thu, 08 Aug 2012 04:18:13 GMT"
|
||||
And as "Alice" the mtime of the file "/toShare/file.txt" in space "Personal" should be "Thu, 08 Aug 2012 04:18:13 GMT"
|
||||
|
||||
|
||||
Scenario: upload file with mtime to a sent share
|
||||
Given user "Alice" has created folder "/toShare"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | toShare |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "toShare" synced
|
||||
When user "Alice" uploads a file "filesForUpload/textfile.txt" to "toShare/file.txt" with mtime "Thu, 08 Aug 2012 04:18:13 GMT" via TUS inside of the space "Personal" using the WebDAV API
|
||||
Then for user "Alice" folder "toShare" of the space "Personal" should contain these entries:
|
||||
| file.txt |
|
||||
And as "Alice" the mtime of the file "/toShare/file.txt" in space "Personal" should be "Thu, 08 Aug 2012 04:18:13 GMT"
|
||||
And as "Brian" the mtime of the file "/toShare/file.txt" in space "Shares" should be "Thu, 08 Aug 2012 04:18:13 GMT"
|
||||
|
||||
|
||||
Scenario: overwriting a file with mtime in a received share
|
||||
Given user "Alice" has created folder "/toShare"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | toShare |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "toShare" synced
|
||||
And user "Alice" has uploaded file with content "uploaded content" to "/toShare/file.txt"
|
||||
When user "Brian" uploads a file "filesForUpload/textfile.txt" to "toShare/file.txt" with mtime "Thu, 08 Aug 2012 04:18:13 GMT" via TUS inside of the space "Shares" using the WebDAV API
|
||||
Then for user "Brian" folder "toShare" of the space "Shares" should contain these entries:
|
||||
| file.txt |
|
||||
And as "Brian" the mtime of the file "/toShare/file.txt" in space "Shares" should be "Thu, 08 Aug 2012 04:18:13 GMT"
|
||||
And as "Alice" the mtime of the file "/toShare/file.txt" in space "Personal" should be "Thu, 08 Aug 2012 04:18:13 GMT"
|
||||
|
||||
|
||||
Scenario: overwriting a file with mtime in a sent share
|
||||
Given user "Alice" has created folder "/toShare"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | toShare |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "toShare" synced
|
||||
And user "Brian" has uploaded a file inside space "Shares" with content "uploaded content" to "toShare/file.txt"
|
||||
When user "Alice" uploads a file "filesForUpload/textfile.txt" to "toShare/file.txt" with mtime "Thu, 08 Aug 2012 04:18:13 GMT" via TUS inside of the space "Personal" using the WebDAV API
|
||||
Then for user "Alice" folder "toShare" of the space "Personal" should contain these entries:
|
||||
| file.txt |
|
||||
And as "Alice" the mtime of the file "/toShare/file.txt" in space "Personal" should be "Thu, 08 Aug 2012 04:18:13 GMT"
|
||||
And as "Brian" the mtime of the file "/toShare/file.txt" in space "Shares" should be "Thu, 08 Aug 2012 04:18:13 GMT"
|
||||
|
||||
|
||||
Scenario: attempt to upload a file into a nonexistent folder within correctly received share
|
||||
Given using OCS API version "1"
|
||||
And user "Alice" has created folder "/toShare"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | toShare |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "toShare" synced
|
||||
When user "Brian" uploads a file with content "uploaded content" to "/toShare/nonExistentFolder/file.txt" via TUS inside of the space "Shares" using the WebDAV API
|
||||
Then for user "Brian" folder "toShare" of the space "Shares" should not contain these entries:
|
||||
| nonExistentFolder |
|
||||
|
||||
|
||||
Scenario: attempt to upload a file into a nonexistent folder within correctly received read only share
|
||||
Given using OCS API version "1"
|
||||
And user "Alice" has created folder "/toShare"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | toShare |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Viewer |
|
||||
And user "Brian" has a share "toShare" synced
|
||||
When user "Brian" uploads a file with content "uploaded content" to "/toShare/nonExistentFolder/file.txt" via TUS inside of the space "Shares" using the WebDAV API
|
||||
Then for user "Brian" folder "toShare" of the space "Shares" should not contain these entries:
|
||||
| nonExistentFolder |
|
||||
|
||||
|
||||
Scenario: uploading a file to a received share folder
|
||||
Given user "Alice" has created folder "/toShare"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | toShare |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "toShare" synced
|
||||
When user "Brian" uploads a file with content "uploaded content" to "/toShare/file.txt" via TUS inside of the space "Shares" using the WebDAV API
|
||||
Then for user "Alice" folder "toShare" of the space "Personal" should contain these entries:
|
||||
| file.txt |
|
||||
And for user "Alice" the content of the file "toShare/file.txt" of the space "Personal" should be "uploaded content"
|
||||
|
||||
|
||||
Scenario: uploading a file to a user read/write share folder
|
||||
Given user "Alice" has created folder "/toShare"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | toShare |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Uploader |
|
||||
And user "Brian" has a share "toShare" synced
|
||||
When user "Brian" uploads a file with content "uploaded content" to "/toShare/file.txt" via TUS inside of the space "Shares" using the WebDAV API
|
||||
Then for user "Alice" folder "toShare" of the space "Personal" should contain these entries:
|
||||
| file.txt |
|
||||
And for user "Alice" the content of the file "toShare/file.txt" of the space "Personal" should be "uploaded content"
|
||||
|
||||
|
||||
Scenario: uploading a file into a group share as a share receiver
|
||||
Given group "grp1" has been created
|
||||
And user "Brian" has been added to group "grp1"
|
||||
And user "Alice" has created folder "/toShare"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | toShare |
|
||||
| space | Personal |
|
||||
| sharee | grp1 |
|
||||
| shareType | group |
|
||||
| permissionsRole | Uploader |
|
||||
And user "Brian" has a share "toShare" synced
|
||||
When user "Brian" uploads a file with content "uploaded content" to "/toShare/file.txt" via TUS inside of the space "Shares" using the WebDAV API
|
||||
Then for user "Alice" folder "toShare" of the space "Personal" should contain these entries:
|
||||
| file.txt |
|
||||
And for user "Alice" the content of the file "toShare/file.txt" of the space "Personal" should be "uploaded content"
|
||||
|
||||
|
||||
Scenario: overwrite file to a received share folder
|
||||
Given user "Alice" has created folder "/toShare"
|
||||
And user "Alice" has uploaded file with content "original content" to "/toShare/file.txt"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | toShare |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "toShare" synced
|
||||
When user "Brian" uploads a file with content "overwritten content" to "/toShare/file.txt" via TUS inside of the space "Shares" using the WebDAV API
|
||||
Then for user "Alice" folder "toShare" of the space "Personal" should contain these entries:
|
||||
| file.txt |
|
||||
And for user "Alice" the content of the file "toShare/file.txt" of the space "Personal" should be "overwritten content"
|
||||
|
||||
|
||||
Scenario: attempt to upload a file into a folder within correctly received read only share
|
||||
Given user "Alice" has created folder "/toShare"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | toShare |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Viewer |
|
||||
And user "Brian" has a share "toShare" synced
|
||||
When user "Brian" uploads a file with content "uploaded content" to "/toShare/file.txt" via TUS inside of the space "Shares" using the WebDAV API
|
||||
Then for user "Brian" folder "toShare" of the space "Shares" should not contain these entries:
|
||||
| file.txt |
|
||||
|
||||
|
||||
Scenario: upload a file to shared folder with checksum should return the checksum in the propfind for sharee
|
||||
Given user "Alice" has created folder "/FOLDER"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | FOLDER |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "FOLDER" synced
|
||||
And user "Alice" has created a new TUS resource in the space "Personal" with the following headers:
|
||||
| Upload-Length | 5 |
|
||||
# L0ZPTERFUi90ZXh0RmlsZS50eHQ= is the base64 encode of /FOLDER/textFile.txt
|
||||
| Upload-Metadata | filename L0ZPTERFUi90ZXh0RmlsZS50eHQ= |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
And user "Alice" has uploaded file with checksum "SHA1 8cb2237d0679ca88db6464eac60da96345513964" to the last created TUS Location with offset "0" and content "12345" via TUS inside of the space "Personal" using the WebDAV API
|
||||
When user "Brian" requests the checksum of file "/FOLDER/textFile.txt" in space "Shares" via propfind using the WebDAV API
|
||||
Then the HTTP status code should be "207"
|
||||
And the webdav checksum should match "SHA1:8cb2237d0679ca88db6464eac60da96345513964 MD5:827ccb0eea8a706c4c34a16891f84e7b ADLER32:02f80100"
|
||||
|
||||
|
||||
Scenario: upload a file to shared folder with checksum should return the checksum in the download header for sharee
|
||||
Given user "Alice" has created folder "/FOLDER"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | FOLDER |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "FOLDER" synced
|
||||
And user "Alice" has created a new TUS resource in the space "Personal" with the following headers:
|
||||
| Upload-Length | 5 |
|
||||
# L0ZPTERFUi90ZXh0RmlsZS50eHQ= is the base64 encode of /FOLDER/textFile.txt
|
||||
| Upload-Metadata | filename L0ZPTERFUi90ZXh0RmlsZS50eHQ= |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
And user "Alice" has uploaded file with checksum "SHA1 8cb2237d0679ca88db6464eac60da96345513964" to the last created TUS Location with offset "0" and content "12345" via TUS inside of the space "Personal" using the WebDAV API
|
||||
When user "Brian" downloads the file "/FOLDER/textFile.txt" of the space "Shares" using the WebDAV API
|
||||
Then the header checksum should match "SHA1:8cb2237d0679ca88db6464eac60da96345513964"
|
||||
|
||||
|
||||
Scenario: sharer shares a file with correct checksum should return the checksum in the propfind for sharee
|
||||
Given user "Alice" has created a new TUS resource in the space "Personal" with the following headers:
|
||||
| Upload-Length | 5 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
And user "Alice" has uploaded file with checksum "SHA1 8cb2237d0679ca88db6464eac60da96345513964" to the last created TUS Location with offset "0" and content "12345" via TUS inside of the space "Personal" using the WebDAV API
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | textFile.txt |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | File Editor |
|
||||
And user "Brian" has a share "textFile.txt" synced
|
||||
When user "Brian" requests the checksum of file "/textFile.txt" in space "Shares" via propfind using the WebDAV API
|
||||
Then the HTTP status code should be "207"
|
||||
And the webdav checksum should match "SHA1:8cb2237d0679ca88db6464eac60da96345513964 MD5:827ccb0eea8a706c4c34a16891f84e7b ADLER32:02f80100"
|
||||
|
||||
|
||||
Scenario: sharer shares a file with correct checksum should return the checksum in the download header for sharee
|
||||
Given user "Alice" has created a new TUS resource in the space "Personal" with the following headers:
|
||||
| Upload-Length | 5 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
And user "Alice" has uploaded file with checksum "SHA1 8cb2237d0679ca88db6464eac60da96345513964" to the last created TUS Location with offset "0" and content "12345" via TUS inside of the space "Personal" using the WebDAV API
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | textFile.txt |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | File Editor |
|
||||
And user "Brian" has a share "textFile.txt" synced
|
||||
When user "Brian" downloads the file "/textFile.txt" of the space "Shares" using the WebDAV API
|
||||
Then the header checksum should match "SHA1:8cb2237d0679ca88db6464eac60da96345513964"
|
||||
|
||||
|
||||
Scenario: sharee uploads a file to a received share folder with correct checksum
|
||||
Given user "Alice" has created folder "/FOLDER"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | FOLDER |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "FOLDER" synced
|
||||
When user "Brian" creates a new TUS resource for the space "Shares" with content "" using the WebDAV API with these headers:
|
||||
| Upload-Length | 5 |
|
||||
# L0ZPTERFUi90ZXh0RmlsZS50eHQ= is the base64 encode of /FOLDER/textFile.txt
|
||||
| Upload-Metadata | filename L0ZPTERFUi90ZXh0RmlsZS50eHQ= |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
And user "Brian" uploads file with checksum "MD5 827ccb0eea8a706c4c34a16891f84e7b" to the last created TUS Location with offset "0" and content "12345" via TUS inside of the space "Shares" using the WebDAV API
|
||||
Then for user "Alice" folder "FOLDER" of the space "Personal" should contain these entries:
|
||||
| textFile.txt |
|
||||
And for user "Alice" the content of the file "FOLDER/textFile.txt" of the space "Personal" should be "12345"
|
||||
|
||||
@issue-1755
|
||||
Scenario: sharee uploads a file to a received share folder with wrong checksum should not work
|
||||
Given user "Alice" has created folder "/FOLDER"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | FOLDER |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "FOLDER" synced
|
||||
When user "Brian" creates a new TUS resource for the space "Shares" with content "" using the WebDAV API with these headers:
|
||||
| Upload-Length | 5 |
|
||||
# L0ZPTERFUi90ZXh0RmlsZS50eHQ= is the base64 encode of /FOLDER/textFile.txt
|
||||
| Upload-Metadata | filename L0ZPTERFUi90ZXh0RmlsZS50eHQ= |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
And user "Brian" uploads file with checksum "MD5 827ccb0eea8a706c4c34a16891f84e7b" to the last created TUS Location with offset "0" and content "12346" via TUS inside of the space "Shares" using the WebDAV API
|
||||
Then the HTTP status code should be "460"
|
||||
And for user "Alice" folder "FOLDER" of the space "Personal" should not contain these entries:
|
||||
| textFile.txt |
|
||||
|
||||
@issue-1755
|
||||
Scenario: sharer uploads a file to shared folder with wrong checksum should not work
|
||||
Given user "Alice" has created folder "/FOLDER"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | FOLDER |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "FOLDER" synced
|
||||
And user "Alice" has created a new TUS resource in the space "Personal" with the following headers:
|
||||
| Upload-Length | 16 |
|
||||
# L0ZPTERFUi90ZXh0RmlsZS50eHQ= is the base64 encode of /FOLDER/textFile.txt
|
||||
| Upload-Metadata | filename L0ZPTERFUi90ZXh0RmlsZS50eHQ= |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
When user "Alice" uploads file with checksum "SHA1 8cb2237d0679ca88db6464eac60da96345513964" to the last created TUS Location with offset "0" and content "12346" via TUS inside of the space "Personal" using the WebDAV API
|
||||
Then the HTTP status code should be "460"
|
||||
And for user "Alice" folder "FOLDER" of the space "Personal" should not contain these entries:
|
||||
| textFile.txt |
|
||||
And for user "Brian" folder "FOLDER" of the space "Shares" should not contain these entries:
|
||||
| textFile.txt |
|
||||
|
||||
|
||||
Scenario: sharer uploads a chunked file with correct checksum and share it with sharee should work
|
||||
Given user "Alice" has created a new TUS resource in the space "Personal" with the following headers:
|
||||
| Upload-Length | 10 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
When user "Alice" sends a chunk to the last created TUS Location with offset "0" and data "01234" with checksum "MD5 4100c4d44da9177247e44a5fc1546778" via TUS inside of the space "Personal" using the WebDAV API
|
||||
And user "Alice" sends a chunk to the last created TUS Location with offset "5" and data "56789" with checksum "MD5 099ebea48ea9666a7da2177267983138" via TUS inside of the space "Personal" using the WebDAV API
|
||||
And user "Alice" shares file "textFile.txt" with user "Brian" using the sharing API
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "100"
|
||||
And for user "Brian" the content of the file "/textFile.txt" of the space "Shares" should be "0123456789"
|
||||
|
||||
|
||||
Scenario: sharee uploads a chunked file with correct checksum to a received share folder should work
|
||||
Given user "Alice" has created folder "/FOLDER"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | FOLDER |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "FOLDER" synced
|
||||
And user "Brian" has created a new TUS resource in the space "Shares" with the following headers:
|
||||
| Upload-Length | 10 |
|
||||
# L0ZPTERFUi90ZXh0RmlsZS50eHQ= is the base64 encode of /FOLDER/textFile.txt
|
||||
| Upload-Metadata | filename L0ZPTERFUi90ZXh0RmlsZS50eHQ= |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
When user "Brian" sends a chunk to the last created TUS Location with offset "0" and data "01234" with checksum "MD5 4100c4d44da9177247e44a5fc1546778" via TUS inside of the space "Shares" using the WebDAV API
|
||||
And user "Brian" sends a chunk to the last created TUS Location with offset "5" and data "56789" with checksum "MD5 099ebea48ea9666a7da2177267983138" via TUS inside of the space "Shares" using the WebDAV API
|
||||
Then the HTTP status code should be "204"
|
||||
And for user "Alice" folder "FOLDER" of the space "Personal" should contain these entries:
|
||||
| textFile.txt |
|
||||
And for user "Alice" the content of the file "/FOLDER/textFile.txt" of the space "Personal" should be "0123456789"
|
||||
|
||||
|
||||
Scenario: sharer uploads a file with checksum and as a sharee overwrites the shared file with new data and correct checksum
|
||||
Given user "Alice" has created a new TUS resource in the space "Personal" with the following headers:
|
||||
| Upload-Length | 16 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
And user "Alice" has uploaded file with checksum "SHA1 c1dab0c0864b6ac9bdd3743a1408d679f1acd823" to the last created TUS Location with offset "0" and content "original content" via TUS inside of the space "Personal" using the WebDAV API
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | textFile.txt |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | File Editor |
|
||||
And user "Brian" has a share "textFile.txt" synced
|
||||
When user "Brian" overwrites recently shared file with offset "0" and data "overwritten content" with checksum "SHA1 fe990d2686a0fc86004efc31f5bf2475a45d4905" via TUS inside of the space "Shares" using the WebDAV API with these headers:
|
||||
| Upload-Length | 19 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
Then the HTTP status code should be "204"
|
||||
And for user "Alice" the content of the file "/textFile.txt" of the space "Personal" should be "overwritten content"
|
||||
|
||||
@issue-1755
|
||||
Scenario: sharer uploads a file with checksum and as a sharee overwrites the shared file with new data and invalid checksum
|
||||
Given user "Alice" has created a new TUS resource in the space "Personal" with the following headers:
|
||||
| Upload-Length | 16 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
And user "Alice" has uploaded file with checksum "SHA1 c1dab0c0864b6ac9bdd3743a1408d679f1acd823" to the last created TUS Location with offset "0" and content "original content" via TUS inside of the space "Personal" using the WebDAV API
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | textFile.txt |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | File Editor |
|
||||
And user "Brian" has a share "textFile.txt" synced
|
||||
When user "Brian" overwrites recently shared file with offset "0" and data "overwritten content" with checksum "SHA1 fe990d2686a0fc86004efc31f5bf2475a45d4906" via TUS inside of the space "Shares" using the WebDAV API with these headers:
|
||||
| Upload-Length | 19 |
|
||||
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
|
||||
| Upload-Metadata | filename dGV4dEZpbGUudHh0 |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
Then the HTTP status code should be "460"
|
||||
And for user "Alice" the content of the file "/textFile.txt" of the space "Personal" should be "original content"
|
||||
Reference in New Issue
Block a user