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

Initial QSfera import

Browse Source
This commit is contained in:
Курнат Андрей
2026-06-07 10:20:04 +03:00
commit 2315f25754
16485 changed files with 4826827 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Server/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature
+711
View File
@@ -0,0 +1,711 @@
@skipOnReva @issue-1289 @issue-1328
Feature: accept/decline shares coming from internal users
As a user
I want to have control of which received shares I accept
So that I can keep my file system clean
Background:
Given using OCS API version "1"
And using new DAV path
And these users have been created with default attributes:
| username |
| Alice |
| Brian |
| Carol |
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Carol" has been added to group "grp1"
And user "Alice" has created folder "PARENT"
And user "Alice" has created folder "FOLDER"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt"
And user "Brian" has created folder "PARENT"
And user "Brian" has created folder "FOLDER"
And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt"
@smokeTest @issue-2540
Scenario: share a file & folder with another internal group when auto accept is disabled
Given user "Brian" has disabled auto-accepting
And user "Carol" has disabled auto-accepting
And user "Carol" has created folder "FOLDER"
And user "Carol" has created folder "PARENT"
And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API
And user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And user "Brian" should see the following elements
| /FOLDER |
| /PARENT |
| /textfile0.txt |
But user "Brian" should not see the following elements
| /Shares/PARENT |
| /Shares/PARENT/parent.txt |
| /Shares/textfile0.txt |
And the sharing API should report to user "Brian" that these shares are in the pending state
| path |
| /PARENT/ |
| /textfile0.txt |
And user "Carol" should see the following elements
| /FOLDER |
| /PARENT |
| /textfile0.txt |
But user "Carol" should not see the following elements
| /Shares/PARENT |
| /Shares/PARENT/parent.txt |
| /Shares/textfile0.txt |
And the sharing API should report to user "Carol" that these shares are in the pending state
| path |
| /PARENT/ |
| /textfile0.txt |
@issue-2540
Scenario: share a file & folder with another internal user when auto accept is disabled
Given user "Brian" has disabled auto-accepting
When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API
And user "Alice" shares file "/textfile0.txt" with user "Brian" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And user "Brian" should see the following elements
| /FOLDER |
| /PARENT |
| /textfile0.txt |
But user "Brian" should not see the following elements
| /Shares/PARENT |
| /Shares/PARENT/parent.txt |
| /Shares/textfile0.txt |
And the sharing API should report to user "Brian" that these shares are in the pending state
| path |
| /PARENT/ |
| /textfile0.txt |
@smokeTest @issue-2131
Scenario: accept a pending share
Given user "Brian" has disabled auto-accepting
And user "Alice" has sent the following resource share invitation:
| resource | PARENT |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
And user "Alice" has sent the following resource share invitation:
| resource | textfile0.txt |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | File Editor |
When user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API
And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And the fields of the last response to user "Alice" sharing with user "Brian" should include
| id | A_STRING |
| share_type | user |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| permissions | read,update |
| uid_file_owner | %username% |
| displayname_file_owner | %displayname% |
| state | 0 |
| path | /Shares/textfile0.txt |
| item_type | file |
| mimetype | text/plain |
| storage_id | shared::/Shares/textfile0.txt |
| storage | A_STRING |
| item_source | A_STRING |
| file_source | A_STRING |
| file_target | /Shares/textfile0.txt |
| share_with | %username% |
| share_with_displayname | %displayname% |
| mail_send | 0 |
And user "Brian" should see the following elements
| /FOLDER |
| /PARENT |
| /textfile0.txt |
| /Shares/PARENT |
| /Shares/PARENT/parent.txt |
| /Shares/textfile0.txt |
And the sharing API should report to user "Brian" that these shares are in the accepted state
| path |
| /Shares/PARENT |
| /Shares/textfile0.txt |
Scenario: accept an accepted share
Given user "Alice" has created folder "/shared"
And user "Alice" has sent the following resource share invitation:
| resource | shared |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Viewer |
And user "Brian" has a share "shared" synced
When user "Brian" accepts the already accepted share "/shared" offered by user "Alice" using the sharing API
Then the OCS status code should be "100"
And the HTTP status code should be "200"
And user "Brian" should see the following elements
| /Shares/shared |
And the sharing API should report to user "Brian" that these shares are in the accepted state
| path |
| /Shares/shared/ |
@smokeTest @issue-2540
Scenario: declines a pending share
Given user "Brian" has disabled auto-accepting
And user "Alice" has sent the following resource share invitation:
| resource | PARENT |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Viewer |
And user "Alice" has sent the following resource share invitation:
| resource | textfile0.txt |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Viewer |
When user "Brian" declines share "/PARENT" offered by user "Alice" using the sharing API
And user "Brian" declines share "/textfile0.txt" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And user "Brian" should see the following elements
| /FOLDER |
| /PARENT |
| /textfile0.txt |
But user "Brian" should not see the following elements
| /Shares/PARENT |
| /Shares/PARENT/parent.txt |
| /Shares/textfile0.txt |
And the sharing API should report to user "Brian" that these shares are in the declined state
| path |
| /PARENT/ |
| /textfile0.txt |
@smokeTest @issue-2128 @issue-2540
Scenario: decline an accepted share
Given user "Brian" has disabled auto-accepting
And user "Alice" has sent the following resource share invitation:
| resource | PARENT |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Viewer |
And user "Alice" has sent the following resource share invitation:
| resource | textfile0.txt |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Viewer |
And user "Brian" has accepted share "/PARENT" offered by user "Alice"
And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
When user "Brian" declines share "/Shares/PARENT" offered by user "Alice" using the sharing API
And user "Brian" declines share "/Shares/textfile0.txt" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And user "Brian" should not see the following elements
| /Shares/PARENT |
| /Shares/PARENT/parent.txt |
| /Shares/textfile0.txt |
And the sharing API should report to user "Brian" that these shares are in the declined state
| path |
| /PARENT/ |
| /textfile0.txt |
Scenario Outline: deleting shares in pending state
Given using <dav-path-version> DAV path
And user "Brian" has disabled auto-accepting
And user "Alice" has sent the following resource share invitation:
| resource | PARENT |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
And user "Alice" has sent the following resource share invitation:
| resource | textfile0.txt |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Viewer |
When user "Alice" deletes folder "/PARENT" using the WebDAV API
And user "Alice" deletes file "/textfile0.txt" using the WebDAV API
Then the HTTP status code of responses on all endpoints should be "204"
And the sharing API should report that no shares are shared with user "Brian"
Examples:
| dav-path-version |
| old |
| new |
| spaces |
@issue-2540
Scenario: only one user in a group accepts a share
Given user "Brian" has disabled auto-accepting
And user "Carol" has disabled auto-accepting
And user "Alice" has sent the following resource share invitation:
| resource | PARENT |
| space | Personal |
| sharee | grp1 |
| shareType | group |
| permissionsRole | Viewer |
And user "Alice" has sent the following resource share invitation:
| resource | textfile0.txt |
| space | Personal |
| sharee | grp1 |
| shareType | group |
| permissionsRole | Viewer |
When user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API
And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And user "Carol" should not see the following elements
| /Shares/PARENT |
| /Shares/PARENT/parent.txt |
| /Shares/textfile0.txt |
And the sharing API should report to user "Carol" that these shares are in the pending state
| path |
| /PARENT/ |
| /textfile0.txt |
But user "Brian" should see the following elements
| /Shares/PARENT |
| /Shares/PARENT/parent.txt |
| /Shares/textfile0.txt |
And the sharing API should report to user "Brian" that these shares are in the accepted state
| path |
| /Shares/PARENT/ |
| /Shares/textfile0.txt |
@issue-2131
Scenario: receive two shares with identical names from different users, accept one by one
Given user "Carol" has disabled auto-accepting
And user "Alice" has created folder "/shared"
And user "Alice" has created folder "/shared/Alice"
And user "Brian" has created folder "/shared"
And user "Brian" has created folder "/shared/Brian"
And user "Alice" has sent the following resource share invitation:
| resource | shared |
| space | Personal |
| sharee | Carol |
| shareType | user |
| permissionsRole | Viewer |
And user "Brian" has sent the following resource share invitation:
| resource | shared |
| space | Personal |
| sharee | Carol |
| shareType | user |
| permissionsRole | Viewer |
When user "Carol" accepts share "/shared" offered by user "Brian" using the sharing API
And user "Carol" accepts share "/shared" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And user "Carol" should see the following elements
| /Shares/shared/Brian |
| /Shares/shared (1)/Alice |
And the sharing API should report to user "Carol" that these shares are in the accepted state
| path |
| /Shares/shared/ |
| /Shares/shared (1)/ |
@issue-2540
Scenario: share with a group that you are part of yourself
Given user "Brian" has disabled auto-accepting
When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API
Then the OCS status code should be "100"
And the HTTP status code should be "200"
And the sharing API should report to user "Brian" that these shares are in the pending state
| path |
| /PARENT/ |
And the sharing API should report that no shares are shared with user "Alice"
Scenario: user accepts file that was initially accepted from another user and then declined
Given user "Alice" has uploaded file with content "First file" to "/testfile.txt"
And user "Brian" has uploaded file with content "Second file" to "/testfile.txt"
And user "Alice" has sent the following resource share invitation:
| resource | testfile.txt |
| space | Personal |
| sharee | Carol |
| shareType | user |
| permissionsRole | Viewer |
And user "Carol" has a share "testfile.txt" synced
And user "Carol" has declined share "/Shares/testfile.txt" offered by user "Alice"
And user "Carol" has disabled auto-accepting
And user "Brian" has sent the following resource share invitation:
| resource | testfile.txt |
| space | Personal |
| sharee | Carol |
| shareType | user |
| permissionsRole | Viewer |
When user "Carol" accepts share "/testfile.txt" offered by user "Brian" using the sharing API
Then the HTTP status code should be "200"
And the OCS status code should be "100"
And the sharing API should report to user "Carol" that these shares are in the accepted state
| path |
| /Shares/testfile.txt |
And the content of file "/Shares/testfile.txt" for user "Carol" should be "Second file"
Scenario: user accepts shares received from multiple users with the same name when auto-accept share is disabled
Given user "Alice" has disabled auto-accepting
And user "David" has been created with default attributes
And user "David" has created folder "PARENT"
And user "Brian" has sent the following resource share invitation:
| resource | PARENT |
| space | Personal |
| sharee | Alice |
| shareType | user |
| permissionsRole | Viewer |
And user "Carol" has created folder "PARENT"
And user "Carol" has sent the following resource share invitation:
| resource | PARENT |
| space | Personal |
| sharee | Alice |
| shareType | user |
| permissionsRole | Viewer |
When user "Alice" accepts share "/PARENT" offered by user "Brian" using the sharing API
And user "Alice" accepts share "/PARENT" offered by user "Carol" using the sharing API
And user "Alice" declines share "/Shares/PARENT (1)" offered by user "Carol" using the sharing API
And user "Alice" declines share "/Shares/PARENT" offered by user "Brian" using the sharing API
And user "David" shares folder "/PARENT" with user "Alice" using the sharing API
And user "Alice" accepts share "/PARENT" offered by user "David" using the sharing API
And user "Alice" accepts share "/PARENT" offered by user "Carol" using the sharing API
And user "Alice" accepts share "/PARENT" offered by user "Brian" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And the sharing API should report to user "Alice" that these shares are in the accepted state
| path | uid_owner |
| /Shares/PARENT | David |
| /Shares/PARENT (1) | Carol |
| /Shares/PARENT (2) | Brian |
Scenario: user shares folder with matching folder-name for both user involved in sharing
Given user "Brian" has disabled auto-accepting
And user "Alice" has uploaded file with content "uploaded content" to "/PARENT/abc.txt"
And user "Alice" has uploaded file with content "uploaded content" to "/FOLDER/abc.txt"
When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API
And user "Alice" shares folder "/FOLDER" with user "Brian" using the sharing API
And user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API
And user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And user "Brian" should see the following elements
| /FOLDER |
| /PARENT |
| /Shares/PARENT |
| /Shares/PARENT/abc.txt |
| /Shares/FOLDER |
| /Shares/FOLDER/abc.txt |
And user "Brian" should not see the following elements
| /FOLDER/abc.txt |
| /PARENT/abc.txt |
And the content of file "/Shares/PARENT/abc.txt" for user "Brian" should be "uploaded content"
And the content of file "/Shares/FOLDER/abc.txt" for user "Brian" should be "uploaded content"
Scenario: user shares folder in a group with matching folder-name for every users involved
Given user "Brian" has disabled auto-accepting
And user "Carol" has disabled auto-accepting
And user "Alice" has uploaded file with content "uploaded content" to "/PARENT/abc.txt"
And user "Alice" has uploaded file with content "uploaded content" to "/FOLDER/abc.txt"
And user "Carol" has created folder "PARENT"
And user "Carol" has created folder "FOLDER"
When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API
And user "Alice" shares folder "/FOLDER" with group "grp1" using the sharing API
And user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API
And user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API
And user "Carol" accepts share "/PARENT" offered by user "Alice" using the sharing API
And user "Carol" accepts share "/FOLDER" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And user "Brian" should see the following elements
| /FOLDER |
| /PARENT |
| /Shares/PARENT |
| /Shares/FOLDER |
| /Shares/PARENT/abc.txt |
| /Shares/FOLDER/abc.txt |
And user "Brian" should not see the following elements
| /FOLDER/abc.txt |
| /PARENT/abc.txt |
And user "Carol" should see the following elements
| /FOLDER |
| /PARENT |
| /Shares/PARENT |
| /Shares/FOLDER |
| /Shares/PARENT/abc.txt |
| /Shares/FOLDER/abc.txt |
And user "Carol" should not see the following elements
| /FOLDER/abc.txt |
| /PARENT/abc.txt |
And the content of file "/Shares/PARENT/abc.txt" for user "Brian" should be "uploaded content"
And the content of file "/Shares/FOLDER/abc.txt" for user "Brian" should be "uploaded content"
And the content of file "/Shares/PARENT/abc.txt" for user "Carol" should be "uploaded content"
And the content of file "/Shares/FOLDER/abc.txt" for user "Carol" should be "uploaded content"
Scenario: user shares files in a group with matching file-names for every users involved in sharing
Given user "Brian" has disabled auto-accepting
And user "Carol" has disabled auto-accepting
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt"
And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt"
And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "textfile1.txt"
When user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API
And user "Alice" shares file "/textfile1.txt" with group "grp1" using the sharing API
And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API
And user "Brian" accepts share "/textfile1.txt" offered by user "Alice" using the sharing API
And user "Carol" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API
And user "Carol" accepts share "/textfile1.txt" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And user "Brian" should see the following elements
| /textfile0.txt |
| /textfile1.txt |
| /Shares/textfile0.txt |
| /Shares/textfile1.txt |
And user "Carol" should see the following elements
| /textfile0.txt |
| /textfile1.txt |
| /Shares/textfile0.txt |
| /Shares/textfile1.txt |
Scenario: user shares resource with matching resource-name with another user when auto accept is disabled
Given user "Brian" has disabled auto-accepting
When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API
And user "Alice" shares file "/textfile0.txt" with user "Brian" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And user "Brian" should see the following elements
| /PARENT |
| /textfile0.txt |
But user "Brian" should not see the following elements
| /Shares/textfile0.txt |
| /Shares/PARENT |
When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API
And user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And user "Brian" should see the following elements
| /PARENT |
| /textfile0.txt |
| /Shares/PARENT |
| /Shares/textfile0.txt |
Scenario: user shares file in a group with matching filename when auto accept is disabled
Given user "Brian" has disabled auto-accepting
And user "Carol" has disabled auto-accepting
And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
When user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API
Then the OCS status code should be "100"
And the HTTP status code should be "200"
And user "Brian" should see the following elements
| /textfile0.txt |
But user "Brian" should not see the following elements
| /Shares/textfile0.txt |
And user "Carol" should see the following elements
| /textfile0.txt |
But user "Carol" should not see the following elements
| /Shares/textfile0.txt |
When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API
And user "Carol" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And user "Brian" should see the following elements
| /textfile0.txt |
| /Shares/textfile0.txt |
And user "Carol" should see the following elements
| /textfile0.txt |
| /Shares/textfile0.txt |
Scenario: user shares folder with matching folder name to a user before that user has logged in
Given these users have been created without being initialized:
| username |
| David |
And user "David" has disabled auto-accepting
And user "Alice" has uploaded file with content "uploaded content" to "/PARENT/abc.txt"
When user "Alice" shares folder "/PARENT" with user "David" using the sharing API
And user "David" accepts share "/PARENT" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And user "David" should see the following elements
| /Shares/PARENT |
| /Shares/PARENT/abc.txt |
And user "David" should not see the following elements
| /PARENT (2) |
And the content of file "/Shares/PARENT/abc.txt" for user "David" should be "uploaded content"
@issue-1123 @issue-2540
Scenario Outline: deleting a share accepted file and folder
Given using <dav-path-version> DAV path
And user "Brian" has disabled auto-accepting
And user "Alice" has sent the following resource share invitation:
| resource | PARENT |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
And user "Brian" has accepted share "/PARENT" offered by user "Alice"
When user "Brian" deletes file "/Shares/PARENT" using the WebDAV API
Then the HTTP status code should be "204"
And the sharing API should report to user "Brian" that these shares are in the declined state
| path |
| /PARENT |
Examples:
| dav-path-version |
| old |
| new |
@issue-765 @issue-2131
Scenario Outline: shares exist after restoring already shared file to a previous version
Given using <dav-path-version> DAV path
And user "Brian" has disabled auto-accepting
And user "Alice" has uploaded file with content "Test Content." to "/toShareFile.txt"
And user "Alice" has uploaded file with content "Content Test Updated." to "/toShareFile.txt"
And user "Alice" has sent the following resource share invitation:
| resource | toShareFile.txt |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | File Editor |
And user "Brian" has accepted share "/toShareFile.txt" offered by user "Alice"
When user "Alice" restores version index "1" of file "/toShareFile.txt" using the WebDAV API
Then the HTTP status code should be "204"
And the content of file "/toShareFile.txt" for user "Alice" should be "Test Content."
And the content of file "/Shares/toShareFile.txt" for user "Brian" should be "Test Content."
Examples:
| dav-path-version |
| old |
| new |
| spaces |
@issue-2131
Scenario: user receives multiple group shares for matching file and folder name
Given user "Brian" has disabled auto-accepting
And group "grp2" has been created
And user "Alice" has been added to group "grp2"
And user "Brian" has been added to group "grp2"
And user "Carol" has created folder "/PARENT"
And user "Alice" has created folder "/PaRent"
And user "Alice" has uploaded the following files with content "subfile, from alice to grp2"
| path |
| /PARENT/parent.txt |
| /PaRent/parent.txt |
And user "Alice" has uploaded the following files with content "from alice to grp2"
| path |
| /PARENT.txt |
And user "Carol" has uploaded the following files with content "subfile, from carol to grp1"
| path |
| /PARENT/parent.txt |
And user "Carol" has uploaded the following files with content "from carol to grp1"
| path |
| /PARENT.txt |
| /parent.txt |
When user "Alice" shares the following entries with group "grp2" using the sharing API
| path |
| /PARENT |
| /PaRent |
| /PARENT.txt |
And user "Brian" accepts the following shares offered by user "Alice" using the sharing API
| path |
| /PARENT |
| /PaRent |
| /PARENT.txt |
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And user "Brian" should see the following elements
| /PARENT |
| /Shares/PARENT |
| /Shares/PaRent |
| /Shares/PARENT.txt |
And the content of file "/Shares/PARENT/parent.txt" for user "Brian" should be "subfile, from alice to grp2"
And the content of file "/Shares/PaRent/parent.txt" for user "Brian" should be "subfile, from alice to grp2"
And the content of file "/Shares/PARENT.txt" for user "Brian" should be "from alice to grp2"
When user "Carol" shares the following entries with group "grp2" using the sharing API
| path |
| /PARENT |
| /PARENT.txt |
| /parent.txt |
And user "Brian" accepts the following shares offered by user "Carol" using the sharing API
| path |
| /PARENT |
| /PARENT.txt |
| /parent.txt |
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And user "Brian" should see the following elements
| /PARENT |
| /Shares/PARENT |
| /Shares/PARENT (1) |
| /Shares/PaRent |
| /Shares/PARENT.txt |
| /Shares/PARENT (1).txt |
| /Shares/parent.txt |
And the content of file "/Shares/PARENT (1)/parent.txt" for user "Brian" should be "subfile, from carol to grp1"
And the content of file "/Shares/PARENT (1).txt" for user "Brian" should be "from carol to grp1"
And the content of file "/Shares/parent.txt" for user "Brian" should be "from carol to grp1"
@issue-2131
Scenario: group receives multiple shares from non-member for matching file and folder name
Given user "Carol" has disabled auto-accepting
And user "Brian" has been removed from group "grp1"
And user "Alice" has created folder "/PaRent"
And user "Carol" has created folder "/PARENT"
And user "Alice" has uploaded the following files with content "subfile, from alice to grp1"
| path |
| /PARENT/parent.txt |
| /PaRent/parent.txt |
And user "Alice" has uploaded the following files with content "from alice to grp1"
| path |
| /PARENT.txt |
And user "Brian" has uploaded the following files with content "subfile, from brian to grp1"
| path |
| /PARENT/parent.txt |
And user "Brian" has uploaded the following files with content "from brian to grp1"
| path |
| /PARENT.txt |
| /parent.txt |
When user "Alice" shares the following entries with group "grp1" using the sharing API
| path |
| /PARENT |
| /PaRent |
| /PARENT.txt |
And user "Carol" accepts the following shares offered by user "Alice" using the sharing API
| path |
| /PARENT |
| /PaRent |
| /PARENT.txt |
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And user "Carol" should see the following elements
| /PARENT |
| /Shares/PARENT |
| /Shares/PaRent |
| /Shares/PARENT.txt |
And the content of file "/Shares/PARENT/parent.txt" for user "Carol" should be "subfile, from alice to grp1"
And the content of file "/Shares/PARENT.txt" for user "Carol" should be "from alice to grp1"
When user "Brian" shares the following entries with group "grp1" using the sharing API
| path |
| /PARENT |
| /PARENT.txt |
| /parent.txt |
And user "Carol" accepts the following shares offered by user "Brian" using the sharing API
| path |
| /PARENT |
| /PARENT.txt |
| /parent.txt |
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And user "Carol" should see the following elements
| /PARENT |
| /Shares/PARENT |
| /Shares/PARENT (1) |
| /Shares/PaRent |
| /Shares/PARENT.txt |
| /Shares/PARENT (1).txt |
| /Shares/parent.txt |
And the content of file "/Shares/PARENT (1)/parent.txt" for user "Carol" should be "subfile, from brian to grp1"
And the content of file "/Shares/PARENT (1).txt" for user "Carol" should be "from brian to grp1"
Server/tests/acceptance/features/coreApiShareManagementToShares/acceptSharesToSharesFolder.feature
+97
View File
@@ -0,0 +1,97 @@
@skipOnReva
Feature: accept/decline shares coming from internal users to the Shares folder
As a user
I want to have control of which received shares I accept
So that I can keep my file system clean
Background:
Given using OCS API version "1"
And using new DAV path
And these users have been created with default attributes:
| username |
| Alice |
| Brian |
Scenario: accept an incoming file share
Given user "Alice" has uploaded file with content "КуСфера test text file 0" to "textfile0.txt"
And user "Brian" has disabled auto-accepting
And user "Alice" has sent the following resource share invitation:
| resource | textfile0.txt |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Viewer |
When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API
Then the OCS status code should be "100"
And the HTTP status code should be "200"
And the content of file "/Shares/textfile0.txt" for user "Brian" should be "КуСфера test text file 0"
Scenario: accept an incoming folder share
Given user "Alice" has created folder "/PARENT"
And user "Brian" has disabled auto-accepting
And user "Alice" has uploaded file with content "КуСфера test text file parent" to "PARENT/parent.txt"
And user "Alice" has sent the following resource share invitation:
| resource | PARENT |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Viewer |
When user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API
Then the content of file "/Shares/PARENT/parent.txt" for user "Brian" should be "КуСфера test text file parent"
Scenario: accept an incoming file share and check the response
Given user "Alice" has uploaded file with content "КуСфера test text file 0" to "textfile0.txt"
And user "Brian" has disabled auto-accepting
And user "Alice" has sent the following resource share invitation:
| resource | textfile0.txt |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | File Editor |
When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API
Then the OCS status code should be "100"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" sharing with user "Brian" should include
| share_with | %username% |
| share_with_displayname | %displayname% |
| file_target | /Shares/textfile0.txt |
| path | /Shares/textfile0.txt |
| permissions | read,update |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| item_type | file |
| mimetype | text/plain |
| storage_id | ANY_VALUE |
| share_type | user |
And the content of file "/Shares/textfile0.txt" for user "Brian" should be "КуСфера test text file 0"
Scenario: accept an incoming folder share and check the response
Given user "Alice" has created folder "/PARENT"
And user "Brian" has disabled auto-accepting
And user "Alice" has uploaded file with content "КуСфера test text file parent" to "PARENT/parent.txt"
And user "Alice" has sent the following resource share invitation:
| resource | PARENT |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
When user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API
Then the OCS status code should be "100"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" sharing with user "Brian" should include
| share_with | %username% |
| share_with_displayname | %displayname% |
| file_target | /Shares/PARENT |
| path | /Shares/PARENT |
| permissions | all |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| item_type | folder |
| mimetype | httpd/unix-directory |
| storage_id | ANY_VALUE |
| share_type | user |
And the content of file "/Shares/PARENT/parent.txt" for user "Brian" should be "КуСфера test text file parent"
Server/tests/acceptance/features/coreApiShareManagementToShares/mergeShare.feature
+148
View File
@@ -0,0 +1,148 @@
@skipOnReva @issue-1328 @issues-1289
Feature: sharing
Background:
Given using OCS API version "1"
And these users have been created with default attributes:
| username |
| Alice |
| Brian |
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Brian" has disabled auto-accepting
@smokeTest
Scenario: merging shares for recipient when shared from outside with group and member
Given user "Alice" has created folder "/merge-test-outside"
When user "Alice" shares folder "/merge-test-outside" with group "grp1" using the sharing API
And user "Alice" shares folder "/merge-test-outside" with user "Brian" using the sharing API
And user "Brian" accepts share "/merge-test-outside" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And as "Brian" folder "/Shares/merge-test-outside" should exist
And as "Brian" folder "/Shares/merge-test-outside (2)" should not exist
Scenario: merging shares for recipient when shared from outside with group and member with different permissions
Given user "Alice" has created folder "/merge-test-outside-perms"
When user "Alice" shares folder "/merge-test-outside-perms" with group "grp1" with permissions "read" using the sharing API
And user "Alice" shares folder "/merge-test-outside-perms" with user "Brian" with permissions "all" using the sharing API
And user "Brian" accepts share "/merge-test-outside-perms" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And as user "Brian" folder "/Shares/merge-test-outside-perms" should contain a property "oc:permissions" with value "SDNVCK"
And as "Brian" folder "/Shares/merge-test-outside-perms (2)" should not exist
Scenario: merging shares for recipient when shared from outside with two groups
Given group "grp2" has been created
And user "Brian" has been added to group "grp2"
And user "Alice" has created folder "/merge-test-outside-twogroups"
When user "Alice" shares folder "/merge-test-outside-twogroups" with group "grp1" using the sharing API
And user "Alice" shares folder "/merge-test-outside-twogroups" with group "grp2" using the sharing API
And user "Brian" accepts share "/merge-test-outside-twogroups" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And as "Brian" folder "/Shares/merge-test-outside-twogroups" should exist
And as "Brian" folder "/Shares/merge-test-outside-twogroups (2)" should not exist
Scenario: merging shares for recipient when shared from outside with two groups with different permissions
Given group "grp2" has been created
And user "Brian" has been added to group "grp2"
And user "Alice" has created folder "/merge-test-outside-twogroups-perms"
When user "Alice" shares folder "/merge-test-outside-twogroups-perms" with group "grp1" with permissions "read" using the sharing API
And user "Alice" shares folder "/merge-test-outside-twogroups-perms" with group "grp2" with permissions "all" using the sharing API
And user "Brian" accepts share "/merge-test-outside-twogroups-perms" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And as user "Brian" folder "/Shares/merge-test-outside-twogroups-perms" should contain a property "oc:permissions" with value "SDNVCK"
And as "Brian" folder "/Shares/merge-test-outside-twogroups-perms (2)" should not exist
Scenario: merging shares for recipient when shared from outside with two groups and member
Given group "grp2" has been created
And user "Brian" has been added to group "grp2"
And user "Alice" has created folder "/merge-test-outside-twogroups-member-perms"
When user "Alice" shares folder "/merge-test-outside-twogroups-member-perms" with group "grp1" with permissions "read" using the sharing API
And user "Alice" shares folder "/merge-test-outside-twogroups-member-perms" with group "grp2" with permissions "all" using the sharing API
And user "Alice" shares folder "/merge-test-outside-twogroups-member-perms" with user "Brian" with permissions "read" using the sharing API
And user "Brian" accepts share "/merge-test-outside-twogroups-member-perms" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And as user "Brian" folder "/Shares/merge-test-outside-twogroups-member-perms" should contain a property "oc:permissions" with value "SDNVCK"
And as "Brian" folder "/Shares/merge-test-outside-twogroups-member-perms (2)" should not exist
Scenario: merging shares for recipient when shared from inside with group
Given user "Brian" has created folder "/merge-test-inside-group"
When user "Brian" shares folder "/merge-test-inside-group" with group "grp1" using the sharing API
Then the OCS status code should be "100"
And the HTTP status code should be "200"
And as "Brian" folder "/merge-test-inside-group" should exist
And as "Brian" folder "/Shares/merge-test-inside-group" should not exist
Scenario: merging shares for recipient when shared from inside with two groups
Given group "grp2" has been created
And user "Brian" has been added to group "grp2"
And user "Brian" has created folder "/merge-test-inside-twogroups"
When user "Brian" shares folder "/merge-test-inside-twogroups" with group "grp1" using the sharing API
And user "Brian" shares folder "/merge-test-inside-twogroups" with group "grp2" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And as "Brian" folder "/merge-test-inside-twogroups" should exist
And as "Brian" folder "/Shares/merge-test-inside-twogroups" should not exist
And as "Brian" folder "/Shares/merge-test-inside-twogroups (2)" should not exist
Scenario: merging shares for recipient when shared from inside with group with less permissions
Given group "grp2" has been created
And user "Brian" has been added to group "grp2"
And user "Brian" has created folder "/merge-test-inside-twogroups-perms"
When user "Brian" shares folder "/merge-test-inside-twogroups-perms" with group "grp1" using the sharing API
And user "Brian" shares folder "/merge-test-inside-twogroups-perms" with group "grp2" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And as user "Brian" folder "/merge-test-inside-twogroups-perms" should contain a property "oc:permissions" with value "RDNVCKZP" or with value "RMDNVCKZP"
And as "Brian" folder "/Shares/merge-test-inside-twogroups-perms" should not exist
And as "Brian" folder "/Shares/merge-test-inside-twogroups-perms (2)" should not exist
Scenario: merging shares for recipient when shared from outside with group then user and recipient renames in between
And user "Alice" has created folder "/merge-test-outside-groups-renamebeforesecondshare"
# Section 1: Brian receives and accepts the group share from Alice and moves and renames it out of the "Shares" folder
When user "Alice" shares folder "/merge-test-outside-groups-renamebeforesecondshare" with group "grp1" using the sharing API
And user "Brian" accepts share "/merge-test-outside-groups-renamebeforesecondshare" offered by user "Alice" using the sharing API
And user "Brian" moves folder "/Shares/merge-test-outside-groups-renamebeforesecondshare" to "/merge-test-outside-groups-renamebeforesecondshare-renamed" using the WebDAV API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on each endpoint should be "200, 200, 502" respectively
And as "Brian" folder "/Shares/merge-test-outside-groups-renamebeforesecondshare" should exist
But as "Brian" folder "/merge-test-outside-groups-renamebeforesecondshare-renamed" should not exist
# Section 2: Brian receives and accepts the user share from Alice. Brian now has 2 shares of the same folder owned by Alice
# The server "merges" the 2 shares and presents them to Brian as a single folder inside the "Shares" folder
When user "Alice" shares folder "/merge-test-outside-groups-renamebeforesecondshare" with user "Brian" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And as "Brian" folder "/Shares/merge-test-outside-groups-renamebeforesecondshare" should exist
But as "Brian" folder "/merge-test-outside-groups-renamebeforesecondshare-renamed" should not exist
Scenario: merging shares for recipient when shared from outside with user then group and recipient renames in between
And user "Alice" has created folder "/merge-test-outside-groups-renamebeforesecondshare"
# Section 1: Brian receives and accepts the user share from Alice and moves and renames it out of the "Shares" folder
When user "Alice" shares folder "/merge-test-outside-groups-renamebeforesecondshare" with user "Brian" using the sharing API
And user "Brian" accepts share "/merge-test-outside-groups-renamebeforesecondshare" offered by user "Alice" using the sharing API
And user "Brian" moves folder "/Shares/merge-test-outside-groups-renamebeforesecondshare" to "/merge-test-outside-groups-renamebeforesecondshare-renamed" using the WebDAV API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on each endpoint should be "200, 200, 502" respectively
And as "Brian" folder "/Shares/merge-test-outside-groups-renamebeforesecondshare" should exist
But as "Brian" folder "/merge-test-outside-groups-renamebeforesecondshare-renamed" should not exist
# Section 2: Brian receives and accepts the group share from Alice. Brian now has 2 shares of the same folder owned by Alice
# The server "merges" the 2 shares and presents them to Brian as a single folder inside the "Shares" folder
When user "Alice" shares folder "/merge-test-outside-groups-renamebeforesecondshare" with group "grp1" using the sharing API
And user "Brian" accepts share "/merge-test-outside-groups-renamebeforesecondshare" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And as "Brian" folder "/Shares/merge-test-outside-groups-renamebeforesecondshare" should exist
But as "Brian" folder "/merge-test-outside-groups-renamebeforesecondshare-renamed" should not exist
Server/tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShare.feature
+505
View File
@@ -0,0 +1,505 @@
@skipOnReva @issue-1289 @issue-1328
Feature: sharing
Background:
Given using OCS API version "1"
And these users have been created with default attributes:
| username |
| Alice |
| Brian |
| Carol |
@issue-8242 @issue-10334
Scenario Outline: sharer renames the shared item (old/new webdav)
Given user "Alice" has uploaded file with content "foo" to "sharefile.txt"
And using <dav-path-version> DAV path
And user "Alice" has sent the following resource share invitation:
| resource | sharefile.txt |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Viewer |
And user "Brian" has a share "sharefile.txt" synced
And user "Alice" has sent the following resource share invitation:
| resource | sharefile.txt |
| space | Personal |
| sharee | Carol |
| shareType | user |
| permissionsRole | Viewer |
And user "Carol" has a share "sharefile.txt" synced
When user "Alice" moves file "sharefile.txt" to "renamedsharefile.txt" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "renamedsharefile.txt" should exist
And as "Brian" file "Shares/sharefile.txt" should exist
And as "Carol" file "Shares/sharefile.txt" should exist
When user "Alice" sends HTTP method "PROPFIND" to URL "<dav-path>"
Then the HTTP status code should be "207"
And as user "Alice" the value of the item "//oc:name" of path "<dav-path>/renamedsharefile.txt" in the response should be "renamedsharefile.txt"
And as user "Alice" the value of the item "//d:displayname" of path "<dav-path>/renamedsharefile.txt" in the response should be "renamedsharefile.txt"
When user "Brian" sends HTTP method "PROPFIND" to URL "<dav-path>/Shares"
Then the HTTP status code should be "207"
And as user "Brian" the value of the item "//oc:name" of path "<dav-path>/Shares/sharefile.txt" in the response should be "sharefile.txt"
And as user "Brian" the value of the item "//d:displayname" of path "<dav-path>/Shares/sharefile.txt" in the response should be "sharefile.txt"
When user "Carol" sends HTTP method "PROPFIND" to URL "<dav-path>/Shares"
Then the HTTP status code should be "207"
And as user "Carol" the value of the item "//oc:name" of path "<dav-path>/Shares/sharefile.txt" in the response should be "sharefile.txt"
And as user "Carol" the value of the item "//d:displayname" of path "<dav-path>/Shares/sharefile.txt" in the response should be "sharefile.txt"
Examples:
| dav-path-version | dav-path |
| old | /webdav |
| new | /dav/files/%username% |
@issue-8242
Scenario Outline: sharer renames the shared item (spaces webdav)
Given user "Alice" has uploaded file with content "foo" to "sharefile.txt"
And user "Alice" has sent the following resource share invitation:
| resource | sharefile.txt |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Viewer |
And user "Brian" has a share "sharefile.txt" synced
And user "Alice" has sent the following resource share invitation:
| resource | sharefile.txt |
| space | Personal |
| sharee | Carol |
| shareType | user |
| permissionsRole | Viewer |
And user "Carol" has a share "sharefile.txt" synced
When user "Alice" moves file "sharefile.txt" to "renamedsharefile.txt" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "renamedsharefile.txt" should exist
And as "Brian" file "Shares/sharefile.txt" should exist
And as "Carol" file "Shares/sharefile.txt" should exist
And using spaces DAV path
When user "Alice" sends HTTP method "PROPFIND" to URL "<dav-path-personal>"
Then the HTTP status code should be "207"
And as user "Alice" the value of the item "//oc:name" of path "<dav-path-personal>/renamedsharefile.txt" in the response should be "renamedsharefile.txt"
And as user "Alice" the value of the item "//d:displayname" of path "<dav-path-personal>/renamedsharefile.txt" in the response should be "renamedsharefile.txt"
When user "Brian" sends HTTP method "PROPFIND" to URL "<dav-path>"
Then the HTTP status code should be "207"
And as user "Brian" the value of the item "//oc:name" of path "<dav-path>/sharefile.txt" in the response should be "sharefile.txt"
And as user "Brian" the value of the item "//d:displayname" of path "<dav-path>/sharefile.txt" in the response should be "sharefile.txt"
When user "Carol" sends HTTP method "PROPFIND" to URL "<dav-path>"
Then the HTTP status code should be "207"
And as user "Carol" the value of the item "//oc:name" of path "<dav-path>/sharefile.txt" in the response should be "sharefile.txt"
And as user "Carol" the value of the item "//d:displayname" of path "<dav-path>/sharefile.txt" in the response should be "sharefile.txt"
Examples:
| dav-path | dav-path-personal |
| /dav/spaces/%shares_drive_id% | /dav/spaces/%spaceid% |
@issue-8242 @issue-10334 @env-config
Scenario Outline: share receiver renames the shared item (old/new webdav)
Given user "Alice" has uploaded file with content "foo" to "/sharefile.txt"
And the administrator has enabled the permissions role "Secure Viewer"
And using <dav-path-version> DAV path
And user "Alice" has sent the following resource share invitation:
| resource | sharefile.txt |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | <permissions-role> |
And user "Brian" has a share "sharefile.txt" synced
And user "Alice" has sent the following resource share invitation:
| resource | sharefile.txt |
| space | Personal |
| sharee | Carol |
| shareType | user |
| permissionsRole | <permissions-role> |
And user "Carol" has a share "sharefile.txt" synced
When user "Carol" moves file "Shares/sharefile.txt" to "Shares/renamedsharefile.txt" using the WebDAV API
Then the HTTP status code should be "201"
And as "Carol" file "Shares/renamedsharefile.txt" should exist
And as "Brian" file "Shares/sharefile.txt" should exist
And as "Alice" file "sharefile.txt" should exist
When user "Carol" sends HTTP method "PROPFIND" to URL "<dav-path>/Shares"
Then the HTTP status code should be "207"
And as user "Carol" the value of the item "//oc:name" of path "<dav-path>/Shares/renamedsharefile.txt" in the response should be "renamedsharefile.txt"
And as user "Carol" the value of the item "//d:displayname" of path "<dav-path>/Shares/renamedsharefile.txt" in the response should be "renamedsharefile.txt"
When user "Alice" sends HTTP method "PROPFIND" to URL "<dav-path>"
Then the HTTP status code should be "207"
And as user "Alice" the value of the item "//oc:name" of path "<dav-path>/sharefile.txt" in the response should be "sharefile.txt"
And as user "Alice" the value of the item "//d:displayname" of path "<dav-path>/sharefile.txt" in the response should be "sharefile.txt"
When user "Brian" sends HTTP method "PROPFIND" to URL "<dav-path>/Shares"
Then the HTTP status code should be "207"
And as user "Brian" the value of the item "//oc:name" of path "<dav-path>/Shares/sharefile.txt" in the response should be "sharefile.txt"
And as user "Brian" the value of the item "//d:displayname" of path "<dav-path>/Shares/sharefile.txt" in the response should be "sharefile.txt"
Examples:
| dav-path-version | dav-path | permissions-role |
| old | /webdav | Viewer |
| old | /webdav | Secure Viewer |
| new | /dav/files/%username% | Viewer |
| new | /dav/files/%username% | Secure Viewer |
@issue-8242 @env-config
Scenario Outline: share receiver renames the shared item (spaces webdav)
Given user "Alice" has uploaded file with content "foo" to "/sharefile.txt"
And the administrator has enabled the permissions role "Secure Viewer"
And user "Alice" has sent the following resource share invitation:
| resource | sharefile.txt |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | <permissions-role> |
And user "Brian" has a share "sharefile.txt" synced
And user "Alice" has sent the following resource share invitation:
| resource | sharefile.txt |
| space | Personal |
| sharee | Carol |
| shareType | user |
| permissionsRole | <permissions-role> |
And user "Carol" has a share "sharefile.txt" synced
When user "Carol" moves file "Shares/sharefile.txt" to "Shares/renamedsharefile.txt" using the WebDAV API
Then the HTTP status code should be "201"
And as "Carol" file "Shares/renamedsharefile.txt" should exist
And as "Brian" file "Shares/sharefile.txt" should exist
And as "Alice" file "sharefile.txt" should exist
And using spaces DAV path
When user "Carol" sends HTTP method "PROPFIND" to URL "<dav-path>"
Then the HTTP status code should be "207"
And as user "Carol" the value of the item "//oc:name" of path "<dav-path>/renamedsharefile.txt" in the response should be "renamedsharefile.txt"
And as user "Carol" the value of the item "//d:displayname" of path "<dav-path>/renamedsharefile.txt" in the response should be "renamedsharefile.txt"
When user "Alice" sends HTTP method "PROPFIND" to URL "<dav-path-personal>"
Then the HTTP status code should be "207"
And as user "Alice" the value of the item "//oc:name" of path "<dav-path-personal>/sharefile.txt" in the response should be "sharefile.txt"
And as user "Alice" the value of the item "//d:displayname" of path "<dav-path-personal>/sharefile.txt" in the response should be "sharefile.txt"
When user "Brian" sends HTTP method "PROPFIND" to URL "<dav-path>"
Then the HTTP status code should be "207"
And as user "Brian" the value of the item "//oc:name" of path "<dav-path>/sharefile.txt" in the response should be "sharefile.txt"
And as user "Brian" the value of the item "//d:displayname" of path "<dav-path>/sharefile.txt" in the response should be "sharefile.txt"
Examples:
| dav-path | dav-path-personal | permissions-role |
| /dav/spaces/%shares_drive_id% | /dav/spaces/%spaceid% | Viewer |
| /dav/spaces/%shares_drive_id% | /dav/spaces/%spaceid% | Secure Viewer |
Scenario Outline: keep group share when the one user renames the share and the user is deleted
Given using <dav-path-version> DAV path
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Carol" 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 | Viewer |
And user "Carol" has a share "/TMP" synced
When user "Carol" moves folder "/Shares/TMP" to "/Shares/new" using the WebDAV API
And the administrator deletes user "Carol" using the provisioning API
Then the HTTP status code of responses on each endpoint should be "201, 204" respectively
And as "Alice" file "Shares/TMP" should not exist
Examples:
| dav-path-version |
| old |
| new |
| spaces |
Scenario Outline: receiver renames a received share with read, change permissions inside the Shares folder
Given using <dav-path-version> DAV path
And user "Alice" has created folder "folderToShare"
And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "/folderToShare/fileInside"
And user "Alice" has sent the following resource share invitation:
| resource | folderToShare |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
And user "Brian" has a share "folderToShare" synced
When user "Brian" moves folder "/Shares/folderToShare" to "/Shares/myFolder" using the WebDAV API
Then the HTTP status code should be "201"
And as "Brian" folder "/Shares/myFolder" should exist
But as "Alice" folder "/Shares/myFolder" should not exist
When user "Brian" moves file "/Shares/myFolder/fileInside" to "/Shares/myFolder/renamedFile" using the WebDAV API
Then the HTTP status code should be "201"
And as "Brian" file "/Shares/myFolder/renamedFile" should exist
And as "Alice" file "/folderToShare/renamedFile" should exist
But as "Alice" file "/folderToShare/fileInside" should not exist
Examples:
| dav-path-version |
| old |
| new |
| spaces |
@env-config
Scenario Outline: receiver tries to rename a received share with read permissions inside the Shares folder
Given using <dav-path-version> DAV path
And user "Alice" has created folder "folderToShare"
And the administrator has enabled the permissions role "Secure Viewer"
And user "Alice" has created folder "folderToShare/folderInside"
And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "/folderToShare/fileInside"
And user "Alice" has sent the following resource share invitation:
| resource | folderToShare |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | <permissions-role> |
And user "Brian" has a share "folderToShare" synced
When user "Brian" moves folder "/Shares/folderToShare" to "/Shares/myFolder" using the WebDAV API
Then the HTTP status code should be "201"
And as "Brian" folder "/Shares/myFolder" should exist
But as "Alice" folder "/Shares/myFolder" should not exist
When user "Brian" moves file "/Shares/myFolder/fileInside" to "/Shares/myFolder/renamedFile" using the WebDAV API
Then the HTTP status code should be "403"
And as "Brian" file "/Shares/myFolder/renamedFile" should not exist
But as "Brian" file "Shares/myFolder/fileInside" should exist
When user "Brian" moves folder "/Shares/myFolder/folderInside" to "/Shares/myFolder/renamedFolder" using the WebDAV API
Then the HTTP status code should be "403"
And as "Brian" folder "/Shares/myFolder/renamedFolder" should not exist
But as "Brian" folder "Shares/myFolder/folderInside" should exist
Examples:
| permissions-role | dav-path-version |
| Viewer | old |
| Secure Viewer | old |
| Viewer | new |
| Secure Viewer | new |
| Viewer | spaces |
| Secure Viewer | spaces |
Scenario Outline: receiver renames a received folder share to a different name on the same folder
Given using <dav-path-version> DAV path
And user "Alice" has created folder "PARENT"
And user "Alice" has sent the following resource share invitation:
| resource | PARENT |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
And user "Brian" has a share "PARENT" synced
When user "Brian" moves folder "/Shares/PARENT" to "/Shares/myFolder" using the WebDAV API
Then the HTTP status code should be "201"
And as "Brian" folder "/Shares/myFolder" should exist
But as "Alice" folder "myFolder" should not exist
Examples:
| dav-path-version |
| old |
| new |
| spaces |
Scenario Outline: receiver renames a received file share to different name on the same folder
Given using <dav-path-version> DAV path
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt"
And user "Alice" has sent the following resource share invitation:
| resource | fileToShare.txt |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | File Editor |
And user "Brian" has a share "fileToShare.txt" synced
When user "Brian" moves file "/Shares/fileToShare.txt" to "/Shares/newFile.txt" using the WebDAV API
Then the HTTP status code should be "201"
And as "Brian" file "/Shares/newFile.txt" should exist
But as "Alice" file "newFile.txt" should not exist
Examples:
| dav-path-version |
| old |
| new |
| spaces |
Scenario Outline: receiver renames a received file share to different name on the same folder for group sharing
Given using <dav-path-version> DAV path
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt"
And user "Alice" has sent the following resource share invitation:
| resource | fileToShare.txt |
| space | Personal |
| sharee | grp1 |
| shareType | group |
| permissionsRole | File Editor |
And user "Brian" has a share "fileToShare.txt" synced
When user "Brian" moves file "/Shares/fileToShare.txt" to "/Shares/newFile.txt" using the WebDAV API
Then the HTTP status code should be "201"
And as "Brian" file "/Shares/newFile.txt" should exist
But as "Alice" file "newFile.txt" should not exist
Examples:
| dav-path-version |
| old |
| new |
| spaces |
Scenario Outline: receiver renames a received folder share to different name on the same folder for group sharing
Given using <dav-path-version> DAV path
And group "grp1" has been created
And user "Alice" has created folder "PARENT"
And user "Brian" has been added to group "grp1"
And user "Alice" has sent the following resource share invitation:
| resource | PARENT |
| space | Personal |
| sharee | grp1 |
| shareType | group |
| permissionsRole | Viewer |
And user "Brian" has a share "PARENT" synced
When user "Brian" moves folder "/Shares/PARENT" to "/Shares/myFolder" using the WebDAV API
Then the HTTP status code should be "201"
And as "Brian" folder "/Shares/myFolder" should exist
But as "Alice" folder "myFolder" should not exist
Examples:
| dav-path-version |
| old |
| new |
| spaces |
Scenario Outline: receiver renames a received file share with read,update permissions inside the Shares folder in group sharing
Given using <dav-path-version> DAV path
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt"
And user "Alice" has sent the following resource share invitation:
| resource | fileToShare.txt |
| space | Personal |
| sharee | grp1 |
| shareType | group |
| permissionsRole | File Editor |
And user "Brian" has a share "fileToShare.txt" synced
When user "Brian" moves folder "/Shares/fileToShare.txt" to "/Shares/newFile.txt" using the WebDAV API
Then the HTTP status code should be "201"
And as "Brian" file "/Shares/newFile.txt" should exist
But as "Alice" file "/Shares/newFile.txt" should not exist
Examples:
| dav-path-version |
| old |
| new |
| spaces |
Scenario Outline: receiver renames a received folder share with read, change permissions inside the Shares folder in group sharing
Given using <dav-path-version> DAV path
And group "grp1" has been created
And user "Alice" has created folder "PARENT"
And user "Brian" has been added to group "grp1"
And user "Alice" has sent the following resource share invitation:
| resource | PARENT |
| space | Personal |
| sharee | grp1 |
| shareType | group |
| permissionsRole | Editor |
And user "Brian" has a share "PARENT" synced
When user "Brian" moves folder "/Shares/PARENT" to "/Shares/myFolder" using the WebDAV API
Then the HTTP status code should be "201"
And as "Brian" folder "/Shares/myFolder" should exist
But as "Alice" folder "/Shares/myFolder" should not exist
Examples:
| dav-path-version |
| old |
| new |
| spaces |
Scenario Outline: receiver renames a received file share with share, read permissions inside the Shares folder in group sharing)
Given using <dav-path-version> DAV path
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt"
And user "Alice" has sent the following resource share invitation:
| resource | fileToShare.txt |
| space | Personal |
| sharee | grp1 |
| shareType | group |
| permissionsRole | Viewer |
And user "Brian" has a share "fileToShare.txt" synced
When user "Brian" moves file "/Shares/fileToShare.txt" to "/Shares/newFile.txt" using the WebDAV API
Then the HTTP status code should be "201"
And as "Brian" file "/Shares/newFile.txt" should exist
But as "Alice" file "/Shares/newFile.txt" should not exist
Examples:
| dav-path-version |
| old |
| new |
| spaces |
Scenario Outline: receiver renames a received folder share with read permissions inside the Shares folder in group sharing
Given using <dav-path-version> DAV path
And group "grp1" has been created
And user "Alice" has created folder "PARENT"
And user "Brian" has been added to group "grp1"
And user "Alice" has sent the following resource share invitation:
| resource | PARENT |
| space | Personal |
| sharee | grp1 |
| shareType | group |
| permissionsRole | Viewer |
And user "Brian" has a share "PARENT" synced
When user "Brian" moves folder "/Shares/PARENT" to "/Shares/myFolder" using the WebDAV API
Then the HTTP status code should be "201"
And as "Brian" folder "/Shares/myFolder" should exist
But as "Alice" folder "/Shares/myFolder" should not exist
Examples:
| dav-path-version |
| old |
| new |
| spaces |
@issue-2141
Scenario Outline: receiver renames a received folder share to name with special characters in group sharing
Given using <dav-path-version> DAV path
And group "grp1" has been created
And user "Carol" has been added to group "grp1"
And user "Alice" has created folder "<sharer-folder>"
And user "Alice" has created folder "<group-folder>"
And user "Alice" has sent the following resource share invitation:
| resource | <sharer-folder> |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
And user "Brian" has a share "<sharer-folder>" synced
When user "Brian" moves folder "/Shares/<sharer-folder>" to "/Shares/<receiver-folder>" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" folder "<receiver-folder>" should not exist
And as "Brian" folder "/Shares/<receiver-folder>" should exist
When user "Alice" shares folder "<group-folder>" with group "grp1" using the sharing API
And user "Carol" moves folder "/Shares/<group-folder>" to "/Shares/<receiver-folder>" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" folder "<receiver-folder>" should not exist
But as "Carol" folder "/Shares/<receiver-folder>" should exist
Examples:
| sharer-folder | group-folder | receiver-folder | dav-path-version |
| ?abc=oc # | ?abc=oc g%rp# | # oc?test=oc&a | old |
| @a#8a=b?c=d | @a#8a=b?c=d grp | ?a#8 a=b?c=d | old |
| ?abc=oc # | ?abc=oc g%rp# | # oc?test=oc&a | new |
| @a#8a=b?c=d | @a#8a=b?c=d grp | ?a#8 a=b?c=d | new |
| ?abc=oc # | ?abc=oc g%rp# | # oc?test=oc&a | spaces |
| @a#8a=b?c=d | @a#8a=b?c=d grp | ?a#8 a=b?c=d | spaces |
@issue-2141
Scenario Outline: receiver renames a received file share to name with special characters with read, change permissions in group sharing
Given using <dav-path-version> DAV path
And group "grp1" has been created
And user "Carol" has been added to group "grp1"
And user "Alice" has created folder "<sharer-folder>"
And user "Alice" has created folder "<group-folder>"
And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "/<sharer-folder>/fileInside"
And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "/<group-folder>/fileInside"
And user "Alice" has sent the following resource share invitation:
| resource | <sharer-folder> |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
And user "Brian" has a share "<sharer-folder>" synced
When user "Brian" moves folder "/Shares/<sharer-folder>/fileInside" to "/Shares/<sharer-folder>/<receiver_file>" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "<sharer-folder>/<receiver_file>" should exist
And as "Brian" file "/Shares/<sharer-folder>/<receiver_file>" should exist
When user "Alice" shares folder "<group-folder>" with group "grp1" with permissions "read,change" using the sharing API
And user "Carol" moves folder "/Shares/<group-folder>/fileInside" to "/Shares/<group-folder>/<receiver_file>" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "<group-folder>/<receiver_file>" should exist
And as "Carol" file "/Shares/<group-folder>/<receiver_file>" should exist
Examples:
| sharer-folder | group-folder | receiver_file | dav-path-version |
| ?abc=oc # | ?abc=oc g%rp# | # oc?test=oc&a | old |
| @a#8a=b?c=d | @a#8a=b?c=d grp | ?a#8 a=b?c=d | old |
| ?abc=oc # | ?abc=oc g%rp# | # oc?test=oc&a | new |
| @a#8a=b?c=d | @a#8a=b?c=d grp | ?a#8 a=b?c=d | new |
| ?abc=oc # | ?abc=oc g%rp# | # oc?test=oc&a | spaces |
| @a#8a=b?c=d | @a#8a=b?c=d grp | ?a#8 a=b?c=d | spaces |
Server/tests/acceptance/features/coreApiShareManagementToShares/moveShareInsideAnotherShare.feature
+94
View File
@@ -0,0 +1,94 @@
@skipOnReva
Feature: moving a share inside another share
As a user
I want to move a shared resource inside another shared resource
So that I have full flexibility when managing resources
Background:
Given using OCS API version "1"
And these users have been created with default attributes:
| username |
| Alice |
| Brian |
And user "Alice" has created folder "folderA"
And user "Alice" has created folder "folderB"
And user "Alice" has uploaded file with content "text A" to "/folderA/fileA.txt"
And user "Alice" has uploaded file with content "text B" to "/folderB/fileB.txt"
And user "Alice" has sent the following resource share invitation:
| resource | folderA |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
And user "Brian" has a share "folderA" synced
And user "Alice" has sent the following resource share invitation:
| resource | folderB |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Editor |
And user "Brian" has a share "folderB" synced
Scenario Outline: share receiver cannot move a whole share inside another share
Given using <dav-path-version> DAV path
When user "Brian" moves folder "Shares/folderB" to "Shares/folderA/folderB" using the WebDAV API
Then the HTTP status code should be "502"
And as "Alice" folder "/folderB" should exist
And as "Brian" folder "/Shares/folderB" should exist
And as "Alice" file "/folderB/fileB.txt" should exist
And as "Brian" file "/Shares/folderB/fileB.txt" should exist
Examples:
| dav-path-version |
| old |
| new |
| spaces |
Scenario Outline: share owner moves a whole share inside another share
Given using <dav-path-version> DAV path
When user "Alice" moves folder "folderB" to "folderA/folderB" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" folder "/folderB" should not exist
And as "Alice" folder "/folderA/folderB" should exist
And as "Brian" folder "/Shares/folderB" should exist
And as "Alice" file "/folderA/folderB/fileB.txt" should exist
And as "Brian" file "/Shares/folderA/folderB/fileB.txt" should exist
And as "Brian" file "/Shares/folderB/fileB.txt" should exist
Examples:
| dav-path-version |
| old |
| new |
| spaces |
Scenario Outline: share receiver moves a local folder inside a received share (local folder does not have a share in it)
Given using <dav-path-version> DAV path
And user "Brian" has created folder "localFolder"
And user "Brian" has created folder "localFolder/subFolder"
And user "Brian" has uploaded file with content "local text" to "/localFolder/localFile.txt"
When user "Brian" moves folder "localFolder" to "Shares/folderA/localFolder" using the WebDAV API
Then the HTTP status code should be "502"
And as "Brian" folder "/Shares/folderA/localFolder" should not exist
And as "Alice" folder "/folderA/localFolder" should not exist
And as "Brian" folder "/localFolder" should exist
Examples:
| dav-path-version |
| old |
| new |
| spaces |
Scenario Outline: share receiver tries to move a whole share inside a local folder
Given using <dav-path-version> DAV path
And user "Brian" has created folder "localFolder"
And user "Brian" has uploaded file with content "local text" to "/localFolder/localFile.txt"
When user "Brian" moves folder "Shares/folderB" to "localFolder/folderB" using the WebDAV API
Then the HTTP status code should be "502"
And as "Alice" file "/folderB/fileB.txt" should exist
And as "Brian" file "/Shares/folderB/fileB.txt" should exist
Examples:
| dav-path-version |
| old |
| new |
| spaces |