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

copy feature files from core

Browse Source
This commit is contained in:
Saw-jan
2023-01-05 09:22:52 +05:45
committed by Phil Davis
parent 35d4cb53ae
commit c59392bc1e
336 changed files with 52903 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tests/acceptance/features/coreApiShareManagementBasicToShares/createShareFromLocalStorageToSharesFolder.feature
+114
View File
@@ -0,0 +1,114 @@
@api @local_storage @files_external-app-required @notToImplementOnOCIS @files_sharing-app-required
Feature: local-storage
Background:
Given the administrator has set the default folder for received shares to "Shares"
And auto-accept shares has been disabled
And these users have been created with default attributes and without skeleton files:
| username |
| Alice |
| Brian |
@skipOnEncryptionType:user-keys @encryption-issue-181
Scenario Outline: Share a file inside a local external storage
Given using OCS API version "<ocs_api_version>"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/local_storage/filetoshare.txt"
When user "Alice" shares file "/local_storage/filetoshare.txt" with user "Brian" using the sharing API
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" sharing with user "Brian" should include
| share_with | %username% |
| share_with_displayname | %displayname% |
| file_target | /Shares/filetoshare.txt |
| path | /local_storage/filetoshare.txt |
| permissions | share,read,update |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| item_type | file |
| mimetype | text/plain |
| storage_id | ANY_VALUE |
| share_type | user |
When user "Brian" accepts share "<pending_share_path>" offered by user "Alice" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
And as "Brian" file "/Shares/filetoshare.txt" should exist
Examples:
| ocs_api_version | ocs_status_code | pending_share_path |
| 1 | 100 | /filetoshare.txt |
| 2 | 200 | /filetoshare.txt |
Scenario Outline: Share a folder inside a local external storage
Given using OCS API version "<ocs_api_version>"
And user "Alice" has created folder "/local_storage/foo"
When user "Alice" shares folder "/local_storage/foo" with user "Brian" using the sharing API
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" sharing with user "Brian" should include
| share_with | %username% |
| share_with_displayname | %displayname% |
| file_target | /Shares/foo |
| path | /local_storage/foo |
| permissions | all |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| item_type | folder |
| mimetype | httpd/unix-directory |
| storage_id | ANY_VALUE |
| share_type | user |
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
@skipOnEncryptionType:user-keys @encryption-issue-181
Scenario Outline: Share a file inside a local external storage to a group
Given using OCS API version "<ocs_api_version>"
And group "grp1" has been created
And user "Alice" has been added to group "grp1"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/local_storage/filetoshare.txt"
When user "Alice" shares file "/local_storage/filetoshare.txt" with group "grp1" using the sharing API
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" sharing with group "grp1" should include
| share_with | grp1 |
| share_with_displayname | grp1 |
| file_target | /Shares/filetoshare.txt |
| path | /local_storage/filetoshare.txt |
| permissions | share,read,update |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| item_type | file |
| mimetype | text/plain |
| storage_id | ANY_VALUE |
| share_type | group |
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: Share a folder inside a local external storage to a group
Given using OCS API version "<ocs_api_version>"
And group "grp1" has been created
And user "Alice" has been added to group "grp1"
And user "Alice" has created folder "/local_storage/foo"
When user "Alice" shares folder "/local_storage/foo" with group "grp1" using the sharing API
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" sharing with group "grp1" should include
| share_with | grp1 |
| share_with_displayname | grp1 |
| file_target | /Shares/foo |
| path | /local_storage/foo |
| permissions | all |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| item_type | folder |
| mimetype | httpd/unix-directory |
| storage_id | ANY_VALUE |
| share_type | group |
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature
+783
View File
@@ -0,0 +1,783 @@
@api @files_sharing-app-required
Feature: sharing
Background:
Given the administrator has set the default folder for received shares to "Shares"
And auto-accept shares has been disabled
And user "Alice" has been created with default attributes and without skeleton files
@smokeTest @skipOnEncryptionType:user-keys @issue-32322
Scenario Outline: Creating a share of a file with a user, the default permissions are read(1)+update(2)+can-share(16)
Given using OCS API version "<ocs_api_version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API
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" sharing with user "Brian" should include
| share_with | %username% |
| share_with_displayname | %displayname% |
| share_with_user_type | 0 |
| file_target | /Shares/textfile0.txt |
| path | /textfile0.txt |
| permissions | share,read,update |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| item_type | file |
| mimetype | text/plain |
| storage_id | ANY_VALUE |
| share_type | user |
When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
And the content of file "/Shares/textfile0.txt" for user "Brian" should be "ownCloud test text file 0"
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
@smokeTest @skipOnEncryptionType:user-keys @issue-32322 @issue-ocis-2133
Scenario Outline: Creating a share of a file containing commas in the filename, with a user, the default permissions are read(1)+update(2)+can-share(16)
Given using OCS API version "<ocs_api_version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "file with comma in filename" to "/sample,1.txt"
When user "Alice" shares file "sample,1.txt" with user "Brian" using the sharing API
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" sharing with user "Brian" should include
| share_with | %username% |
| share_with_displayname | %displayname% |
| file_target | /Shares/sample,1.txt |
| path | /sample,1.txt |
| permissions | share,read,update |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| item_type | file |
| mimetype | text/plain |
| storage_id | ANY_VALUE |
| share_type | user |
When user "Brian" accepts share "/sample,1.txt" offered by user "Alice" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
And the content of file "/Shares/sample,1.txt" for user "Brian" should be "file with comma in filename"
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
@issue-ocis-2133 @issue-ocis-reva-301 @issue-ocis-reva-302
Scenario Outline: Creating a share of a file with a user and asking for various permission combinations
Given using OCS API version "<ocs_api_version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
When user "Alice" shares file "textfile0.txt" with user "Brian" with permissions <requested_permissions> using the sharing API
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" sharing with user "Brian" should include
| share_with | %username% |
| share_with_displayname | %displayname% |
| file_target | /Shares/textfile0.txt |
| path | /textfile0.txt |
| permissions | <granted_permissions> |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| item_type | file |
| mimetype | text/plain |
| storage_id | ANY_VALUE |
| share_type | user |
Examples:
| ocs_api_version | requested_permissions | granted_permissions | ocs_status_code |
# Ask for full permissions. You get share plus read plus update. create and delete do not apply to shares of a file
| 1 | 31 | 19 | 100 |
| 2 | 31 | 19 | 200 |
# Ask for read, share (17), create and delete. You get share plus read
| 1 | 29 | 17 | 100 |
| 2 | 29 | 17 | 200 |
# Ask for read, update, create, delete. You get read plus update.
| 1 | 15 | 3 | 100 |
| 2 | 15 | 3 | 200 |
# Ask for just update. You get exactly update (you do not get read or anything else)
| 1 | 2 | 2 | 100 |
| 2 | 2 | 2 | 200 |
Scenario Outline: Creating a share of a file with no permissions should fail
Given using OCS API version "<ocs_api_version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "Random data" to "randomfile.txt"
When user "Alice" shares file "randomfile.txt" with user "Brian" with permissions "0" using the sharing API
Then the OCS status code should be "400"
And the HTTP status code should be "<http_status_code>"
And the sharing API should report that no shares are shared with user "Brian"
And as "Brian" file "/Shares/randomfile.txt" should not exist
And as "Brian" file "randomfile.txt" should not exist
Examples:
| ocs_api_version | http_status_code |
| 1 | 200 |
| 2 | 400 |
Scenario Outline: Creating a share of a folder with no permissions should fail
Given using OCS API version "<ocs_api_version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "/afolder"
When user "Alice" shares folder "afolder" with user "Brian" with permissions "0" using the sharing API
Then the OCS status code should be "400"
And the HTTP status code should be "<http_status_code>"
And the sharing API should report that no shares are shared with user "Brian"
And as "Brian" folder "/Shares/afolder" should not exist
And as "Brian" folder "afolder" should not exist
Examples:
| ocs_api_version | http_status_code |
| 1 | 200 |
| 2 | 400 |
@issue-ocis-2133
Scenario Outline: Creating a share of a folder with a user, the default permissions are all permissions(31)
Given using OCS API version "<ocs_api_version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "/FOLDER"
When user "Alice" shares folder "/FOLDER" with user "Brian" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
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/FOLDER |
| path | /FOLDER |
| permissions | all |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| item_type | folder |
| mimetype | httpd/unix-directory |
| storage_id | ANY_VALUE |
| share_type | user |
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
@issue-ocis-reva-34
Scenario Outline: Creating a share of a file with a group, the default permissions are read(1)+update(2)+can-share(16)
Given using OCS API version "<ocs_api_version>"
And group "grp1" has been created
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
When user "Alice" shares file "/textfile0.txt" with group "grp1" using the sharing API
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" sharing with group "grp1" should include
| share_with | grp1 |
| share_with_displayname | grp1 |
| file_target | /Shares/textfile0.txt |
| path | /textfile0.txt |
| permissions | share,read,update |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| item_type | file |
| mimetype | text/plain |
| storage_id | ANY_VALUE |
| share_type | group |
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
@issue-ocis-reva-34
Scenario Outline: Creating a share of a folder with a group, the default permissions are all permissions(31)
Given using OCS API version "<ocs_api_version>"
And group "grp1" has been created
And user "Alice" has created folder "/FOLDER"
When user "Alice" shares folder "/FOLDER" with group "grp1" using the sharing API
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" sharing with user "Brian" should include
| share_with | grp1 |
| share_with_displayname | grp1 |
| file_target | /Shares/FOLDER |
| path | /FOLDER |
| permissions | all |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| item_type | folder |
| mimetype | httpd/unix-directory |
| storage_id | ANY_VALUE |
| share_type | group |
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
@smokeTest
Scenario Outline: Share of folder to a group
Given using OCS API version "<ocs_api_version>"
And these users have been created with default attributes and without skeleton files:
| username |
| 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 uploaded file with content "file in parent folder" to "/PARENT/parent.txt"
When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API
And user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API
And user "Carol" accepts share "/PARENT" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "<ocs_status_code>"
And the HTTP status code of responses on all endpoints should be "200"
And user "Brian" should see the following elements
| /Shares/PARENT/ |
| /Shares/PARENT/parent.txt |
And user "Carol" should see the following elements
| /Shares/PARENT/ |
| /Shares/PARENT/parent.txt |
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
@smokeTest @skipOnReva # reva doesn't have a pre-created admin user
Scenario Outline: User included in multiple groups receives a share from the admin
Given using OCS API version "<ocs_api_version>"
And group "grp1" has been created
And group "grp2" has been created
And user "Alice" has been added to group "grp1"
And user "Alice" has been added to group "grp2"
And admin has created folder "/PARENT"
When user "admin" shares folder "/PARENT" with group "grp1" using the sharing API
And user "Alice" accepts share "/PARENT" offered by user "admin" using the sharing API
Then the OCS status code of responses on all endpoints should be "<ocs_status_code>"
And the HTTP status code of responses on all endpoints should be "200"
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
@smokeTest
Scenario Outline: user included in multiple groups, shares a folder with a group
Given using OCS API version "<ocs_api_version>"
And these users have been created with default attributes and without skeleton files:
| username |
| Brian |
And group "grp1" has been created
And group "grp2" has been created
And user "Alice" has been added to group "grp1"
And user "Alice" has been added to group "grp2"
And user "Brian" has been added to group "grp1"
And user "Brian" has been added to group "grp2"
And user "Alice" has created folder "/PARENT"
When user "Alice" shares folder "/PARENT" with group "grp1" 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 "<ocs_status_code>"
And the HTTP status code of responses on all endpoints should be "200"
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: sharing again an own file while belonging to a group
Given using OCS API version "<ocs_api_version>"
And user "Brian" has been created with default attributes and without skeleton files
And group "grp1" has been created
And user "Alice" has been added to group "grp1"
And user "Brian" has been added to group "grp1"
And user "Brian" has uploaded file with content "ownCloud test text file 0" to "/randomfile.txt"
And user "Brian" has shared file "randomfile.txt" with group "grp1"
And user "Brian" has deleted the last share
When user "Brian" shares file "/randomfile.txt" with group "grp1" using the sharing API
And user "Alice" accepts share "/randomfile.txt" offered by user "Brian" using the sharing API
Then the OCS status code of responses on all endpoints should be "<ocs_status_code>"
And the HTTP status code of responses on all endpoints should be "200"
And as "Alice" file "/Shares/randomfile.txt" should exist
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
@issue-ocis-2201
Scenario Outline: sharing subfolder of already shared folder, GET result is correct
Given using OCS API version "<ocs_api_version>"
And these users have been created with default attributes and without skeleton files:
| username |
| Brian |
| Carol |
| David |
| Emily |
And user "Alice" has created folder "/folder1"
And user "Alice" has shared folder "/folder1" with user "Brian"
And user "Alice" has shared folder "/folder1" with user "Carol"
And user "Alice" has created folder "/folder1/folder2"
And user "Alice" has shared folder "/folder1/folder2" with user "David"
And user "Alice" has shared folder "/folder1/folder2" with user "Emily"
When user "Alice" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/shares"
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
And the response should contain 4 entries
And folder "/folder1" should be included as path in the response
And folder "/folder1/folder2" should be included as path in the response
When user "Alice" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/shares?path=/folder1/folder2"
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
And the response should contain 2 entries
And folder "/folder1" should not be included as path in the response
And folder "/folder1/folder2" should be included as path in the response
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: user shares a file with file name longer than 64 chars to another user
Given using OCS API version "<ocs_api_version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
And user "Alice" has moved file "textfile0.txt" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt"
When user "Alice" shares file "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" with user "Brian" using the sharing API
And user "Brian" accepts share "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "<ocs_status_code>"
And the HTTP status code of responses on all endpoints should be "200"
And as "Brian" file "/Shares/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" should exist
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: user shares a file with file name longer than 64 chars to a group
Given using OCS API version "<ocs_api_version>"
And group "grp1" has been created
And user "Brian" has been created with default attributes and without skeleton files
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
And user "Alice" has moved file "textfile0.txt" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt"
When user "Alice" shares file "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" with group "grp1" using the sharing API
And user "Brian" accepts share "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "<ocs_status_code>"
And the HTTP status code of responses on all endpoints should be "200"
And as "Brian" file "/Shares/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog.txt" should exist
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: user shares a folder with folder name longer than 64 chars to another user
Given using OCS API version "<ocs_api_version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "ownCloud test" to "/textfile0.txt"
And user "Alice" has created folder "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog"
And user "Alice" has moved file "textfile0.txt" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog/textfile0.txt"
When user "Alice" shares folder "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" with user "Brian" using the sharing API
And user "Brian" accepts share "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "<ocs_status_code>"
And the HTTP status code of responses on all endpoints should be "200"
And the content of file "/Shares/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog/textfile0.txt" for user "Brian" should be "ownCloud test"
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: user shares a folder with folder name longer than 64 chars to a group
Given using OCS API version "<ocs_api_version>"
And group "grp1" has been created
And user "Brian" has been created with default attributes and without skeleton files
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file with content "ownCloud test" to "/textfile0.txt"
And user "Alice" has created folder "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog"
And user "Alice" has moved file "textfile0.txt" to "aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog/textfile0.txt"
When user "Alice" shares folder "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" with group "grp1" using the sharing API
And user "Brian" accepts share "/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "<ocs_status_code>"
And the HTTP status code of responses on all endpoints should be "200"
And the content of file "/Shares/aquickbrownfoxjumpsoveraverylazydogaquickbrownfoxjumpsoveralazydog/textfile0.txt" for user "Brian" should be "ownCloud test"
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
@issue-ocis-reva-11
Scenario: share with user when username contains capital letters
Given these users have been created without skeleton files:
| username |
| brian |
And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt"
When user "Alice" shares file "/randomfile.txt" with user "BRIAN" 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 | brian |
| file_target | /Shares/randomfile.txt |
| path | /randomfile.txt |
| permissions | share,read,update |
| uid_owner | %username% |
When user "brian" accepts share "/randomfile.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 user "brian" should see the following elements
| /Shares/randomfile.txt |
And the content of file "Shares/randomfile.txt" for user "brian" should be "Random data"
@skipOnLDAP
Scenario: creating a new share with user of a group when username contains capital letters
Given these users have been created without skeleton files:
| username |
| Brian |
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt"
And user "Alice" has shared file "randomfile.txt" with group "grp1"
When user "Brian" accepts share "/randomfile.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 user "Brian" should see the following elements
| /Shares/randomfile.txt |
And the content of file "/Shares/randomfile.txt" for user "Brian" should be "Random data"
@issue-ocis-reva-34
Scenario Outline: Share of folder to a group with emoji in the name
Given using OCS API version "<ocs_api_version>"
And these users have been created with default attributes and without skeleton files:
| username |
| Brian |
| Carol |
And group "😀 😁" has been created
And user "Brian" has been added to group "😀 😁"
And user "Carol" has been added to group "😀 😁"
And user "Alice" has created folder "/PARENT"
And user "Alice" has uploaded file with content "file in parent folder" to "/PARENT/parent.txt"
When user "Alice" shares folder "/PARENT" with group "😀 😁" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
And user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API
And the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
And user "Carol" accepts share "/PARENT" offered by user "Alice" using the sharing API
And the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
And user "Brian" should see the following elements
| /Shares/PARENT/ |
| /Shares/PARENT/parent.txt |
And user "Carol" should see the following elements
| /Shares/PARENT/ |
| /Shares/PARENT/parent.txt |
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
@skipOnEncryptionType:user-keys @encryption-issue-132 @skipOnLDAP @skipOnGraph
Scenario Outline: share with a group and then add a user to that group
Given using OCS API version "<ocs_api_version>"
And these users have been created with default attributes and without skeleton files:
| username |
| Brian |
| Carol |
And these groups have been created:
| groupname |
| grp1 |
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file with content "some content" to "lorem.txt"
When user "Alice" shares file "lorem.txt" with group "grp1" using the sharing API
And user "Brian" accepts share "/lorem.txt" offered by user "Alice" using the sharing API
And the administrator adds user "Carol" to group "grp1" using the provisioning API
And user "Carol" accepts share "/lorem.txt" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "<ocs_status_code>"
And the HTTP status code of responses on all endpoints should be "200"
And the content of file "/Shares/lorem.txt" for user "Brian" should be "some content"
And the content of file "/Shares/lorem.txt" for user "Carol" should be "some content"
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
@skipOnLDAP
# deleting an LDAP group is not relevant or possible using the provisioning API
Scenario Outline: shares shared to deleted group should not be available
Given using OCS API version "<ocs_api_version>"
And these users have been created with default attributes and without skeleton files:
| username |
| 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 uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
And user "Alice" has shared file "/textfile0.txt" with group "grp1"
When user "Alice" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/shares"
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" sharing with group "grp1" should include
| share_with | grp1 |
| file_target | <path> |
| path | /textfile0.txt |
| uid_owner | %username% |
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 as "Brian" file "/Shares/textfile0.txt" should exist
And as "Carol" file "/Shares/textfile0.txt" should exist
When the administrator deletes group "grp1" using the provisioning API
And user "Alice" sends HTTP method "GET" to OCS API endpoint "/apps/files_sharing/api/v1/shares"
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
And file "/textfile0.txt" should not be included as path in the response
And as "Brian" file "/Shares/textfile0.txt" should not exist
And as "Carol" file "/Shares/textfile0.txt" should not exist
@skipOnOcis
Examples:
| ocs_api_version | ocs_status_code | path |
| 1 | 100 | /Shares/textfile0.txt |
| 2 | 200 | /Shares/textfile0.txt |
@skipOnOcV10 @issue-ocis-2441
Examples:
| ocs_api_version | ocs_status_code | path |
| 1 | 100 | /textfile0.txt |
| 2 | 200 | /textfile0.txt |
@skipOnFilesClassifier @issue-files-classifier-291 @issue-ocis-2146
Scenario: Share a file by multiple channels and download from sub-folder and direct file share
Given these users have been created with default attributes and without skeleton files:
| username |
| 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 "/common"
And user "Alice" has created folder "/common/sub"
And user "Alice" has shared folder "common" with group "grp1"
And user "Brian" has accepted share "/common" offered by user "Alice"
And user "Carol" has accepted share "/common" offered by user "Alice"
And user "Brian" has uploaded file with content "ownCloud" to "/textfile0.txt"
And user "Brian" has shared file "textfile0.txt" with user "Carol"
And user "Carol" has accepted share "/textfile0.txt" offered by user "Brian"
And user "Brian" has moved file "/textfile0.txt" to "/Shares/common/textfile0.txt"
And user "Brian" has moved file "/Shares/common/textfile0.txt" to "/Shares/common/sub/textfile0.txt"
When user "Carol" uploads file "filesForUpload/file_to_overwrite.txt" to "/Shares/textfile0.txt" using the WebDAV API
Then the HTTP status code should be "204"
And the content of file "/Shares/common/sub/textfile0.txt" for user "Carol" should be "BLABLABLA" plus end-of-line
And the content of file "/Shares/textfile0.txt" for user "Carol" should be "BLABLABLA" plus end-of-line
And user "Carol" should see the following elements
| /Shares/common/sub/textfile0.txt |
| /Shares/textfile0.txt |
And the content of file "/Shares/common/sub/textfile0.txt" for user "Brian" should be "BLABLABLA" plus end-of-line
And the content of file "/common/sub/textfile0.txt" for user "Alice" should be "BLABLABLA" plus end-of-line
@issue-enterprise-3896 @issue-ocis-2201
Scenario Outline: sharing back to resharer is allowed
Given these users have been created with default attributes and without skeleton files:
| username |
| Brian |
| Carol |
And user "Alice" has created folder "userZeroFolder"
And user "Alice" has shared folder "userZeroFolder" with user "Brian"
And user "Brian" has accepted share "/userZeroFolder" offered by user "Alice"
And user "Brian" has created folder "/Shares/userZeroFolder/userOneFolder"
And user "Brian" has shared folder "/Shares/userZeroFolder/userOneFolder" with user "Carol" with permissions "read, share"
And user "Carol" has accepted share "<pending_share_path>" offered by user "Brian"
When user "Carol" shares folder "/Shares/userOneFolder" with user "Brian" using the sharing API
Then the HTTP status code should be "200"
# Then the HTTP status code should be "405"
And the sharing API should report to user "Brian" that no shares are in the pending state
And as "Brian" folder "/Shares/userOneFolder" should not exist
Examples:
| pending_share_path |
| /userOneFolder |
@issue-enterprise-3896 @issue-ocis-2201
Scenario Outline: sharing back to original sharer is allowed
Given these users have been created with default attributes and without skeleton files:
| username |
| Brian |
| Carol |
And user "Alice" has created folder "userZeroFolder"
And user "Alice" has shared folder "userZeroFolder" with user "Brian"
And user "Brian" has accepted share "/userZeroFolder" offered by user "Alice"
And user "Brian" has created folder "/Shares/userZeroFolder/userOneFolder"
And user "Brian" has shared folder "/Shares/userZeroFolder/userOneFolder" with user "Carol" with permissions "read, share"
And user "Carol" has accepted share "<pending_share_path>" offered by user "Brian"
When user "Carol" shares folder "/Shares/userOneFolder" with user "Alice" using the sharing API
Then the HTTP status code should be "200"
# Then the HTTP status code should be "405"
And the sharing API should report to user "Alice" that no shares are in the pending state
And as "Alice" folder "/Shares/userOneFolder" should not exist
Examples:
| pending_share_path |
| /userOneFolder |
@issue-enterprise-3896 @issue-ocis-2201
Scenario Outline: sharing a subfolder to a user that already received parent folder share
Given these users have been created with default attributes and without skeleton files:
| username |
| Brian |
| Carol |
| David |
And user "Alice" has created folder "userZeroFolder"
And user "Alice" has shared folder "userZeroFolder" with user "Brian"
And user "Alice" has shared folder "userZeroFolder" with user "Carol"
And user "Brian" has accepted share "/userZeroFolder" offered by user "Alice"
And user "Carol" has accepted share "/userZeroFolder" offered by user "Alice"
And user "Brian" has created folder "/Shares/userZeroFolder/userOneFolder"
And user "Brian" has shared folder "/Shares/userZeroFolder/userOneFolder" with user "David" with permissions "read, share"
And user "David" has accepted share "<pending_share_path>" offered by user "Brian"
When user "David" shares folder "/Shares/userOneFolder" with user "Carol" using the sharing API
Then the HTTP status code should be "200"
# Then the HTTP status code should be "405"
And the sharing API should report to user "Carol" that no shares are in the pending state
And as "Carol" folder "/Shares/userOneFolder" should not exist
Examples:
| pending_share_path |
| /userOneFolder |
@smokeTest
Scenario Outline: Creating a share of a renamed file
Given using OCS API version "<ocs_api_version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
And user "Alice" has moved file "/textfile0.txt" to "/renamed.txt"
When user "Alice" shares file "renamed.txt" with user "Brian" using the sharing API
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" sharing with user "Brian" should include
| share_with | %username% |
| share_with_displayname | %displayname% |
| file_target | /Shares/renamed.txt |
| path | /renamed.txt |
| permissions | share,read,update |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| item_type | file |
| mimetype | text/plain |
| storage_id | ANY_VALUE |
| share_type | user |
When user "Brian" accepts share "/renamed.txt" offered by user "Alice" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
And the content of file "/Shares/renamed.txt" for user "Brian" should be "ownCloud test text file 0"
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
@issue-ocis-903
Scenario Outline: shares to a deleted user should not be listed as shares for the sharer
Given using OCS API version "<ocs_api_version>"
And these users have been created with default attributes and without skeleton files:
| username |
| Brian |
| Carol |
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
And user "Alice" has shared file "textfile0.txt" with user "Carol"
And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
And user "Carol" has accepted share "/textfile0.txt" offered by user "Alice"
And the administrator has deleted user "Brian" using the provisioning API
When user "Alice" gets all the shares from the file "textfile0.txt" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
And user "Carol" should be included in the response
But user "Brian" should not be included in the response
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
@issue-ocis-719
Scenario Outline: Creating a share of a renamed file when another share exists
Given using OCS API version "<ocs_api_version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "/Folder1"
And user "Alice" has created folder "/Folder2"
And user "Alice" has shared folder "/Folder1" with user "Brian"
And user "Brian" has accepted share "/Folder1" offered by user "Alice"
And user "Alice" has moved file "/Folder2" to "/renamedFolder2"
When user "Alice" shares folder "/renamedFolder2" with user "Brian" using the sharing API
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" sharing with user "Brian" should include
| share_with | %username% |
| share_with_displayname | %displayname% |
| file_target | /Shares/renamedFolder2 |
| path | /renamedFolder2 |
| permissions | all |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| item_type | folder |
| mimetype | httpd/unix-directory |
| storage_id | ANY_VALUE |
| share_type | user |
When user "Brian" accepts share "/renamedFolder2" offered by user "Alice" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
And as "Brian" folder "/Shares/renamedFolder2" should exist
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
@issue-ocis-1710
Scenario Outline: Sharing a same file twice to the same group is not possible
Given using OCS API version "<ocs-api-version>"
And group "grp1" has been created
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with group "grp1"
When user "Alice" shares file "textfile0.txt" with group "grp1" using the sharing API
Then the HTTP status code should be "<http-status>"
And the OCS status code should be "403"
And the OCS status message should be "Path already shared with this group"
Examples:
| ocs-api-version | http-status |
| 1 | 200 |
| 2 | 403 |
@issue-ocis-2215
Scenario Outline: Sharing the shares folder to users is not possible
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Carol" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
When user "Brian" shares folder "Shares" with user "Carol" using the sharing API
Then the HTTP status code should be "<http-status>"
And the OCS status code should be "403"
And the OCS status message should be "Path contains files shared with you"
Examples:
| ocs-api-version | http-status |
| 1 | 200 |
| 2 | 403 |
@issue-ocis-2215
Scenario Outline: Sharing the shares folder to groups is not possible
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Carol" has been created with default attributes and without skeleton files
And group "share_group" has been created
And user "Carol" has been added to group "share_group"
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
When user "Brian" shares folder "Shares" with group "share_group" using the sharing API
Then the HTTP status code should be "<http-status>"
And the OCS status code should be "403"
And the OCS status message should be "Path contains files shared with you"
Examples:
| ocs-api-version | http-status |
| 1 | 200 |
| 2 | 403 |
@issue-ocis-2215
Scenario Outline: Sharing the shares folder as public link is not possible
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
When user "Brian" creates a public link share of folder "Shares" using the sharing API
Then the HTTP status code should be "<http-status>"
And the OCS status code should be "403"
And the OCS status message should be "Path contains files shared with you"
Examples:
| ocs-api-version | http-status |
| 1 | 200 |
| 2 | 403 |
tests/acceptance/features/coreApiShareManagementBasicToShares/deleteShareFromShares.feature
+227
View File
@@ -0,0 +1,227 @@
@api @files_sharing-app-required @issue-ocis-1328 @issue-ocis-1289
Feature: sharing
Background:
Given the administrator has set the default folder for received shares to "Shares"
And auto-accept shares has been disabled
And these users have been created with default attributes and without skeleton files:
| username |
| Alice |
| Brian |
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
Scenario Outline: Delete all group shares
Given using OCS API version "<ocs_api_version>"
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has shared file "textfile0.txt" with group "grp1"
And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
And user "Brian" has moved file "/Shares/textfile0.txt" to "/Shares/anotherName.txt"
When user "Alice" deletes the last share using the sharing API
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
And user "Brian" should not see the share id of the last share
And as "Brian" file "/Shares/textfile0.txt" should not exist
And as "Brian" file "/Shares/anotherName.txt" should not exist
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
@smokeTest
Scenario Outline: delete a share
Given using OCS API version "<ocs_api_version>"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
When user "Alice" deletes the last share using the sharing API
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
And the last share id should not be included in the response
And as "Brian" file "/Shares/textfile0.txt" should not exist
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: orphaned shares
Given using OCS API version "1"
And user "Alice" has created folder "/common"
And user "Alice" has created folder "/common/sub"
And user "Alice" has shared folder "/common/sub" with user "Brian"
And user "Brian" has accepted share "<pending_share_path>" offered by user "Alice"
When user "Alice" deletes folder "/common" using the WebDAV API
Then the HTTP status code should be "204"
And as "Brian" folder "/Shares/sub" should not exist
And as "Brian" folder "/sub" should not exist
Examples:
| pending_share_path |
| /sub |
@smokeTest @files_trashbin-app-required
Scenario: deleting a file out of a share as recipient creates a backup for the owner
Given using OCS API version "1"
And user "Alice" has created folder "/shared"
And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt"
And user "Alice" has shared folder "/shared" with user "Brian"
And user "Brian" has accepted share "/shared" offered by user "Alice"
When user "Brian" deletes file "/Shares/shared/shared_file.txt" using the WebDAV API
Then the HTTP status code should be "204"
And as "Brian" file "/Shares/shared/shared_file.txt" should not exist
And as "Alice" file "/shared/shared_file.txt" should not exist
And as "Alice" file "/shared_file.txt" should exist in the trashbin
And as "Brian" file "/shared_file.txt" should exist in the trashbin
@files_trashbin-app-required
Scenario: deleting a folder out of a share as recipient creates a backup for the owner
Given using OCS API version "1"
And user "Alice" has created folder "/shared"
And user "Alice" has created folder "/shared/sub"
And user "Alice" has moved file "/textfile0.txt" to "/shared/sub/shared_file.txt"
And user "Alice" has shared folder "/shared" with user "Brian"
And user "Brian" has accepted share "/shared" offered by user "Alice"
When user "Brian" deletes folder "/Shares/shared/sub" using the WebDAV API
Then the HTTP status code should be "204"
And as "Brian" folder "/Shares/shared/sub" should not exist
And as "Alice" folder "/shared/sub" should not exist
And as "Alice" folder "/sub" should exist in the trashbin
And as "Alice" file "/sub/shared_file.txt" should exist in the trashbin
And as "Brian" folder "/sub" should exist in the trashbin
And as "Brian" file "/sub/shared_file.txt" should exist in the trashbin
@smokeTest
Scenario Outline: unshare from self
And group "grp1" has been created
And these users have been created with default attributes and without skeleton files:
| username |
| Carol |
And user "Brian" has been added to group "grp1"
And user "Carol" has been added to group "grp1"
And user "Carol" has created folder "PARENT"
And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt"
And user "Carol" has shared file "/PARENT/parent.txt" with group "grp1"
And user "Brian" has accepted share "<pending_share_path>" offered by user "Carol"
And user "Carol" has stored etag of element "/PARENT"
And user "Brian" has stored etag of element "/"
And user "Brian" has stored etag of element "/Shares"
When user "Brian" unshares file "/Shares/parent.txt" using the WebDAV API
Then the HTTP status code should be "204"
And the etag of element "/" of user "Brian" should have changed
And the etag of element "/Shares" of user "Brian" should have changed
And the etag of element "/PARENT" of user "Carol" should not have changed
Examples:
| pending_share_path |
| /parent.txt |
Scenario: sharee of a read-only share folder tries to delete the shared folder
Given using OCS API version "1"
And user "Alice" has created folder "/shared"
And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt"
And user "Alice" has shared folder "shared" with user "Brian" with permissions "read"
And user "Brian" has accepted share "/shared" offered by user "Alice"
When user "Brian" deletes file "/Shares/shared/shared_file.txt" using the WebDAV API
Then the HTTP status code should be "403"
And as "Alice" file "/shared/shared_file.txt" should exist
And as "Brian" file "/Shares/shared/shared_file.txt" should exist
Scenario: sharee of a upload-only shared folder tries to delete a file in the shared folder
Given using OCS API version "1"
And user "Alice" has created folder "/shared"
And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt"
And user "Alice" has shared folder "shared" with user "Brian" with permissions "create"
And user "Brian" has accepted share "/shared" offered by user "Alice"
When user "Brian" deletes file "/Shares/shared/shared_file.txt" using the WebDAV API
Then the HTTP status code should be "403"
And as "Alice" file "/shared/shared_file.txt" should exist
# Note: for Brian, the file does not "exist" because he only has "create" permission, not "read"
And as "Brian" file "/Shares/shared/shared_file.txt" should not exist
Scenario: sharee of an upload-only shared folder tries to delete their file in the folder
Given using OCS API version "1"
And user "Alice" has created folder "/shared"
And user "Alice" has shared folder "shared" with user "Brian" with permissions "create"
And user "Brian" has accepted share "/shared" offered by user "Alice"
And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/Shares/shared/textfile.txt"
When user "Brian" deletes file "/Shares/shared/textfile.txt" using the WebDAV API
Then the HTTP status code should be "403"
And as "Alice" file "/shared/textfile.txt" should exist
# Note: for Brian, the file does not "exist" because he only has "create" permission, not "read"
And as "Brian" file "/Shares/shared/textfile.txt" should not exist
Scenario Outline: A Group share recipient tries to delete the share
Given using OCS API version "<ocs_api_version>"
And group "grp1" has been created
And these users have been created with default attributes and without skeleton files:
| username |
| Carol |
And user "Brian" has been added to group "grp1"
And user "Carol" has been added to group "grp1"
And user "Alice" has created folder "/shared"
And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt"
And user "Alice" has shared entry "<entry_to_share>" with group "grp1"
And user "Brian" has accepted share "<pending_entry>" offered by user "Alice"
And user "Carol" has accepted share "<pending_entry>" offered by user "Alice"
When user "Brian" deletes the last share of user "Alice" using the sharing API
Then the OCS status code should be "404"
And the HTTP status code should be "<http_status_code>"
And as "Alice" entry "<entry_to_share>" should exist
And as "Brian" entry "<received_entry>" should exist
And as "Carol" entry "<received_entry>" should exist
Examples:
| entry_to_share | ocs_api_version | http_status_code | received_entry | pending_entry |
| /shared/shared_file.txt | 1 | 200 | /Shares/shared_file.txt | /Shares/shared_file.txt |
| /shared/shared_file.txt | 2 | 404 | /Shares/shared_file.txt | /Shares/shared_file.txt |
| /shared | 1 | 200 | /Shares/shared | /Shares/shared |
| /shared | 2 | 404 | /Shares/shared | /Shares/shared |
Scenario Outline: An individual share recipient tries to delete the share
Given using OCS API version "<ocs_api_version>"
And user "Alice" has created folder "/shared"
And user "Alice" has moved file "/textfile0.txt" to "/shared/shared_file.txt"
And user "Alice" has shared entry "<entry_to_share>" with user "Brian"
And user "Brian" has accepted share "<pending_entry>" offered by user "Alice"
When user "Brian" deletes the last share of user "Alice" using the sharing API
Then the OCS status code should be "404"
And the HTTP status code should be "<http_status_code>"
And as "Alice" entry "<entry_to_share>" should exist
And as "Brian" entry "<received_entry>" should exist
Examples:
| entry_to_share | ocs_api_version | http_status_code | received_entry | pending_entry |
| /shared/shared_file.txt | 1 | 200 | /Shares/shared_file.txt | /Shares/shared_file.txt |
| /shared/shared_file.txt | 2 | 404 | /Shares/shared_file.txt | /Shares/shared_file.txt |
| /shared | 1 | 200 | /Shares/shared | /Shares/shared |
| /shared | 2 | 404 | /Shares/shared | /Shares/shared |
@issue-ocis-720
Scenario Outline: request PROPFIND after sharer deletes the collaborator
Given using OCS API version "<ocs_api_version>"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
When user "Alice" deletes the last share using the sharing API
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
When user "Brian" requests "/remote.php/dav/files/%username%" with "PROPFIND" using basic auth
Then the HTTP status code should be "207"
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
@issue-ocis-1229
Scenario Outline: delete a share with wrong authentication
Given using OCS API version "<ocs_api_version>"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
When user "Brian" tries to delete the last share of user "Alice" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "<http_status_code>"
Examples:
| ocs_api_version | ocs_status_code | http_status_code |
| 1 | 404 | 200 |
| 2 | 404 | 404 |
tests/acceptance/features/coreApiShareManagementBasicToShares/excludeGroupFromReceivingSharesToSharesFolder.feature
+174
View File
@@ -0,0 +1,174 @@
@api @files_sharing-app-required
Feature: Exclude groups from receiving shares
As an admin
I want to exclude groups from receiving shares
So that users do not mistakenly share with groups they should not e.g. huge meta groups
Background:
Given the administrator has set the default folder for received shares to "Shares"
And auto-accept shares has been disabled
And these users have been created with default attributes and without skeleton files:
| username |
| Alice |
| Brian |
| Carol |
| David |
And group "grp1" has been created
And group "grp2" has been created
And user "Brian" has been added to group "grp1"
And user "David" has been added to group "grp2"
@skipOnOcis
Scenario Outline: user cannot share with a group that is excluded from receiving shares but can share with other groups
Given using OCS API version "<ocs_api_version>"
And user "Alice" has created folder "PARENT"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt"
And the administrator has added group "grp1" to the exclude groups from receiving shares list
When user "Alice" shares file "fileToShare.txt" with group "grp1" using the sharing API
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the OCS status message should be "The group is blacklisted for sharing"
And the sharing API should report to user "Brian" that no shares are in the pending state
When user "Alice" shares folder "PARENT" with group "grp1" using the sharing API
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the OCS status message should be "The group is blacklisted for sharing"
And the sharing API should report to user "Brian" that no shares are in the pending state
When user "Alice" shares file "fileToShare.txt" with group "grp2" using the sharing API
And user "Alice" shares folder "PARENT" with group "grp2" using the sharing API
And user "David" accepts share "/fileToShare.txt" offered by user "Alice" using the sharing API
And user "David" accepts share "/PARENT" offered by user "Alice" using the sharing API
Then as "David" file "/Shares/fileToShare.txt" should exist
And as "David" folder "/Shares/PARENT" should exist
Examples:
| ocs_api_version | http_status_code |
| 1 | 200 |
| 2 | 403 |
@skipOnOcis
Scenario Outline: exclude multiple groups from receiving shares stops the user to share with any of them
Given using OCS API version "<ocs_api_version>"
And group "grp3" has been created
And user "Brian" has been added to group "grp3"
And the administrator has added group "grp1, grp2, grp3" to the exclude group from sharing list
And user "Alice" has created folder "PARENT"
And user "Alice" has created folder "PARENT/CHILD"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt"
And the administrator has added group "grp1" to the exclude groups from receiving shares list
And the administrator has added group "grp2" to the exclude groups from receiving shares list
And the administrator has added group "grp3" to the exclude groups from receiving shares list
When user "Alice" shares file "fileToShare.txt" with group "grp1" using the sharing API
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the OCS status message should be "The group is blacklisted for sharing"
And the sharing API should report to user "Brian" that no shares are in the pending state
When user "Alice" shares folder "PARENT" with group "grp2" using the sharing API
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the OCS status message should be "The group is blacklisted for sharing"
And the sharing API should report to user "David" that no shares are in the pending state
When user "Alice" shares folder "PARENT/CHILD" with group "grp3" using the sharing API
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the OCS status message should be "The group is blacklisted for sharing"
And the sharing API should report to user "Brian" that no shares are in the pending state
Examples:
| ocs_api_version | http_status_code |
| 1 | 200 |
| 2 | 403 |
@skipOnOcis
Scenario Outline: user cannot reshare a received share with a group that is excluded from receiving shares but can share with other groups
Given using OCS API version "<ocs_api_version>"
And user "Carol" has created folder "PARENT"
And user "Carol" has uploaded file "filesForUpload/textfile.txt" to "textfile0.txt"
And user "Carol" has shared file "textfile0.txt" with user "Alice"
And user "Alice" has accepted share "/textfile0.txt" offered by user "Carol"
And user "Carol" has shared folder "PARENT" with user "Alice"
And user "Alice" has accepted share "/PARENT" offered by user "Carol"
And the administrator has added group "grp1" to the exclude groups from receiving shares list
When user "Alice" shares file "/Shares/textfile0.txt" with group "grp1" using the sharing API
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the OCS status message should be "The group is blacklisted for sharing"
And the sharing API should report to user "Brian" that no shares are in the pending state
When user "Alice" shares folder "/Shares/PARENT" with group "grp1" using the sharing API
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the OCS status message should be "The group is blacklisted for sharing"
And the sharing API should report to user "Brian" that no shares are in the pending state
When user "Alice" shares file "/Shares/textfile0.txt" with group "grp2" using the sharing API
And user "Alice" shares folder "/Shares/PARENT" with group "grp2" using the sharing API
And user "David" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API
And user "David" accepts share "/PARENT" offered by user "Alice" using the sharing API
Then as "David" file "/Shares/textfile0.txt" should exist
And as "David" folder "/Shares/PARENT" should exist
Examples:
| ocs_api_version | http_status_code |
| 1 | 200 |
| 2 | 403 |
Scenario Outline: sharing with a user that is part of a group that is excluded from receiving shares still works
Given using OCS API version "<ocs_api_version>"
And user "Alice" has created folder "PARENT"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt"
And the administrator has added group "grp1" to the exclude groups from receiving shares list
When user "Alice" shares file "fileToShare.txt" with user "Brian" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
When user "Alice" shares folder "PARENT" with user "Brian" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
When user "Brian" accepts share "/fileToShare.txt" offered by user "Alice" using the sharing API
And user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API
Then as "Brian" file "/Shares/fileToShare.txt" should exist
And as "Brian" folder "/Shares/PARENT" should exist
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: sharing with a user that is part of a group that is excluded from receiving shares using an other group works
Given using OCS API version "<ocs_api_version>"
And group "grp3" has been created
And user "Brian" has been added to group "grp3"
And user "Alice" has created folder "PARENT"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt"
And the administrator has added group "grp1" to the exclude groups from receiving shares list
When user "Alice" shares file "fileToShare.txt" with group "grp3" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
When user "Alice" shares folder "PARENT" with group "grp3" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
When user "Brian" accepts share "/fileToShare.txt" offered by user "Alice" using the sharing API
And user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API
Then as "Brian" file "/Shares/fileToShare.txt" should exist
And as "Brian" folder "/Shares/PARENT" should exist
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: a user that is part of a group that is excluded from receiving shares still can initiate shares
Given using OCS API version "<ocs_api_version>"
And user "Brian" has created folder "PARENT"
And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt"
And the administrator has added group "grp1" to the exclude groups from receiving shares list
When user "Brian" shares file "fileToShare.txt" with user "Carol" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
And user "Brian" shares folder "PARENT" with user "Carol" using the sharing API
And the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "200"
When user "Carol" accepts share "/fileToShare.txt" offered by user "Brian" using the sharing API
And user "Carol" accepts share "/PARENT" offered by user "Brian" using the sharing API
Then as "Carol" file "/Shares/fileToShare.txt" should exist
And as "Carol" folder "/Shares/PARENT" should exist
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |