copy feature files from core
This commit is contained in:
Saw-jan
+23
@@ -0,0 +1,23 @@
|
||||
@api @files_sharing-app-required @issue-ocis-1327
|
||||
Feature: shares are received in the default folder for received shares
|
||||
|
||||
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
|
||||
|
||||
|
||||
Scenario Outline: Do not allow sharing of the entire share_folder
|
||||
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
|
||||
And user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API
|
||||
And user "Brian" unshares folder "Shares/FOLDER" using the WebDAV API
|
||||
And user "Brian" shares folder "/Shares" with user "Alice" using the sharing API
|
||||
Then the OCS status code of responses on each endpoint should be "<ocs_status_code>" respectively
|
||||
And the HTTP status code of responses on each endpoint should be "<http_status_code>" respectively
|
||||
Examples:
|
||||
| ocs_api_version | ocs_status_code | http_status_code |
|
||||
| 1 | 100, 100, 404 | 200, 200, 204, 200 |
|
||||
| 2 | 200, 200, 404 | 200, 200, 204, 404 |
|
||||
+95
@@ -0,0 +1,95 @@
|
||||
@api @files_sharing-app-required
|
||||
Feature: sharing works when a username and group name are the same
|
||||
|
||||
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
|
||||
|
||||
@skipOnLDAP
|
||||
Scenario: creating a new share with user and a group having same name
|
||||
Given these users have been created without skeleton files:
|
||||
| username |
|
||||
| Brian |
|
||||
| Carol |
|
||||
And group "Brian" has been created
|
||||
And user "Carol" has been added to group "Brian"
|
||||
And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt"
|
||||
And user "Alice" has shared file "randomfile.txt" with group "Brian"
|
||||
And user "Carol" has accepted share "/randomfile.txt" offered by user "Alice"
|
||||
When user "Alice" shares file "randomfile.txt" with user "Brian" using the sharing API
|
||||
And user "Brian" accepts share "/randomfile.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
|
||||
| /Shares/randomfile.txt |
|
||||
And user "Carol" should see the following elements
|
||||
| /Shares/randomfile.txt |
|
||||
And the content of file "/Shares/randomfile.txt" for user "Brian" should be "Random data"
|
||||
And the content of file "/Shares/randomfile.txt" for user "Carol" should be "Random data"
|
||||
|
||||
@skipOnLDAP
|
||||
Scenario: creating a new share with group and a user having same name
|
||||
Given these users have been created without skeleton files:
|
||||
| username |
|
||||
| Brian |
|
||||
| Carol |
|
||||
And group "Brian" has been created
|
||||
And user "Carol" has been added to group "Brian"
|
||||
And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt"
|
||||
And user "Alice" has shared file "randomfile.txt" with user "Brian"
|
||||
And user "Brian" has accepted share "/randomfile.txt" offered by user "Alice"
|
||||
When user "Alice" shares file "randomfile.txt" with group "Brian" using the sharing API
|
||||
And user "Carol" accepts share "/randomfile.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
|
||||
| /Shares/randomfile.txt |
|
||||
And user "Carol" should see the following elements
|
||||
| /Shares/randomfile.txt |
|
||||
And the content of file "/Shares/randomfile.txt" for user "Brian" should be "Random data"
|
||||
And the content of file "/Shares/randomfile.txt" for user "Carol" should be "Random data"
|
||||
|
||||
@skipOnLDAP
|
||||
Scenario: creating a new share with user and a group having same name but different case
|
||||
Given these users have been created without skeleton files:
|
||||
| username |
|
||||
| Brian |
|
||||
| Carol |
|
||||
And group "brian" has been created
|
||||
And user "Carol" has been added to group "brian"
|
||||
And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt"
|
||||
And user "Alice" has shared file "randomfile.txt" with group "brian"
|
||||
And user "Carol" has accepted share "/randomfile.txt" offered by user "Alice"
|
||||
When user "Alice" shares file "randomfile.txt" with user "Brian" using the sharing API
|
||||
And user "Brian" accepts share "/randomfile.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
|
||||
| /Shares/randomfile.txt |
|
||||
And user "Carol" should see the following elements
|
||||
| /Shares/randomfile.txt |
|
||||
And the content of file "/Shares/randomfile.txt" for user "Brian" should be "Random data"
|
||||
And the content of file "/Shares/randomfile.txt" for user "Carol" should be "Random data"
|
||||
|
||||
@skipOnLDAP
|
||||
Scenario: creating a new share with group and a user having same name but different case
|
||||
Given these users have been created without skeleton files:
|
||||
| username |
|
||||
| Brian |
|
||||
| Carol |
|
||||
And group "brian" has been created
|
||||
And user "Carol" has been added to group "brian"
|
||||
And user "Alice" has uploaded file with content "Random data" to "/randomfile.txt"
|
||||
And user "Alice" has shared file "randomfile.txt" with user "Brian"
|
||||
And user "Brian" has accepted share "/randomfile.txt" offered by user "Alice"
|
||||
When user "Alice" shares file "randomfile.txt" with group "brian" using the sharing API
|
||||
And user "Carol" accepts share "/randomfile.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 see the following elements
|
||||
| /Shares/randomfile.txt |
|
||||
And user "Brian" should see the following elements
|
||||
| /Shares/randomfile.txt |
|
||||
And the content of file "/Shares/randomfile.txt" for user "Carol" should be "Random data"
|
||||
And the content of file "/Shares/randomfile.txt" for user "Brian" should be "Random data"
|
||||
+90
@@ -0,0 +1,90 @@
|
||||
@api @files_sharing-app-required @notToImplementOnOCIS
|
||||
Feature: share with groups, group names are case-sensitive
|
||||
|
||||
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
|
||||
And user "Alice" has uploaded file with content "ownCloud test text file 1" to "/textfile1.txt"
|
||||
And user "Alice" has uploaded file with content "ownCloud test text file 2" to "/textfile2.txt"
|
||||
And user "Alice" has uploaded file with content "ownCloud test text file 3" to "/textfile3.txt"
|
||||
|
||||
@skipOnLDAP @issue-ldap-250
|
||||
Scenario Outline: group names are case-sensitive, sharing with groups with different upper and lower case names
|
||||
Given using OCS API version "<ocs_api_version>"
|
||||
And group "<group_id1>" has been created
|
||||
And group "<group_id2>" has been created
|
||||
And group "<group_id3>" has been created
|
||||
And these users have been created with default attributes and without skeleton files:
|
||||
| username |
|
||||
| Brian |
|
||||
| Carol |
|
||||
| David |
|
||||
And user "Brian" has been added to group "<group_id1>"
|
||||
And user "Carol" has been added to group "<group_id2>"
|
||||
And user "David" has been added to group "<group_id3>"
|
||||
When user "Alice" shares file "textfile1.txt" with group "<group_id1>" 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 "/textfile1.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/textfile1.txt" for user "Brian" should be "ownCloud test text file 1"
|
||||
When user "Alice" shares file "textfile2.txt" with group "<group_id2>" using the sharing API
|
||||
Then the OCS status code should be "<ocs_status_code>"
|
||||
And the HTTP status code should be "200"
|
||||
When user "Carol" accepts share "/textfile2.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/textfile2.txt" for user "Carol" should be "ownCloud test text file 2"
|
||||
When user "Alice" shares file "textfile3.txt" with group "<group_id3>" using the sharing API
|
||||
Then the OCS status code should be "<ocs_status_code>"
|
||||
And the HTTP status code should be "200"
|
||||
When user "David" accepts share "/textfile3.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/textfile3.txt" for user "David" should be "ownCloud test text file 3"
|
||||
Examples:
|
||||
| ocs_api_version | group_id1 | group_id2 | group_id3 | ocs_status_code |
|
||||
| 1 | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | 100 |
|
||||
| 1 | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | 100 |
|
||||
| 1 | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | 100 |
|
||||
| 2 | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | 200 |
|
||||
| 2 | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | 200 |
|
||||
| 2 | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | 200 |
|
||||
|
||||
@skipOnLDAP @issue-ldap-250
|
||||
Scenario Outline: group names are case-sensitive, sharing with nonexistent groups with different upper and lower case names
|
||||
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 "<group_id1>" has been created
|
||||
And user "Brian" has been added to group "<group_id1>"
|
||||
When user "Alice" shares file "textfile1.txt" with group "<group_id1>" 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 "/textfile1.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 fields of the last response to user "Alice" should include
|
||||
| share_with | <group_id1> |
|
||||
| file_target | /Shares/textfile1.txt |
|
||||
| path | /Shares/textfile1.txt |
|
||||
| permissions | share,read,update |
|
||||
| uid_owner | %username% |
|
||||
And the content of file "/Shares/textfile1.txt" for user "Brian" should be "ownCloud test text file 1"
|
||||
When user "Alice" shares file "textfile2.txt" with group "<group_id2>" using the sharing API
|
||||
Then the OCS status code should be "404"
|
||||
And the HTTP status code should be "<http_status_code>"
|
||||
When user "Alice" shares file "textfile3.txt" with group "<group_id3>" using the sharing API
|
||||
Then the OCS status code should be "404"
|
||||
And the HTTP status code should be "<http_status_code>"
|
||||
Examples:
|
||||
| ocs_api_version | group_id1 | group_id2 | group_id3 | ocs_status_code | http_status_code |
|
||||
| 1 | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | 100 | 200 |
|
||||
| 1 | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | 100 | 200 |
|
||||
| 1 | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | 100 | 200 |
|
||||
| 2 | case-sensitive-group | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | 200 | 404 |
|
||||
| 2 | Case-Sensitive-Group | CASE-SENSITIVE-GROUP | case-sensitive-group | 200 | 404 |
|
||||
| 2 | CASE-SENSITIVE-GROUP | case-sensitive-group | Case-Sensitive-Group | 200 | 404 |
|
||||
+624
@@ -0,0 +1,624 @@
|
||||
@api @files_sharing-app-required
|
||||
Feature: share resources where the sharee receives the share in multiple ways
|
||||
|
||||
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 |
|
||||
|
||||
|
||||
Scenario Outline: creating and accepting a new share with user who already received a share through their group
|
||||
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 uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
|
||||
And user "Alice" has shared file "textfile0.txt" with group "grp1"
|
||||
And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
|
||||
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 user "Brian" should be able to accept pending share "/textfile0.txt" offered by user "Alice"
|
||||
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 | <file_target> |
|
||||
| path | /Shares/textfile0 (2).txt |
|
||||
| permissions | share,read,update |
|
||||
| uid_owner | %username% |
|
||||
| displayname_owner | %displayname% |
|
||||
| item_type | file |
|
||||
| mimetype | text/plain |
|
||||
| storage_id | ANY_VALUE |
|
||||
| share_type | user |
|
||||
@skipOnOcis
|
||||
Examples:
|
||||
| ocs_api_version | ocs_status_code | file_target |
|
||||
| 1 | 100 | /Shares/textfile0 (2).txt |
|
||||
| 2 | 200 | /Shares/textfile0 (2).txt |
|
||||
|
||||
@skipOnOcV10 @issue-2131
|
||||
Examples:
|
||||
| ocs_api_version | ocs_status_code | file_target |
|
||||
| 1 | 100 | /textfile0 (2).txt |
|
||||
| 2 | 200 | /textfile0 (2).txt |
|
||||
|
||||
@issue-ocis-1289
|
||||
Scenario Outline: Share of folder and sub-folder to same user
|
||||
Given using OCS API version "<ocs_api_version>"
|
||||
And group "grp4" has been created
|
||||
And user "Brian" has been added to group "grp4"
|
||||
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 "/PARENT/parent.txt"
|
||||
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/PARENT/CHILD/child.txt"
|
||||
When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API
|
||||
And user "Alice" shares folder "/PARENT/CHILD" with group "grp4" 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 be able to accept pending share "/PARENT" offered by user "Alice"
|
||||
And user "Brian" should be able to accept pending share "<pending_sub_share_path>" offered by user "Alice"
|
||||
And user "Brian" should see the following elements
|
||||
| /Shares/PARENT/ |
|
||||
| /Shares/PARENT/parent.txt |
|
||||
| /Shares/CHILD/ |
|
||||
| /Shares/CHILD/child.txt |
|
||||
Examples:
|
||||
| ocs_api_version | ocs_status_code | pending_sub_share_path |
|
||||
| 1 | 100 | /CHILD |
|
||||
| 2 | 200 | /CHILD |
|
||||
|
||||
@issue-ocis-2021
|
||||
Scenario Outline: sharing subfolder when parent already shared
|
||||
Given using OCS API version "<ocs_api_version>"
|
||||
And group "grp1" has been created
|
||||
And user "Alice" has created folder "/test"
|
||||
And user "Alice" has created folder "/test/sub"
|
||||
And user "Alice" has shared folder "/test" with group "grp1"
|
||||
When user "Alice" shares folder "/test/sub" 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 user "Brian" should be able to accept pending share "<pending_share_path>" offered by user "Alice"
|
||||
And as "Brian" folder "/Shares/sub" should exist
|
||||
Examples:
|
||||
| ocs_api_version | ocs_status_code | pending_share_path |
|
||||
| 1 | 100 | /sub |
|
||||
| 2 | 200 | /sub |
|
||||
|
||||
@issue-ocis-2021
|
||||
Scenario Outline: sharing subfolder when parent already shared with group of sharer
|
||||
Given using OCS API version "<ocs_api_version>"
|
||||
And group "grp0" has been created
|
||||
And user "Alice" has been added to group "grp0"
|
||||
And user "Alice" has created folder "/test"
|
||||
And user "Alice" has created folder "/test/sub"
|
||||
And user "Alice" has shared folder "/test" with group "grp0"
|
||||
When user "Alice" shares folder "/test/sub" 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 user "Brian" should be able to accept pending share "<pending_share_path>" offered by user "Alice"
|
||||
And as "Brian" folder "/Shares/sub" should exist
|
||||
Examples:
|
||||
| ocs_api_version | ocs_status_code | pending_share_path |
|
||||
| 1 | 100 | /sub |
|
||||
| 2 | 200 | /sub |
|
||||
|
||||
|
||||
Scenario Outline: multiple users share a file with the same name but different permissions to a user
|
||||
Given using OCS API version "<ocs_api_version>"
|
||||
And user "Carol" has been created with default attributes and without skeleton files
|
||||
And user "Brian" has uploaded file with content "First data" to "/randomfile.txt"
|
||||
And user "Carol" has uploaded file with content "Second data" to "/randomfile.txt"
|
||||
When user "Brian" shares file "randomfile.txt" with user "Alice" with permissions "read" using the sharing API
|
||||
And user "Alice" accepts share "/randomfile.txt" offered by user "Brian" using the sharing API
|
||||
Then as "Alice" the info about the last share by user "Brian" with user "Alice" should include
|
||||
| uid_owner | %username% |
|
||||
| share_with | %username% |
|
||||
| file_target | <file_target_1> |
|
||||
| item_type | file |
|
||||
| permissions | read |
|
||||
When user "Carol" shares file "randomfile.txt" with user "Alice" with permissions "read,update" using the sharing API
|
||||
And user "Alice" accepts share "/randomfile.txt" offered by user "Carol" using the sharing API
|
||||
Then as "Alice" the info about the last share by user "Carol" with user "Alice" should include
|
||||
| uid_owner | %username% |
|
||||
| share_with | %username% |
|
||||
| file_target | <file_target_2> |
|
||||
| item_type | file |
|
||||
| permissions | read,update |
|
||||
And the content of file "/Shares/randomfile.txt" for user "Alice" should be "First data"
|
||||
And the content of file "/Shares/randomfile (2).txt" for user "Alice" should be "Second data"
|
||||
@skipOnOcis
|
||||
Examples:
|
||||
| ocs_api_version | file_target_1 | file_target_2 |
|
||||
| 1 | /Shares/randomfile.txt | /Shares/randomfile (2).txt |
|
||||
| 2 | /Shares/randomfile.txt | /Shares/randomfile (2).txt |
|
||||
|
||||
@skipOnOcV10 @issue-ocis-2131
|
||||
Examples:
|
||||
| ocs_api_version | file_target_1 | file_target_2 |
|
||||
| 1 | /randomfile.txt | /randomfile (2).txt |
|
||||
| 2 | /randomfile.txt | /randomfile (2).txt |
|
||||
|
||||
|
||||
Scenario Outline: multiple users share a folder with the same name to a user
|
||||
Given using OCS API version "<ocs_api_version>"
|
||||
And user "Carol" has been created with default attributes and without skeleton files
|
||||
And user "Brian" has created folder "/zzzfolder"
|
||||
And user "Brian" has created folder "zzzfolder/Brian"
|
||||
And user "Carol" has created folder "/zzzfolder"
|
||||
And user "Carol" has created folder "zzzfolder/Carol"
|
||||
When user "Brian" shares folder "zzzfolder" with user "Alice" with permissions "read,delete" using the sharing API
|
||||
And user "Alice" accepts share "/zzzfolder" offered by user "Brian" using the sharing API
|
||||
Then as "Alice" the info about the last share by user "Brian" with user "Alice" should include
|
||||
| uid_owner | %username% |
|
||||
| share_with | %username% |
|
||||
| file_target | <file_target_1> |
|
||||
| item_type | folder |
|
||||
| permissions | read,delete |
|
||||
When user "Carol" shares folder "zzzfolder" with user "Alice" with permissions "read,share" using the sharing API
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "<ocs_status_code>"
|
||||
And user "Alice" should be able to accept pending share "/zzzfolder" offered by user "Carol"
|
||||
Then as "Alice" the info about the last share by user "Carol" with user "Alice" should include
|
||||
| uid_owner | %username% |
|
||||
| share_with | %username% |
|
||||
| file_target | <file_target_2> |
|
||||
| item_type | folder |
|
||||
| permissions | read,share |
|
||||
And as "Alice" folder "/Shares/zzzfolder/Brian" should exist
|
||||
And as "Alice" folder "/Shares/zzzfolder (2)/Carol" should exist
|
||||
@skipOnOcis
|
||||
Examples:
|
||||
| ocs_api_version | file_target_1 | file_target_2 | ocs_status_code |
|
||||
| 1 | /Shares/zzzfolder | /Shares/zzzfolder (2) | 100 |
|
||||
| 2 | /Shares/zzzfolder | /Shares/zzzfolder (2) | 200 |
|
||||
|
||||
@skipOnOcV10 @issue-ocis-2131
|
||||
Examples:
|
||||
| ocs_api_version | file_target_1 | file_target_2 | ocs_status_code |
|
||||
| 1 | /zzzfolder | /zzzfolder (2) | 100 |
|
||||
| 2 | /zzzfolder | /zzzfolder (2) | 200 |
|
||||
|
||||
@skipOnEncryptionType:user-keys @encryption-issue-132 @skipOnLDAP @skipOnGraph
|
||||
Scenario Outline: share with a group and then add a user to that group that already has a file with the shared name
|
||||
Given using OCS API version "<ocs_api_version>"
|
||||
And user "Carol" has been created with default attributes and without skeleton files
|
||||
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 "Shared content" to "lorem.txt"
|
||||
And user "Carol" has uploaded file with content "My content" to "lorem.txt"
|
||||
And user "Alice" has created a share with settings
|
||||
| path | /lorem.txt |
|
||||
| shareType | group |
|
||||
| shareWith | grp1 |
|
||||
And user "Brian" has accepted share "/lorem.txt" offered by user "Alice"
|
||||
When the administrator adds user "Carol" to group "grp1" using the provisioning API
|
||||
Then the OCS status code should be "<ocs_status_code>"
|
||||
And the HTTP status code should be "200"
|
||||
And user "Carol" should be able to accept pending share "/lorem.txt" offered by user "Alice"
|
||||
And the content of file "Shares/lorem.txt" for user "Brian" should be "Shared content"
|
||||
And the content of file "lorem.txt" for user "Carol" should be "My content"
|
||||
And the content of file "Shares/lorem.txt" for user "Carol" should be "Shared content"
|
||||
Examples:
|
||||
| ocs_api_version | ocs_status_code |
|
||||
| 1 | 100 |
|
||||
| 2 | 200 |
|
||||
|
||||
|
||||
Scenario Outline: Sharing parent folder to user with all permissions and its child folder to group with read permission then check create operation
|
||||
Given group "grp1" has been created
|
||||
And user "Carol" has been created with default attributes and without skeleton files
|
||||
And user "Carol" has created the following folders
|
||||
| path |
|
||||
| /parent |
|
||||
| /parent/child1 |
|
||||
| /parent/child1/child2 |
|
||||
And user "Alice" has been added to group "grp1"
|
||||
And user "Brian" has been added to group "grp1"
|
||||
And user "Carol" has created a share with settings
|
||||
| path | /parent |
|
||||
| shareType | user |
|
||||
| shareWith | Brian |
|
||||
| permissions | all |
|
||||
And user "Carol" has created a share with settings
|
||||
| path | /parent/child1 |
|
||||
| shareType | group |
|
||||
| shareWith | grp1 |
|
||||
| permissions | read |
|
||||
When user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API
|
||||
And user "Brian" accepts share "<path>" offered by user "Carol" using the sharing API
|
||||
And user "Alice" accepts share "<path>" offered by user "Carol" using the sharing API
|
||||
Then the HTTP status code of responses on all endpoints should be "200"
|
||||
And the OCS status code of responses on all endpoints should be "100"
|
||||
And user "Brian" should be able to create folder "/Shares/parent/fo1"
|
||||
And user "Brian" should be able to create folder "/Shares/parent/child1/fo2"
|
||||
And user "Alice" should not be able to create folder "/Shares/child1/fo3"
|
||||
@issue-2440
|
||||
Examples:
|
||||
| path |
|
||||
| /child1 |
|
||||
|
||||
|
||||
Scenario Outline: Sharing parent folder to user with all permissions and its child folder to group with read permission then check rename operation
|
||||
Given group "grp1" has been created
|
||||
And user "Carol" has been created with default attributes and without skeleton files
|
||||
And user "Carol" has created the following folders
|
||||
| path |
|
||||
| /parent |
|
||||
| /parent/child1 |
|
||||
| /parent/child1/child2 |
|
||||
And user "Alice" has been added to group "grp1"
|
||||
And user "Brian" has been added to group "grp1"
|
||||
And user "Carol" has uploaded file with content "some data" to "/parent/child1/child2/textfile-2.txt"
|
||||
And user "Carol" has created a share with settings
|
||||
| path | /parent |
|
||||
| shareType | user |
|
||||
| shareWith | Brian |
|
||||
| permissions | all |
|
||||
And user "Carol" has created a share with settings
|
||||
| path | /parent/child1 |
|
||||
| shareType | group |
|
||||
| shareWith | grp1 |
|
||||
| permissions | read |
|
||||
When user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API
|
||||
And user "Brian" accepts share "<path>" offered by user "Carol" using the sharing API
|
||||
And user "Alice" accepts share "<path>" offered by user "Carol" using the sharing API
|
||||
Then the HTTP status code of responses on all endpoints should be "200"
|
||||
And the OCS status code of responses on all endpoints should be "100"
|
||||
And user "Brian" should be able to rename file "/Shares/parent/child1/child2/textfile-2.txt" to "/Shares/parent/child1/child2/rename.txt"
|
||||
And user "Brian" should not be able to rename file "/Shares/child1/child2/rename.txt" to "/Shares/child1/child2/rename2.txt"
|
||||
And user "Alice" should not be able to rename file "/Shares/child1/child2/rename.txt" to "/Shares/child1/child2/rename2.txt"
|
||||
@issue-2440
|
||||
Examples:
|
||||
| path |
|
||||
| /child1 |
|
||||
|
||||
|
||||
Scenario Outline: Sharing parent folder to user with all permissions and its child folder to group with read permission then check delete operation
|
||||
Given group "grp1" has been created
|
||||
And user "Carol" has been created with default attributes and without skeleton files
|
||||
And user "Carol" has created the following folders
|
||||
| path |
|
||||
| /parent |
|
||||
| /parent/child1 |
|
||||
| /parent/child1/child2 |
|
||||
And user "Alice" has been added to group "grp1"
|
||||
And user "Brian" has been added to group "grp1"
|
||||
And user "Carol" has uploaded file with content "some data" to "/parent/child1/child2/textfile-2.txt"
|
||||
And user "Carol" has created a share with settings
|
||||
| path | /parent |
|
||||
| shareType | user |
|
||||
| shareWith | Brian |
|
||||
| permissions | all |
|
||||
And user "Carol" has created a share with settings
|
||||
| path | /parent/child1 |
|
||||
| shareType | group |
|
||||
| shareWith | grp1 |
|
||||
| permissions | read |
|
||||
When user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API
|
||||
And user "Brian" accepts share "<path>" offered by user "Carol" using the sharing API
|
||||
And user "Alice" accepts share "<path>" offered by user "Carol" using the sharing API
|
||||
Then the HTTP status code of responses on all endpoints should be "200"
|
||||
And the OCS status code of responses on all endpoints should be "100"
|
||||
And user "Brian" should be able to delete file "/Shares/parent/child1/child2/textfile-2.txt"
|
||||
And user "Brian" should not be able to delete folder "/Shares/child1/child2"
|
||||
And user "Alice" should not be able to delete folder "/Shares/child1/child2"
|
||||
@issue-2440
|
||||
Examples:
|
||||
| path |
|
||||
| /child1 |
|
||||
|
||||
|
||||
Scenario Outline: Sharing parent folder to user with all permissions and its child folder to group with read permission then check reshare operation
|
||||
Given group "grp1" has been created
|
||||
And user "Carol" has been created with default attributes and without skeleton files
|
||||
And user "Carol" has created the following folders
|
||||
| path |
|
||||
| /parent |
|
||||
| /parent/child1 |
|
||||
| /parent/child1/child2 |
|
||||
And user "Alice" has been added to group "grp1"
|
||||
And user "Brian" has been added to group "grp1"
|
||||
And user "Carol" has created a share with settings
|
||||
| path | /parent |
|
||||
| shareType | user |
|
||||
| shareWith | Brian |
|
||||
| permissions | all |
|
||||
And user "Carol" has created a share with settings
|
||||
| path | /parent/child1 |
|
||||
| shareType | group |
|
||||
| shareWith | grp1 |
|
||||
| permissions | read |
|
||||
And user "Brian" has accepted share "/parent" offered by user "Carol"
|
||||
And user "Brian" has accepted share "<path>" offered by user "Carol"
|
||||
And user "Alice" has accepted share "<path>" offered by user "Carol"
|
||||
When user "Brian" creates a share using the sharing API with settings
|
||||
| path | /Shares/parent |
|
||||
| shareType | user |
|
||||
| shareWith | Alice |
|
||||
| permissions | read |
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "100"
|
||||
And user "Alice" should be able to accept pending share "/parent" offered by user "Brian"
|
||||
And as "Brian" folder "/Shares/child1" should exist
|
||||
And as "Alice" folder "/Shares/child1" should exist
|
||||
And as "Alice" folder "/Shares/parent" should exist
|
||||
Examples:
|
||||
| path |
|
||||
| /child1 |
|
||||
|
||||
|
||||
Scenario Outline: Sharing parent folder to group with read permission and its child folder to user with all permissions then check create operation
|
||||
Given group "grp1" has been created
|
||||
And user "Carol" has been created with default attributes and without skeleton files
|
||||
And user "Carol" has created the following folders
|
||||
| path |
|
||||
| /parent |
|
||||
| /parent/child1 |
|
||||
| /parent/child1/child2 |
|
||||
And user "Alice" has been added to group "grp1"
|
||||
And user "Brian" has been added to group "grp1"
|
||||
And user "Carol" has created a share with settings
|
||||
| path | /parent |
|
||||
| shareType | group |
|
||||
| shareWith | grp1 |
|
||||
| permissions | read |
|
||||
And user "Carol" has created a share with settings
|
||||
| path | /parent/child1 |
|
||||
| shareType | user |
|
||||
| shareWith | Brian |
|
||||
| permissions | all |
|
||||
When user "Brian" accepts share "<path>" offered by user "Carol" using the sharing API
|
||||
And user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API
|
||||
And user "Alice" accepts share "/parent" offered by user "Carol" using the sharing API
|
||||
Then the HTTP status code of responses on all endpoints should be "200"
|
||||
And the OCS status code of responses on all endpoints should be "100"
|
||||
And user "Brian" should be able to create folder "/Shares/child1/fo1"
|
||||
And user "Brian" should be able to create folder "/Shares/child1/child2/fo2"
|
||||
But user "Brian" should not be able to create folder "/Shares/parent/fo3"
|
||||
And user "Brian" should not be able to create folder "/Shares/parent/fo3"
|
||||
And user "Alice" should not be able to create folder "/Shares/parent/fo3"
|
||||
Examples:
|
||||
| path |
|
||||
| /child1 |
|
||||
|
||||
|
||||
Scenario Outline: Sharing parent folder to group with read permission and its child folder to user with all permissions then check rename operation
|
||||
Given group "grp1" has been created
|
||||
And user "Carol" has been created with default attributes and without skeleton files
|
||||
And user "Carol" has created the following folders
|
||||
| path |
|
||||
| /parent |
|
||||
| /parent/child1 |
|
||||
| /parent/child1/child2 |
|
||||
And user "Alice" has been added to group "grp1"
|
||||
And user "Brian" has been added to group "grp1"
|
||||
And user "Carol" has uploaded file with content "some data" to "/parent/child1/child2/textfile-2.txt"
|
||||
And user "Carol" has created a share with settings
|
||||
| path | /parent |
|
||||
| shareType | group |
|
||||
| shareWith | grp1 |
|
||||
| permissions | read |
|
||||
And user "Carol" has created a share with settings
|
||||
| path | /parent/child1 |
|
||||
| shareType | user |
|
||||
| shareWith | Brian |
|
||||
| permissions | all |
|
||||
When user "Brian" accepts share "<path>" offered by user "Carol" using the sharing API
|
||||
And user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API
|
||||
And user "Alice" accepts share "/parent" offered by user "Carol" using the sharing API
|
||||
Then the HTTP status code of responses on all endpoints should be "200"
|
||||
And the OCS status code of responses on all endpoints should be "100"
|
||||
And user "Brian" should be able to rename file "/Shares/child1/child2/textfile-2.txt" to "/Shares/child1/child2/rename.txt"
|
||||
And user "Brian" should not be able to rename file "/Shares/parent/child1/child2/rename.txt" to "/Shares/parent/child1/child2/rename2.txt"
|
||||
And user "Alice" should not be able to rename file "/Shares/parent/child1/child2/rename.txt" to "/Shares/parent/child1/child2/rename2.txt"
|
||||
@issue-ocis-2440
|
||||
Examples:
|
||||
| path |
|
||||
| /child1 |
|
||||
|
||||
|
||||
Scenario Outline: Sharing parent folder to group with read permission and its child folder to user with all permissions then check delete operation
|
||||
Given group "grp1" has been created
|
||||
And user "Carol" has been created with default attributes and without skeleton files
|
||||
And user "Carol" has created the following folders
|
||||
| path |
|
||||
| /parent |
|
||||
| /parent/child1 |
|
||||
| /parent/child1/child2 |
|
||||
And user "Alice" has been added to group "grp1"
|
||||
And user "Brian" has been added to group "grp1"
|
||||
And user "Carol" has uploaded file with content "some data" to "/parent/child1/child2/textfile-2.txt"
|
||||
And user "Carol" has created a share with settings
|
||||
| path | /parent |
|
||||
| shareType | group |
|
||||
| shareWith | grp1 |
|
||||
| permissions | read |
|
||||
And user "Carol" has created a share with settings
|
||||
| path | /parent/child1 |
|
||||
| shareType | user |
|
||||
| shareWith | Brian |
|
||||
| permissions | all |
|
||||
When user "Brian" accepts share "<path>" offered by user "Carol" using the sharing API
|
||||
And user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API
|
||||
And user "Alice" accepts share "/parent" offered by user "Carol" using the sharing API
|
||||
Then the HTTP status code of responses on all endpoints should be "200"
|
||||
And the OCS status code of responses on all endpoints should be "100"
|
||||
And user "Brian" should be able to delete file "/Shares/child1/child2/textfile-2.txt"
|
||||
And user "Brian" should not be able to delete folder "/Shares/parent/child1"
|
||||
And user "Alice" should not be able to delete folder "/Shares/parent/child1"
|
||||
@issue-ocis-2440
|
||||
Examples:
|
||||
| path |
|
||||
| /child1 |
|
||||
|
||||
|
||||
Scenario Outline: Sharing parent folder to group with read permission and its child folder to user with all permissions then check reshare operation
|
||||
Given group "grp1" has been created
|
||||
And user "Carol" has been created with default attributes and without skeleton files
|
||||
And user "Carol" has created the following folders
|
||||
| path |
|
||||
| /parent |
|
||||
| /parent/child1 |
|
||||
| /parent/child1/child2 |
|
||||
And user "Alice" has been added to group "grp1"
|
||||
And user "Brian" has been added to group "grp1"
|
||||
And user "Carol" has created a share with settings
|
||||
| path | /parent |
|
||||
| shareType | group |
|
||||
| shareWith | grp1 |
|
||||
| permissions | read |
|
||||
And user "Carol" has created a share with settings
|
||||
| path | /parent/child1 |
|
||||
| shareType | user |
|
||||
| shareWith | Brian |
|
||||
| permissions | all |
|
||||
When user "Brian" accepts share "<path>" offered by user "Carol" using the sharing API
|
||||
And user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API
|
||||
And user "Alice" accepts share "/parent" offered by user "Carol" using the sharing API
|
||||
Then the HTTP status code of responses on all endpoints should be "200"
|
||||
And the OCS status code of responses on all endpoints should be "100"
|
||||
And user "Brian" should be able to share folder "/Shares/child1" with user "Alice" with permissions "read" using the sharing API
|
||||
And user "Alice" should be able to accept pending share "<path>" offered by user "Brian"
|
||||
And as "Brian" folder "/Shares/parent" should exist
|
||||
And as "Alice" folder "/Shares/parent" should exist
|
||||
And as "Alice" folder "/Shares/child1" should exist
|
||||
Examples:
|
||||
| path |
|
||||
| /child1 |
|
||||
|
||||
|
||||
Scenario Outline: Sharing parent folder to one group with all permissions and its child folder to another group with read permission
|
||||
Given these groups have been created:
|
||||
| groupname |
|
||||
| grp1 |
|
||||
| grp2 |
|
||||
| grp3 |
|
||||
And user "Carol" has been created with default attributes and without skeleton files
|
||||
And user "Carol" has created the following folders
|
||||
| path |
|
||||
| /parent |
|
||||
| /parent/child1 |
|
||||
| /parent/child1/child2 |
|
||||
And user "Alice" has been added to group "grp1"
|
||||
And user "Brian" has been added to group "grp2"
|
||||
And user "Carol" has uploaded file with content "some data" to "/parent/child1/child2/textfile-2.txt"
|
||||
And user "Carol" has created a share with settings
|
||||
| path | /parent |
|
||||
| shareType | group |
|
||||
| shareWith | grp1 |
|
||||
| permissions | all |
|
||||
And user "Carol" has created a share with settings
|
||||
| path | /parent/child1 |
|
||||
| shareType | group |
|
||||
| shareWith | grp2 |
|
||||
| permissions | read |
|
||||
When user "Alice" accepts share "/parent" offered by user "Carol" using the sharing API
|
||||
And user "Brian" accepts share "<path>" offered by user "Carol" using the sharing API
|
||||
Then the HTTP status code of responses on all endpoints should be "200"
|
||||
And the OCS status code of responses on all endpoints should be "100"
|
||||
And user "Alice" should be able to create folder "/Shares/parent/child1/fo1"
|
||||
And user "Alice" should be able to create folder "/Shares/parent/child1/child2/fo2"
|
||||
And user "Alice" should be able to delete folder "/Shares/parent/child1/fo1"
|
||||
And user "Alice" should be able to delete folder "/Shares/parent/child1/child2/fo2"
|
||||
And user "Alice" should be able to rename file "/Shares/parent/child1/child2/textfile-2.txt" to "/Shares/parent/child1/child2/rename.txt"
|
||||
And user "Alice" should be able to share folder "/Shares/parent/child1" with group "grp3" with permissions "all" using the sharing API
|
||||
And as "Brian" folder "/Shares/child1" should exist
|
||||
And user "Brian" should not be able to create folder "/Shares/child1/fo1"
|
||||
And user "Brian" should not be able to create folder "/Shares/child1/child2/fo2"
|
||||
And user "Brian" should not be able to rename file "/Shares/child1/child2/rename.txt" to "/Shares/child1/child2/rename2.txt"
|
||||
And user "Brian" should not be able to share folder "/Shares/child1" with group "grp3" with permissions "read" using the sharing API
|
||||
Examples:
|
||||
| path |
|
||||
| /child1 |
|
||||
|
||||
@skipOnOcV10 @issue-39347
|
||||
Scenario Outline: Share receiver renames the received group share and shares same folder through user share again
|
||||
Given using OCS API version "<ocs_api_version>"
|
||||
And group "grp" has been created
|
||||
And user "Brian" has been added to group "grp"
|
||||
And user "Alice" has been added to group "grp"
|
||||
And user "Alice" has created folder "parent"
|
||||
And user "Alice" has created folder "parent/child"
|
||||
And user "Alice" has uploaded file with content "Share content" to "parent/child/lorem.txt"
|
||||
And user "Alice" has created a share with settings
|
||||
| path | parent |
|
||||
| shareType | group |
|
||||
| shareWith | grp |
|
||||
| permissions | read |
|
||||
When user "Brian" accepts share "/parent" offered by user "Alice" using the sharing API
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "<ocs_status_code>"
|
||||
And user "Brian" should be able to rename folder "/Shares/parent" to "/Shares/sharedParent"
|
||||
And user "Alice" should be able to share folder "parent" with user "Brian" with permissions "read" using the sharing API
|
||||
# Note: Brian has already accepted the share of this resource as a member of "grp".
|
||||
# Now he has also received the same resource shared directly to "Brian".
|
||||
# The server should effectively "auto-accept" this new "copy" of the resource
|
||||
# and present to Brian only the single resource "Shares/sharedParent"
|
||||
And as "Brian" folder "Shares/parent" should not exist
|
||||
And as "Brian" folder "Shares/sharedParent" should exist
|
||||
And as "Brian" file "Shares/sharedParent/child/lorem.txt" should exist
|
||||
Examples:
|
||||
| ocs_api_version | ocs_status_code |
|
||||
| 1 | 100 |
|
||||
| 2 | 200 |
|
||||
|
||||
@skipOnOcV10 @issue-39347
|
||||
Scenario Outline: Share receiver renames a group share and receives same resource through user share with additional permissions
|
||||
Given using OCS API version "<ocs_api_version>"
|
||||
And group "grp" has been created
|
||||
And user "Brian" has been added to group "grp"
|
||||
And user "Alice" has been added to group "grp"
|
||||
And user "Alice" has created folder "parent"
|
||||
And user "Alice" has created folder "parent/child"
|
||||
And user "Alice" has uploaded file with content "Share content" to "parent/child/lorem.txt"
|
||||
And user "Alice" has created a share with settings
|
||||
| path | parent |
|
||||
| shareType | group |
|
||||
| shareWith | grp |
|
||||
| permissions | read |
|
||||
And user "Brian" has accepted share "/parent" offered by user "Alice"
|
||||
And user "Brian" has moved folder "/Shares/parent" to "/Shares/sharedParent"
|
||||
When user "Alice" shares folder "parent" with user "Brian" with permissions "all" using the sharing API
|
||||
# Note: Brian has already accepted the share of this resource as a member of "grp".
|
||||
# Now he has also received the same resource shared directly to "Brian".
|
||||
# The server should effectively "auto-accept" this new "copy" of the resource
|
||||
# and present to Brian only the single resource "Shares/sharedParent"
|
||||
Then as "Brian" folder "Shares/parent" should not exist
|
||||
And as "Brian" folder "Shares/sharedParent" should exist
|
||||
And as "Brian" file "Shares/sharedParent/child/lorem.txt" should exist
|
||||
Examples:
|
||||
| ocs_api_version |
|
||||
| 1 |
|
||||
| 2 |
|
||||
|
||||
@skipOnOcV10 @issue-39347
|
||||
Scenario Outline: Share receiver renames a group share and receives same resource through user share with less permissions
|
||||
Given using OCS API version "<ocs_api_version>"
|
||||
And group "grp" has been created
|
||||
And user "Brian" has been added to group "grp"
|
||||
And user "Alice" has been added to group "grp"
|
||||
And user "Alice" has created folder "parent"
|
||||
And user "Alice" has created folder "parent/child"
|
||||
And user "Alice" has uploaded file with content "Share content" to "parent/child/lorem.txt"
|
||||
And user "Alice" has shared folder "parent" with group "grp" with permissions "all"
|
||||
When user "Brian" accepts share "/parent" offered by user "Alice" using the sharing API
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "<ocs_status_code>"
|
||||
And user "Brian" should be able to rename folder "/Shares/parent" to "/Shares/sharedParent"
|
||||
And user "Alice" should be able to share folder "parent" with user "Brian" with permissions "read" using the sharing API
|
||||
# Note: Brian has already accepted the share of this resource as a member of "grp".
|
||||
# Now he has also received the same resource shared directly to "Brian".
|
||||
# The server should effectively "auto-accept" this new "copy" of the resource
|
||||
# and present to Brian only the single resource "Shares/sharedParent"
|
||||
And as "Brian" folder "Shares/parent" should not exist
|
||||
And as "Brian" folder "Shares/sharedParent" should exist
|
||||
And as "Brian" file "Shares/sharedParent/child/lorem.txt" should exist
|
||||
Examples:
|
||||
| ocs_api_version | ocs_status_code |
|
||||
| 1 | 100 |
|
||||
| 2 | 200 |
|
||||
+130
@@ -0,0 +1,130 @@
|
||||
@api @files_sharing-app-required @notToImplementOnOCIS
|
||||
Feature: share resources where the sharee receives the share in multiple ways
|
||||
|
||||
# These are the bug demonstration scenarios for https://github.com/owncloud/core/issues/39347
|
||||
# Once the issue is fixed, delete this file and unskip all the respective tests tagged with @issue-39347
|
||||
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 |
|
||||
|
||||
|
||||
Scenario Outline: Share receiver renames the received group share and shares same folder through user share again
|
||||
Given using OCS API version "<ocs_api_version>"
|
||||
And group "grp" has been created
|
||||
And user "Brian" has been added to group "grp"
|
||||
And user "Alice" has been added to group "grp"
|
||||
And user "Alice" has created folder "parent"
|
||||
And user "Alice" has created folder "parent/child"
|
||||
And user "Alice" has uploaded file with content "Share content" to "parent/child/lorem.txt"
|
||||
And user "Alice" has created a share with settings
|
||||
| path | parent |
|
||||
| shareType | group |
|
||||
| shareWith | grp |
|
||||
| permissions | read |
|
||||
When user "Brian" accepts share "/parent" offered by user "Alice" using the sharing API
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "<ocs_status_code>"
|
||||
And user "Brian" should be able to rename folder "/Shares/parent" to "/Shares/sharedParent"
|
||||
And user "Alice" should be able to share folder "parent" with user "Brian" with permissions "read" using the sharing API
|
||||
And user "Brian" should be able to accept pending share "/parent" offered by user "Alice"
|
||||
And as "Brian" folder "Shares/parent" should exist
|
||||
And as "Brian" folder "Shares/sharedParent" should not exist
|
||||
And as "Brian" file "Shares/sharedParent/child/lorem.txt" should not exist
|
||||
Examples:
|
||||
| ocs_api_version | ocs_status_code |
|
||||
| 1 | 100 |
|
||||
| 2 | 200 |
|
||||
|
||||
|
||||
# Note: after fixing the bug, this scenario is no longer relevant.
|
||||
# Brian should not get a chance to decline (or accept) the 2nd share of the resource from Alice
|
||||
Scenario Outline: Share receiver renames the received group share and declines another share of same folder through user share again
|
||||
Given using OCS API version "<ocs_api_version>"
|
||||
And group "grp" has been created
|
||||
And user "Brian" has been added to group "grp"
|
||||
And user "Alice" has been added to group "grp"
|
||||
And user "Alice" has created folder "parent"
|
||||
And user "Alice" has created folder "parent/child"
|
||||
And user "Alice" has uploaded file with content "Share content" to "parent/child/lorem.txt"
|
||||
And user "Alice" has created a share with settings
|
||||
| path | parent |
|
||||
| shareType | group |
|
||||
| shareWith | grp |
|
||||
| permissions | read |
|
||||
When user "Brian" accepts share "/parent" offered by user "Alice" using the sharing API
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "<ocs_status_code>"
|
||||
And user "Brian" should be able to rename folder "/Shares/parent" to "/Shares/sharedParent"
|
||||
And user "Alice" should be able to share folder "parent" with user "Brian" with permissions "read" using the sharing API
|
||||
And user "Brian" should be able to decline pending share "/parent" offered by user "Alice"
|
||||
And as "Brian" folder "Shares/parent" should not exist
|
||||
And as "Brian" folder "Shares/sharedParent" should not exist
|
||||
And as "Brian" file "Shares/sharedParent/child/lorem.txt" should not exist
|
||||
Examples:
|
||||
| ocs_api_version | ocs_status_code |
|
||||
| 1 | 100 |
|
||||
| 2 | 200 |
|
||||
|
||||
|
||||
Scenario Outline: Share receiver renames a group share and receives same resource through user share with additional permissions
|
||||
Given using OCS API version "<ocs_api_version>"
|
||||
And group "grp" has been created
|
||||
And user "Brian" has been added to group "grp"
|
||||
And user "Alice" has been added to group "grp"
|
||||
And user "Alice" has created folder "parent"
|
||||
And user "Alice" has created folder "parent/child"
|
||||
And user "Alice" has uploaded file with content "Share content" to "parent/child/lorem.txt"
|
||||
And user "Alice" has created a share with settings
|
||||
| path | parent |
|
||||
| shareType | group |
|
||||
| shareWith | grp |
|
||||
| permissions | read |
|
||||
When user "Brian" accepts share "/parent" offered by user "Alice" using the sharing API
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "<ocs_status_code>"
|
||||
And user "Brian" should be able to rename folder "/Shares/parent" to "/Shares/sharedParent"
|
||||
And user "Alice" should be able to share folder "parent" with user "Brian" with permissions "all" using the sharing API
|
||||
And user "Brian" should be able to accept pending share "/parent" offered by user "Alice"
|
||||
And as "Brian" folder "Shares/parent" should exist
|
||||
And as "Brian" folder "Shares/sharedParent" should not exist
|
||||
And as "Brian" file "Shares/sharedParent/child/lorem.txt" should not exist
|
||||
And as "Brian" file "Shares/parent/child/lorem.txt" should exist
|
||||
And user "Brian" should be able to delete file "Shares/parent/child/lorem.txt"
|
||||
Examples:
|
||||
| ocs_api_version | ocs_status_code |
|
||||
| 1 | 100 |
|
||||
| 2 | 200 |
|
||||
|
||||
|
||||
Scenario Outline: Share receiver renames a group share and receives same resource through user share with less permissions
|
||||
Given using OCS API version "<ocs_api_version> "
|
||||
And group "grp" has been created
|
||||
And user "Brian" has been added to group "grp"
|
||||
And user "Alice" has been added to group "grp"
|
||||
And user "Alice" has created folder "parent"
|
||||
And user "Alice" has created folder "parent/child"
|
||||
And user "Alice" has uploaded file with content "Share content" to "parent/child/lorem.txt"
|
||||
And user "Alice" has created a share with settings
|
||||
| path | parent |
|
||||
| shareType | group |
|
||||
| shareWith | grp |
|
||||
| permissions | all |
|
||||
When user "Brian" accepts share "/parent" offered by user "Alice" using the sharing API
|
||||
Then the HTTP status code should be "200"
|
||||
And the OCS status code should be "<ocs_status_code>"
|
||||
And user "Brian" should be able to rename folder "/Shares/parent" to "/Shares/sharedParent"
|
||||
And user "Alice" should be able to share folder "parent" with user "Brian" with permissions "read" using the sharing API
|
||||
And user "Brian" should be able to accept pending share "/parent" offered by user "Alice"
|
||||
And as "Brian" folder "Shares/parent" should exist
|
||||
And as "Brian" folder "Shares/sharedParent" should not exist
|
||||
And as "Brian" file "Shares/sharedParent/child/lorem.txt" should not exist
|
||||
And as "Brian" file "Shares/parent/child/lorem.txt" should exist
|
||||
And user "Brian" should be able to delete file "Shares/parent/child/lorem.txt"
|
||||
Examples:
|
||||
| ocs_api_version | ocs_status_code |
|
||||
| 1 | 100 |
|
||||
| 2 | 200 |
|
||||
+127
@@ -0,0 +1,127 @@
|
||||
@api @files_sharing-app-required @issue-ocis-1328
|
||||
Feature: cannot share resources outside the group when share with membership groups is enabled
|
||||
|
||||
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
|
||||
|
||||
@issue-ocis-1328 @skipOnOcis
|
||||
Scenario Outline: sharer should not be able to share a folder to a group which he/she is not member of when share with only member group is enabled
|
||||
Given using OCS API version "<ocs_api_version>"
|
||||
And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes"
|
||||
And user "Brian" has been created with default attributes and without skeleton files
|
||||
And group "grp0" has been created
|
||||
And group "grp1" has been created
|
||||
And user "Alice" has been added to group "grp0"
|
||||
And user "Brian" has been added to group "grp1"
|
||||
And user "Alice" has created folder "PARENT"
|
||||
When user "Alice" shares folder "/PARENT" with group "grp1" using the sharing API
|
||||
Then the OCS status code should be "<ocs_status_code>"
|
||||
And the HTTP status code should be "<http_status_code>"
|
||||
And as "Brian" folder "/PARENT" should not exist
|
||||
And as "Brian" folder "/Shares/PARENT" should not exist
|
||||
And the sharing API should report to user "Brian" that no shares are in the pending state
|
||||
Examples:
|
||||
| ocs_api_version | ocs_status_code | http_status_code |
|
||||
| 1 | 403 | 200 |
|
||||
| 2 | 403 | 403 |
|
||||
|
||||
|
||||
Scenario Outline: sharer should be able to share a folder to a user who is not member of sharer group when share with only member group is enabled
|
||||
Given using OCS API version "<ocs_api_version>"
|
||||
And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes"
|
||||
And user "Brian" has been created with default attributes and without skeleton files
|
||||
And group "grp0" has been created
|
||||
And user "Alice" has been added to group "grp0"
|
||||
And user "Alice" has created folder "PARENT"
|
||||
When user "Alice" shares folder "/PARENT" with user "Brian" 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"
|
||||
And as "Brian" folder "/Shares/PARENT" should exist
|
||||
But as "Brian" folder "/PARENT" should not exist
|
||||
Examples:
|
||||
| ocs_api_version | ocs_status_code |
|
||||
| 1 | 100 |
|
||||
| 2 | 200 |
|
||||
|
||||
|
||||
Scenario Outline: sharer should be able to share a folder to a group which he/she is member of when share with only member group is enabled
|
||||
Given using OCS API version "<ocs_api_version>"
|
||||
And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes"
|
||||
And user "Brian" has been created with default attributes and without skeleton files
|
||||
And group "grp0" has been created
|
||||
And user "Alice" has been added to group "grp0"
|
||||
And user "Brian" has been added to group "grp0"
|
||||
And user "Alice" has created folder "PARENT"
|
||||
When user "Alice" shares folder "/PARENT" with group "grp0" 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"
|
||||
And as "Brian" folder "/Shares/PARENT" should exist
|
||||
But as "Brian" folder "/PARENT" should not exist
|
||||
Examples:
|
||||
| ocs_api_version | ocs_status_code |
|
||||
| 1 | 100 |
|
||||
| 2 | 200 |
|
||||
|
||||
@issue-ocis-1328 @skipOnOcis
|
||||
Scenario Outline: sharer should not be able to share a file to a group which he/she is not member of when share with only member group is enabled
|
||||
Given using OCS API version "<ocs_api_version>"
|
||||
And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes"
|
||||
And user "Brian" has been created with default attributes and without skeleton files
|
||||
And group "grp0" has been created
|
||||
And group "grp1" has been created
|
||||
And user "Alice" has been added to group "grp0"
|
||||
And user "Brian" has been added to group "grp1"
|
||||
And user "Alice" 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 "<ocs_status_code>"
|
||||
And the HTTP status code should be "<http_status_code>"
|
||||
And as "Brian" file "/textfile0.txt" should not exist
|
||||
And as "Brian" file "/Shares/textfile0.txt" should not exist
|
||||
And the sharing API should report to user "Brian" that no shares are in the pending state
|
||||
Examples:
|
||||
| ocs_api_version | ocs_status_code | http_status_code |
|
||||
| 1 | 403 | 200 |
|
||||
| 2 | 403 | 403 |
|
||||
|
||||
|
||||
Scenario Outline: sharer should be able to share a file to a group which he/she is member of when share with only member group is enabled
|
||||
Given using OCS API version "<ocs_api_version>"
|
||||
And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes"
|
||||
And user "Brian" has been created with default attributes and without skeleton files
|
||||
And group "grp0" has been created
|
||||
And user "Alice" has been added to group "grp0"
|
||||
And user "Brian" has been added to group "grp0"
|
||||
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
|
||||
When user "Alice" shares folder "/textfile0.txt" with group "grp0" 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 "<ocs_status_code>"
|
||||
And the HTTP status code of responses on all endpoints should be "200"
|
||||
And as "Brian" file "/Shares/textfile0.txt" should exist
|
||||
But as "Brian" file "/textfile0.txt" should not exist
|
||||
Examples:
|
||||
| ocs_api_version | ocs_status_code |
|
||||
| 1 | 100 |
|
||||
| 2 | 200 |
|
||||
|
||||
|
||||
Scenario Outline: sharer should be able to share a file to a user who is not a member of sharer group when share with only member group is enabled
|
||||
Given using OCS API version "<ocs_api_version>"
|
||||
And parameter "shareapi_only_share_with_membership_groups" of app "core" has been set to "yes"
|
||||
And user "Brian" has been created with default attributes and without skeleton files
|
||||
And group "grp0" has been created
|
||||
And user "Alice" has been added to group "grp0"
|
||||
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
|
||||
When user "Alice" shares folder "/textfile0.txt" with user "Brian" 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 "<ocs_status_code>"
|
||||
And the HTTP status code of responses on all endpoints should be "200"
|
||||
And as "Brian" file "/Shares/textfile0.txt" should exist
|
||||
But as "Brian" file "/textfile0.txt" should not exist
|
||||
Examples:
|
||||
| ocs_api_version | ocs_status_code |
|
||||
| 1 | 100 |
|
||||
| 2 | 200 |
|
||||
+30
@@ -0,0 +1,30 @@
|
||||
@api @files_sharing-app-required @issue-ocis-1328
|
||||
Feature: share resources with a disabled user
|
||||
|
||||
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
|
||||
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
|
||||
|
||||
@issue-ocis-2212
|
||||
Scenario Outline: Creating a new share with a disabled 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 been disabled
|
||||
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 "401"
|
||||
Examples:
|
||||
| ocs_api_version | ocs_status_code |
|
||||
| 1 | 997 |
|
||||
|
||||
@issue-32068
|
||||
Scenario: Creating a new share with a disabled user
|
||||
Given using OCS API version "2"
|
||||
And user "Brian" has been created with default attributes and without skeleton files
|
||||
And user "Alice" has been disabled
|
||||
When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API
|
||||
Then the OCS status code should be "997"
|
||||
#And the OCS status code should be "401"
|
||||
And the HTTP status code should be "401"
|
||||
+118
@@ -0,0 +1,118 @@
|
||||
@api @files_sharing-app-required
|
||||
Feature: cannot share resources with invalid permissions
|
||||
|
||||
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
|
||||
And user "Alice" has uploaded file with content "some data" to "/textfile0.txt"
|
||||
And user "Alice" has created folder "/PARENT"
|
||||
|
||||
|
||||
Scenario Outline: Cannot create a share of a file or folder with invalid permissions
|
||||
Given using OCS API version "<ocs_api_version>"
|
||||
And user "Brian" has been created with default attributes and without skeleton files
|
||||
When user "Alice" creates a share using the sharing API with settings
|
||||
| path | <item> |
|
||||
| shareWith | Brian |
|
||||
| shareType | user |
|
||||
| permissions | <permissions> |
|
||||
Then the OCS status code should be "<ocs_status_code>"
|
||||
And the HTTP status code should be "<http_status_code>"
|
||||
And as "Brian" entry "<item>" should not exist
|
||||
And as "Brian" entry "/Shares/<item>" should not exist
|
||||
And the sharing API should report to user "Brian" that no shares are in the pending state
|
||||
Examples:
|
||||
| ocs_api_version | ocs_status_code | http_status_code | item | permissions |
|
||||
| 1 | 400 | 200 | textfile0.txt | 0 |
|
||||
| 2 | 400 | 400 | textfile0.txt | 0 |
|
||||
| 1 | 400 | 200 | PARENT | 0 |
|
||||
| 2 | 400 | 400 | PARENT | 0 |
|
||||
| 1 | 404 | 200 | textfile0.txt | 32 |
|
||||
| 2 | 404 | 404 | textfile0.txt | 32 |
|
||||
| 1 | 404 | 200 | PARENT | 32 |
|
||||
| 2 | 404 | 404 | PARENT | 32 |
|
||||
|
||||
|
||||
Scenario Outline: Cannot create a share of a file with a user with only create permission
|
||||
Given using OCS API version "<ocs_api_version>"
|
||||
And user "Brian" has been created with default attributes and without skeleton files
|
||||
When user "Alice" creates a share using the sharing API with settings
|
||||
| path | textfile0.txt |
|
||||
| shareWith | Brian |
|
||||
| shareType | user |
|
||||
| permissions | create |
|
||||
Then the OCS status code should be "400"
|
||||
And the HTTP status code should be "<http_status_code>"
|
||||
And as "Brian" entry "textfile0.txt" should not exist
|
||||
And as "Brian" entry "/Shares/textfile0.txt" should not exist
|
||||
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 | 400 |
|
||||
|
||||
|
||||
Scenario Outline: Cannot create a share of a file with a user with only (create,delete) permission
|
||||
Given using OCS API version "<ocs_api_version>"
|
||||
And user "Brian" has been created with default attributes and without skeleton files
|
||||
When user "Alice" creates a share using the sharing API with settings
|
||||
| path | textfile0.txt |
|
||||
| shareWith | Brian |
|
||||
| shareType | user |
|
||||
| permissions | <permissions> |
|
||||
Then the OCS status code should be "400"
|
||||
And the HTTP status code should be "<http_status_code>"
|
||||
And as "Brian" entry "textfile0.txt" should not exist
|
||||
And as "Brian" entry "/Shares/textfile0.txt" should not exist
|
||||
And the sharing API should report to user "Brian" that no shares are in the pending state
|
||||
Examples:
|
||||
| ocs_api_version | http_status_code | permissions |
|
||||
| 1 | 200 | delete |
|
||||
| 2 | 400 | delete |
|
||||
| 1 | 200 | create,delete |
|
||||
| 2 | 400 | create,delete |
|
||||
|
||||
@issue-ocis-reva-34
|
||||
Scenario Outline: Cannot create a share of a file with a group with only create permission
|
||||
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 "Brian" has been added to group "grp1"
|
||||
When user "Alice" creates a share using the sharing API with settings
|
||||
| path | textfile0.txt |
|
||||
| shareWith | grp1 |
|
||||
| shareType | group |
|
||||
| permissions | create |
|
||||
Then the OCS status code should be "400"
|
||||
And the HTTP status code should be "<http_status_code>"
|
||||
And as "Brian" entry "textfile0.txt" should not exist
|
||||
And as "Brian" entry "/Shares/textfile0.txt" should not exist
|
||||
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 | 400 |
|
||||
|
||||
@issue-ocis-reva-34
|
||||
Scenario Outline: Cannot create a share of a file with a group with only (create,delete) permission
|
||||
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 "Brian" has been added to group "grp1"
|
||||
When user "Alice" creates a share using the sharing API with settings
|
||||
| path | textfile0.txt |
|
||||
| shareWith | grp1 |
|
||||
| shareType | group |
|
||||
| permissions | <permissions> |
|
||||
Then the OCS status code should be "400"
|
||||
And the HTTP status code should be "<http_status_code>"
|
||||
And as "Brian" entry "textfile0.txt" should not exist
|
||||
And as "Brian" entry "/Shares/textfile0.txt" should not exist
|
||||
And the sharing API should report to user "Brian" that no shares are in the pending state
|
||||
Examples:
|
||||
| ocs_api_version | http_status_code | permissions |
|
||||
| 1 | 200 | delete |
|
||||
| 2 | 400 | delete |
|
||||
| 1 | 200 | create,delete |
|
||||
| 2 | 400 | create,delete |
|
||||
Reference in New Issue
Block a user