From f82361b0dc942f446fe7ad85a1b1ddc01f4686f5 Mon Sep 17 00:00:00 2001 From: sushmita56 Date: Wed, 9 Mar 2022 09:49:58 +0545 Subject: [PATCH] added then steps for apiShareCreateSpecialToRoot1 suite fixed php style addressed review --- .../createShareExpirationDate.feature | 303 ++++++++++-------- .../createShareReceivedInMultipleWays.feature | 56 ++-- ...eateShareResourceCaseSensitiveName.feature | 80 +++-- .../createShareUniqueReceivedNames.feature | 6 +- .../createShareReceivedInMultipleWays.feature | 278 ++++++++++------ .../acceptance/features/bootstrap/Sharing.php | 53 +++ 6 files changed, 490 insertions(+), 286 deletions(-) diff --git a/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareExpirationDate.feature b/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareExpirationDate.feature index 9191a162282f..c5ce4362b8d7 100644 --- a/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareExpirationDate.feature +++ b/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareExpirationDate.feature @@ -81,26 +81,27 @@ Feature: a default expiration date can be specified for shares with users or gro And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" And user "Brian" has been created with default attributes and without skeleton files And user "Alice" has created folder "FOLDER" - When user "Alice" creates a share using the sharing API with settings + And user "Alice" has created a share with settings | path | /FOLDER | | shareType | user | | shareWith | Brian | | permissions | read,share | | expireDate | +15 days | - And the administrator sets parameter "shareapi_default_expire_date_user_share" of app "core" to "no" - And user "Alice" gets the info of the last share using the sharing API - Then the fields of the last response to user "Alice" sharing with user "Brian" should include - | share_type | user | - | file_target | /FOLDER | - | uid_owner | %username% | - | expiration | +15 days | - | share_with | %username% | + When the administrator sets parameter "shareapi_default_expire_date_user_share" of app "core" to "no" + Then the info about the last share by user "Alice" with user "Brian" should include + | share_type | user | + | file_target | /FOLDER | + | uid_owner | %username% | + | expiration | +15 days | + | share_with | %username% | + | ocs_status_code | | + | http_status_code | | And the response when user "Brian" gets the info of the last share should include | expiration | +15 days | Examples: - | ocs_api_version | - | 1 | - | 2 | + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 100 | 200 | + | 2 | 200 | 200 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enabled and enforced for users, user shares with expiration date and then disables @@ -109,25 +110,26 @@ Feature: a default expiration date can be specified for shares with users or gro And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" And user "Brian" has been created with default attributes and without skeleton files And user "Alice" has created folder "FOLDER" - When user "Alice" creates a share using the sharing API with settings + And user "Alice" has created a share with settings | path | /FOLDER | | shareType | user | | shareWith | Brian | | permissions | read,share | - And the administrator sets parameter "shareapi_default_expire_date_user_share" of app "core" to "no" - And user "Alice" gets the info of the last share using the sharing API - Then the fields of the last response to user "Alice" sharing with user "Brian" should include - | share_type | user | - | file_target | /FOLDER | - | uid_owner | %username% | - | share_with | %username% | - | expiration | +7 days | + When parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "no" + Then the info about the last share by user "Alice" with user "Brian" should include + | share_type | user | + | file_target | /FOLDER | + | uid_owner | %username% | + | share_with | %username% | + | expiration | +7 days | + | ocs_status_code | | + | http_status_code | | And the response when user "Brian" gets the info of the last share should include | expiration | +7 days | Examples: - | ocs_api_version | - | 1 | - | 2 | + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 100 | 200 | + | 2 | 200 | 200 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enabled but not enforced for groups, user shares without specifying expireDate @@ -214,26 +216,27 @@ Feature: a default expiration date can be specified for shares with users or gro And group "grp1" has been created And user "Brian" has been added to group "grp1" And user "Alice" has created folder "FOLDER" - When user "Alice" creates a share using the sharing API with settings + And user "Alice" has created a share with settings | path | /FOLDER | | shareType | group | | shareWith | grp1 | | permissions | read,share | | expireDate | +15 days | - And the administrator sets parameter "shareapi_default_expire_date_group_share" of app "core" to "no" - And user "Alice" gets the info of the last share using the sharing API - Then the fields of the last response to user "Alice" sharing with group "grp1" should include - | share_type | group | - | file_target | /FOLDER | - | uid_owner | %username% | - | share_with | grp1 | - | expiration | +15 days | + When the administrator sets parameter "shareapi_default_expire_date_group_share" of app "core" to "no" + Then the info about the last share by user "Alice" with group "grp1" should include + | share_type | group | + | file_target | /FOLDER | + | uid_owner | %username% | + | share_with | grp1 | + | expiration | +15 days | + | ocs_status_code | | + | http_status_code | | And the response when user "Brian" gets the info of the last share should include | expiration | +15 days | Examples: - | ocs_api_version | - | 1 | - | 2 | + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 100 | 200 | + | 2 | 200 | 200 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enabled and enforced for groups, user shares with expiration date and then disables @@ -244,26 +247,27 @@ Feature: a default expiration date can be specified for shares with users or gro And group "grp1" has been created And user "Brian" has been added to group "grp1" And user "Alice" has created folder "FOLDER" - When user "Alice" creates a share using the sharing API with settings + And user "Alice" has created a share with settings | path | /FOLDER | | shareType | group | | shareWith | grp1 | | permissions | read,share | | expireDate | +3 days | - And the administrator sets parameter "shareapi_default_expire_date_group_share" of app "core" to "no" - And user "Alice" gets the info of the last share using the sharing API - Then the fields of the last response to user "Alice" sharing with group "grp1" should include - | share_type | group | - | file_target | /FOLDER | - | uid_owner | %username% | - | share_with | grp1 | - | expiration | +3 days | + When the administrator sets parameter "shareapi_default_expire_date_group_share" of app "core" to "no" + Then the info about the last share by user "Alice" with group "grp1" should include + | share_type | group | + | file_target | /FOLDER | + | uid_owner | %username% | + | share_with | grp1 | + | expiration | +3 days | + | ocs_status_code | | + | http_status_code | | And the response when user "Brian" gets the info of the last share should include | expiration | +3 days | Examples: - | ocs_api_version | - | 1 | - | 2 | + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 100 | 200 | + | 2 | 200 | 200 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enabled and enforced for users, user shares without setting expiration date @@ -273,7 +277,9 @@ Feature: a default expiration date can be specified for shares with users or gro And user "Brian" has been created with default attributes and without skeleton files And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API - Then the fields of the last response to user "Alice" sharing with user "Brian" should include + Then the OCS status code should be "" + And the HTTP status code should be "" + And the fields of the last response to user "Alice" sharing with user "Brian" should include | share_type | user | | file_target | /textfile0.txt | | uid_owner | %username% | @@ -282,9 +288,9 @@ Feature: a default expiration date can be specified for shares with users or gro And the response when user "Brian" gets the info of the last share should include | expiration | +7 days | Examples: - | ocs_api_version | - | 1 | - | 2 | + | ocs_api_version | ocs_status_code | http_status_code | + | 1 | 100 | 200 | + | 2 | 200 | 200 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enabled and enforced for users, user shares with expiration date more than the default @@ -317,7 +323,9 @@ Feature: a default expiration date can be specified for shares with users or gro And user "Brian" has been created with default attributes and without skeleton files And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API - Then the fields of the last response to user "Alice" sharing with user "Brian" should include + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the fields of the last response to user "Alice" sharing with user "Brian" should include | share_type | user | | file_target | /textfile0.txt | | uid_owner | %username% | @@ -326,9 +334,9 @@ Feature: a default expiration date can be specified for shares with users or gro And the response when user "Brian" gets the info of the last share should include | expiration | +30 days | Examples: - | ocs_api_version | - | 1 | - | 2 | + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enabled and enforced for users/max expire date set, user shares with expiration date more than the max expire date @@ -361,15 +369,16 @@ Feature: a default expiration date can be specified for shares with users or gro And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" And user "Brian" has been created with default attributes and without skeleton files And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" shares file "textfile0.txt" with user "Brian" with permissions "read,share" using the sharing API - And the administrator sets parameter "shareapi_expire_after_n_days_user_share" of app "core" to "40" - And user "Alice" gets the info of the last share using the sharing API - Then the fields of the last response to user "Alice" should include - | expiration | +30 days | + And user "Alice" has shared file "textfile0.txt" with user "Brian" with permissions "read,share" + When the administrator sets parameter "shareapi_expire_after_n_days_user_share" of app "core" to "40" + Then the info about the last share by user "Alice" with user "Brian" should include + | expiration | +30 days | + | http_status_code | 200 | + | ocs_status_code | | Examples: - | ocs_api_version | - | 1 | - | 2 | + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enabled for users/max expire date is set, user shares and changes max expire date less than the previous one @@ -379,15 +388,16 @@ Feature: a default expiration date can be specified for shares with users or gro And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30" And user "Brian" has been created with default attributes and without skeleton files And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" - When user "Alice" shares file "textfile0.txt" with user "Brian" with permissions "read,share" using the sharing API - And the administrator sets parameter "shareapi_expire_after_n_days_user_share" of app "core" to "15" - And user "Alice" gets the info of the last share using the sharing API - Then the fields of the last response to user "Alice" should include - | expiration | +30 days | + And user "Alice" has shared file "textfile0.txt" with user "Brian" with permissions "read,share" + When the administrator sets parameter "shareapi_expire_after_n_days_user_share" of app "core" to "15" + Then the info about the last share by user "Alice" with user "Brian" should include + | expiration | +30 days | + | http_status_code | 200 | + | ocs_status_code | | Examples: - | ocs_api_version | - | 1 | - | 2 | + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enabled and enforced for groups, user shares without setting expiration date @@ -399,7 +409,9 @@ Feature: a default expiration date can be specified for shares with users or gro 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 fields of the last response to user "Alice" sharing with group "grp1" should include + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the fields of the last response to user "Alice" sharing with group "grp1" should include | share_type | group | | file_target | /textfile0.txt | | uid_owner | %username% | @@ -408,9 +420,9 @@ Feature: a default expiration date can be specified for shares with users or gro And the response when user "Brian" gets the info of the last share should include | expiration | +7 days | Examples: - | ocs_api_version | - | 1 | - | 2 | + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enabled and enforced for groups, user shares with expiration date more than the default @@ -447,7 +459,9 @@ Feature: a default expiration date can be specified for shares with users or gro 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 fields of the last response to user "Alice" sharing with group "grp1" should include + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the fields of the last response to user "Alice" sharing with group "grp1" should include | share_type | group | | file_target | /textfile0.txt | | uid_owner | %username% | @@ -456,9 +470,9 @@ Feature: a default expiration date can be specified for shares with users or gro And the response when user "Brian" gets the info of the last share should include | expiration | +30 days | Examples: - | ocs_api_version | - | 1 | - | 2 | + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enabled and enforced for groups/max expire date set, user shares with expiration date more than the max expire date @@ -495,17 +509,18 @@ Feature: a default expiration date can be specified for shares with users or gro 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" - When user "Alice" shares file "textfile0.txt" with group "grp1" with permissions "read,share" using the sharing API - And the administrator sets parameter "shareapi_expire_after_n_days_group_share" of app "core" to "40" - And user "Alice" gets the info of the last share using the sharing API - Then the fields of the last response to user "Alice" should include - | expiration | +30 days | + And user "Alice" has shared file "textfile0.txt" with group "grp1" with permissions "read,share" + When the administrator sets parameter "shareapi_expire_after_n_days_group_share" of app "core" to "40" + Then the info about the last share by user "Alice" with user "Brian" should include + | expiration | +30 days | + | http_status_code | 200 | + | ocs_status_code | | And the response when user "Brian" gets the info of the last share should include | expiration | +30 days | Examples: - | ocs_api_version | - | 1 | - | 2 | + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enabled for groups/max expire date is set, user shares and changes max expire date less than the previous one @@ -517,17 +532,19 @@ Feature: a default expiration date can be specified for shares with users or gro 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" - When user "Alice" shares file "textfile0.txt" with group "grp1" with permissions "read,share" using the sharing API - And the administrator sets parameter "shareapi_expire_after_n_days_group_share" of app "core" to "15" + And user "Alice" has shared file "textfile0.txt" with group "grp1" with permissions "read,share" + When the administrator sets parameter "shareapi_expire_after_n_days_group_share" of app "core" to "15" And user "Alice" gets the info of the last share using the sharing API - Then the fields of the last response to user "Alice" should include + Then the OCS status code should be "" + And the HTTP status code should be "200" + And the fields of the last response to user "Alice" should include | expiration | +30 days | And the response when user "Brian" gets the info of the last share should include | expiration | +30 days | Examples: - | ocs_api_version | - | 1 | - | 2 | + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enforced for users, user shares to a group without setting an expiration date @@ -539,15 +556,16 @@ Feature: a default expiration date can be specified for shares with users or gro And user "Brian" has been added to group "grp1" And user "Alice" has created folder "FOLDER" When user "Alice" shares file "FOLDER" with group "grp1" with permissions "read,share" using the sharing API - And user "Alice" gets the info of the last share using the sharing API - Then the fields of the last response to user "Alice" should include - | expiration | | + Then the info about the last share by user "Alice" with group "grp1" should include + | expiration | | + | http_status_code | 200 | + | ocs_status_code | | And the response when user "Brian" gets the info of the last share should include | expiration | | Examples: - | ocs_api_version | - | 1 | - | 2 | + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enforced for groups, user shares to another user @@ -557,15 +575,16 @@ Feature: a default expiration date can be specified for shares with users or gro And user "Brian" has been created with default attributes and without skeleton files And user "Alice" has created folder "FOLDER" When user "Alice" shares file "/FOLDER" with user "Brian" with permissions "read,share" using the sharing API - And user "Alice" gets the info of the last share using the sharing API - Then the fields of the last response to user "Alice" should include - | expiration | | + Then the info about the last share by user "Alice" with user "Brian" should include + | expiration | | + | http_status_code | 200 | + | ocs_status_code | | And the response when user "Brian" gets the info of the last share should include | expiration | | Examples: - | ocs_api_version | - | 1 | - | 2 | + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enforced for users, user shares with invalid expiration date set @@ -628,24 +647,26 @@ Feature: a default expiration date can be specified for shares with users or gro | shareWith | Brian | | permissions | read,share | | expireDateAsString | | - Then the fields of the last response to user "Alice" should include + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the fields of the last response to user "Alice" should include | expiration | | And the response when user "Brian" gets the info of the last share should include | expiration | | Examples: - | ocs_api_version | expiration_date | default | enforce | - | 1 | today | yes | yes | - | 2 | today | yes | yes | - | 1 | tomorrow | yes | yes | - | 2 | tomorrow | yes | yes | - | 1 | today | yes | no | - | 2 | today | yes | no | - | 1 | tomorrow | yes | no | - | 2 | tomorrow | yes | no | - | 1 | today | no | no | - | 2 | today | no | no | - | 1 | tomorrow | no | no | - | 2 | tomorrow | no | no | + | ocs_api_version | expiration_date | default | enforce | ocs_status_code | + | 1 | today | yes | yes | 100 | + | 2 | today | yes | yes | 200 | + | 1 | tomorrow | yes | yes | 100 | + | 2 | tomorrow | yes | yes | 200 | + | 1 | today | yes | no | 100 | + | 2 | today | yes | no | 200 | + | 1 | tomorrow | yes | no | 100 | + | 2 | tomorrow | yes | no | 200 | + | 1 | today | no | no | 100 | + | 2 | today | no | no | 200 | + | 1 | tomorrow | no | no | 100 | + | 2 | tomorrow | no | no | 200 | @skipOnOcV10.3 Scenario Outline: user shares with humanized expiration date format in past @@ -734,14 +755,16 @@ Feature: a default expiration date can be specified for shares with users or gro | shareType | user | | shareWith | Brian | | permissions | read,share | - Then the fields of the last response to user "Alice" should include + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the fields of the last response to user "Alice" should include | expiration | today | And the response when user "Brian" gets the info of the last share should include | expiration | today | Examples: - | ocs_api_version | - | 1 | - | 2 | + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enforced for users, max expire date is 1, user shares without specifying expiration date @@ -756,14 +779,16 @@ Feature: a default expiration date can be specified for shares with users or gro | shareType | user | | shareWith | Brian | | permissions | read,share | - Then the fields of the last response to user "Alice" should include + Then the HTTP status code should be "200" + And the OCS status code should be "" + And the fields of the last response to user "Alice" should include | expiration | tomorrow | And the response when user "Brian" gets the info of the last share should include | expiration | tomorrow | Examples: - | ocs_api_version | - | 1 | - | 2 | + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | @skipOnOcV10.6 @skipOnOcV10.7 Scenario: accessing a user share that is expired should not be possible @@ -772,10 +797,10 @@ Feature: a default expiration date can be specified for shares with users or gro | Brian | And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" And user "Alice" has created a share with settings - | path | /textfile0.txt | - | shareType | user | - | shareWith | Brian | - | expireDate | +15 days | + | path | /textfile0.txt | + | shareType | user | + | shareWith | Brian | + | expireDate | +15 days | And the administrator has expired the last created share using the testing API When user "Alice" gets the info of the last share using the sharing API Then the OCS status code should be "404" @@ -794,10 +819,10 @@ Feature: a default expiration date can be specified for shares with users or gro And user "Brian" has been added to group "brand-new-group" And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" And user "Alice" has created a share with settings - | path | /textfile0.txt | - | shareType | group | - | shareWith | brand-new-group | - | expireDate | +15 days | + | path | /textfile0.txt | + | shareType | group | + | shareWith | brand-new-group | + | expireDate | +15 days | And the administrator has expired the last created share using the testing API When user "Alice" gets the info of the last share using the sharing API Then the OCS status code should be "404" @@ -816,9 +841,9 @@ Feature: a default expiration date can be specified for shares with users or gro And user "Brian" has been added to group "brand-new-group" And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" And user "Alice" has created a public link share with settings - | path | /textfile0.txt | - | shareWith | brand-new-group | - | expireDate | +15 days | + | path | /textfile0.txt | + | shareWith | brand-new-group | + | expireDate | +15 days | And the administrator has expired the last created share using the testing API When the public accesses the preview of file "textfile0.txt" from the last shared public link using the sharing API Then the HTTP status code should be "404" diff --git a/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareReceivedInMultipleWays.feature b/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareReceivedInMultipleWays.feature index 5d10ceadaf32..b5efb1cedd12 100644 --- a/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareReceivedInMultipleWays.feature +++ b/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareReceivedInMultipleWays.feature @@ -17,8 +17,8 @@ Feature: share resources where the sharee receives the share in multiple ways 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 | /textfile0.txt | - | path | /textfile0.txt | + | file_target | /textfile0.txt | + | path | /textfile0.txt | | permissions | share,read,update | | uid_owner | %username% | | displayname_owner | %displayname% | @@ -43,13 +43,13 @@ Feature: share resources where the sharee receives the share in multiple ways 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 user "Brian" should see the following elements - | /PARENT/ | - | /PARENT/parent.txt | - | /CHILD/ | - | /CHILD/child.txt | - And the OCS status code should be "" - And the HTTP status code should be "200" + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "200" + And user "Brian" should see the following elements + | /PARENT/ | + | /PARENT/parent.txt | + | /CHILD/ | + | /CHILD/child.txt | Examples: | ocs_api_version | ocs_status_code | | 1 | 100 | @@ -101,7 +101,9 @@ Feature: share resources where the sharee receives the share in multiple ways 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" gets the info of the last share using the sharing API - Then the fields of the last response about user "Brian" sharing with user "Alice" should include + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "200" + And the fields of the last response about user "Brian" sharing with user "Alice" should include | uid_owner | %username% | | share_with | %username% | | file_target | /randomfile.txt | @@ -109,7 +111,9 @@ Feature: share resources where the sharee receives the share in multiple ways | permissions | read | When user "Carol" shares file "randomfile.txt" with user "Alice" with permissions "read,update" using the sharing API And user "Alice" gets the info of the last share using the sharing API - Then the fields of the last response about user "Carol" sharing with user "Alice" should include + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "200" + And the fields of the last response about user "Carol" sharing with user "Alice" should include | uid_owner | %username% | | share_with | %username% | | file_target | /randomfile (2).txt | @@ -118,9 +122,9 @@ Feature: share resources where the sharee receives the share in multiple ways And the content of file "randomfile.txt" for user "Alice" should be "First data" And the content of file "randomfile (2).txt" for user "Alice" should be "Second data" Examples: - | ocs_api_version | - | 1 | - | 2 | + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | @issue-ocis-2131 Scenario Outline: multiple users share a folder with the same name to a user @@ -135,7 +139,9 @@ Feature: share resources where the sharee receives the share in multiple ways 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" gets the info of the last share using the sharing API - Then the fields of the last response about user "Brian" sharing with user "Alice" should include + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "200" + And the fields of the last response about user "Brian" sharing with user "Alice" should include | uid_owner | %username% | | share_with | %username% | | file_target | /zzzfolder | @@ -143,7 +149,9 @@ Feature: share resources where the sharee receives the share in multiple ways | permissions | read,delete | When user "Carol" shares folder "zzzfolder" with user "Alice" with permissions "read,share" using the sharing API And user "Alice" gets the info of the last share using the sharing API - Then the fields of the last response about user "Carol" sharing with user "Alice" should include + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "200" + And the fields of the last response about user "Carol" sharing with user "Alice" should include | uid_owner | %username% | | share_with | %username% | | file_target | /zzzfolder (2) | @@ -152,9 +160,9 @@ Feature: share resources where the sharee receives the share in multiple ways And as "Alice" folder "zzzfolder/Brian" should exist And as "Alice" folder "zzzfolder (2)/Carol" should exist Examples: - | ocs_api_version | - | 1 | - | 2 | + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | @skipOnEncryptionType:user-keys @encryption-issue-132 @skipOnLDAP Scenario Outline: share with a group and then add a user to that group that already has a file with the shared name @@ -171,10 +179,12 @@ Feature: share resources where the sharee receives the share in multiple ways And user "Carol" has uploaded file with content "My content" to "lorem.txt" When user "Alice" shares file "lorem.txt" with group "grp1" using the sharing API And the administrator adds user "Carol" to group "grp1" using the provisioning API - Then the content of file "lorem.txt" for user "Brian" should be "Shared content" + Then the OCS status code of responses on all endpoints should be "" + And the HTTP status code of responses on all endpoints should be "200" + And the content of file "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 "lorem (2).txt" for user "Carol" should be "Shared content" Examples: - | ocs_api_version | - | 1 | - | 2 | + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | \ No newline at end of file diff --git a/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareResourceCaseSensitiveName.feature b/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareResourceCaseSensitiveName.feature index 4e5381bf33fd..cf0e78a65f38 100644 --- a/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareResourceCaseSensitiveName.feature +++ b/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareResourceCaseSensitiveName.feature @@ -17,7 +17,7 @@ Feature: Sharing resources with different case names with the sharee and checkin | 123textfile.txt | | textfile.XYZ.txt | And user "Brian" has uploaded the following files with content "some data" - | path | + | path | | TEXTFILE.txt | | TEXT_FILE.txt | | 123TEXTFILE.txt | @@ -28,8 +28,10 @@ Feature: Sharing resources with different case names with the sharee and checkin | text_file.txt | | 123textfile.txt | | textfile.XYZ.txt | - Then as "Brian" the following files should exist - | path | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" the following files should exist + | path | | TEXTFILE.txt | | TEXT_FILE.txt | | 123TEXTFILE.txt | @@ -59,7 +61,9 @@ Feature: Sharing resources with different case names with the sharee and checkin | /F_O/ | | /123FO/ | | /FO.XYZ/ | - Then as "Brian" the following folders should exist + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" the following folders should exist | path | | /FO/ | | /F_O/ | @@ -90,12 +94,14 @@ Feature: Sharing resources with different case names with the sharee and checkin | case_sensitive.txt | | 123CASE_SENSITIVE.txt | | casesensitive.xyz.txt | - Then as "Brian" the following folders should exist - | path | - | /CASESENSITIVE/ | - | /CASE_SENSITIVE/ | - | /123case_sensitive/ | - | /CASESENSITIVE.xyz/ | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" the following folders should exist + | path | + | /CASESENSITIVE/ | + | /CASE_SENSITIVE/ | + | /123case_sensitive/ | + | /CASESENSITIVE.xyz/ | And as "Brian" the following files should exist | path | | casesensitive.txt | @@ -123,18 +129,20 @@ Feature: Sharing resources with different case names with the sharee and checkin | /CASE_SENSITIVE/ | | /123case_sensitive/ | | /CASESENSITIVE.xyz/ | - Then as "Brian" the following files should exist + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" the following files should exist | path | | casesensitive.txt | | case_sensitive.txt | | 123CASE_SENSITIVE.txt | | casesensitive.xyz.txt | And as "Brian" the following folders should exist - | path | - | /CASESENSITIVE/ | - | /CASE_SENSITIVE/ | - | /123case_sensitive/ | - | /CASESENSITIVE.xyz/ | + | path | + | /CASESENSITIVE/ | + | /CASE_SENSITIVE/ | + | /123case_sensitive/ | + | /CASESENSITIVE.xyz/ | Scenario: sharing file with group members that has existing files with different case names @@ -147,7 +155,7 @@ Feature: Sharing resources with different case names with the sharee and checkin | 123textfile.txt | | textfile.XYZ.txt | And user "Brian" has uploaded the following files with content "some data" - | path | + | path | | TEXTFILE.txt | | TEXT_FILE.txt | | 123TEXTFILE.txt | @@ -158,8 +166,10 @@ Feature: Sharing resources with different case names with the sharee and checkin | text_file.txt | | 123textfile.txt | | textfile.XYZ.txt | - Then as "Brian" the following files should exist - | path | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" the following files should exist + | path | | TEXTFILE.txt | | TEXT_FILE.txt | | 123TEXTFILE.txt | @@ -191,7 +201,9 @@ Feature: Sharing resources with different case names with the sharee and checkin | /F_O/ | | /123FO/ | | /FO.XYZ/ | - Then as "Brian" the following folders should exist + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" the following folders should exist | path | | /fo/ | | /f_o/ | @@ -224,12 +236,14 @@ Feature: Sharing resources with different case names with the sharee and checkin | case_sensitive.txt | | 123CASE_SENSITIVE.txt | | casesensitive.xyz.txt | - Then as "Brian" the following folders should exist - | path | - | /CASESENSITIVE/ | - | /CASE_SENSITIVE/ | - | /123case_sensitive/ | - | /CASESENSITIVE.xyz/ | + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" the following folders should exist + | path | + | /CASESENSITIVE/ | + | /CASE_SENSITIVE/ | + | /123case_sensitive/ | + | /CASESENSITIVE.xyz/ | And as "Brian" the following files should exist | path | | casesensitive.txt | @@ -258,15 +272,17 @@ Feature: Sharing resources with different case names with the sharee and checkin | /CASE_SENSITIVE/ | | /123case_sensitive/ | | /CASESENSITIVE.xyz/ | - Then as "Brian" the following files should exist + Then the OCS status code of responses on all endpoints should be "100" + And the HTTP status code of responses on all endpoints should be "200" + And as "Brian" the following files should exist | path | | casesensitive.txt | | case_sensitive.txt | | 123CASE_SENSITIVE.txt | | casesensitive.xyz.txt | And as "Brian" the following folders should exist - | path | - | /CASESENSITIVE/ | - | /CASE_SENSITIVE/ | - | /123case_sensitive/ | - | /CASESENSITIVE.xyz/ | + | path | + | /CASESENSITIVE/ | + | /CASE_SENSITIVE/ | + | /123case_sensitive/ | + | /CASESENSITIVE.xyz/ | diff --git a/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareUniqueReceivedNames.feature b/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareUniqueReceivedNames.feature index 67d5274d85da..8c85193eeb40 100644 --- a/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareUniqueReceivedNames.feature +++ b/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareUniqueReceivedNames.feature @@ -15,6 +15,8 @@ Feature: resources shared with the same name are received with unique names And user "Brian" has created folder "/foo" When user "Alice" shares folder "/foo" with user "Carol" using the sharing API And user "Brian" shares folder "/foo" with user "Carol" using the sharing API - Then user "Carol" should see the following elements - | /foo/ | + 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 + | /foo/ | | /foo (2)/ | diff --git a/tests/acceptance/features/apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature b/tests/acceptance/features/apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature index ecd715c45120..94647ea0c5ee 100644 --- a/tests/acceptance/features/apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature +++ b/tests/acceptance/features/apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature @@ -10,7 +10,7 @@ Feature: share resources where the sharee receives the share in multiple ways | Brian | - Scenario Outline: Creating a new share with user who already received a share through their group + Scenario Outline: creating and accepting a new share with user who already received a share through their group Given using OCS API version "" And group "grp1" has been created And user "Brian" has been added to group "grp1" @@ -20,9 +20,7 @@ Feature: share resources where the sharee receives the share in multiple ways When user "Alice" shares file "/textfile0.txt" with user "Brian" using the sharing API Then the OCS status code should be "" And the HTTP status code should be "200" - When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API - Then the OCS status code should be "" - 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% | @@ -60,12 +58,8 @@ Feature: share resources where the sharee receives the share in multiple ways And user "Alice" shares folder "/PARENT/CHILD" with group "grp4" using the sharing API Then the OCS status code should be "" And the HTTP status code should be "200" - When user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" - And user "Brian" accepts share "" offered by user "Alice" using the sharing API - And the OCS status code should be "" - 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 "" offered by user "Alice" And user "Brian" should see the following elements | /Shares/PARENT/ | | /Shares/PARENT/parent.txt | @@ -93,9 +87,7 @@ Feature: share resources where the sharee receives the share in multiple ways When user "Alice" shares folder "/test/sub" with user "Brian" using the sharing API Then the OCS status code should be "" And the HTTP status code should be "200" - When user "Brian" accepts share "" offered by user "Alice" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" + And user "Brian" should be able to accept pending share "" offered by user "Alice" And as "Brian" folder "/Shares/sub" should exist @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 Examples: @@ -120,9 +112,7 @@ Feature: share resources where the sharee receives the share in multiple ways When user "Alice" shares folder "/test/sub" with user "Brian" using the sharing API Then the OCS status code should be "" And the HTTP status code should be "200" - When user "Brian" accepts share "" offered by user "Alice" using the sharing API - Then the OCS status code should be "" - And the HTTP status code should be "200" + And user "Brian" should be able to accept pending share "" offered by user "Alice" And as "Brian" folder "/Shares/sub" should exist @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 Examples: @@ -144,8 +134,7 @@ Feature: share resources where the sharee receives the share in multiple ways 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 - And user "Alice" gets the info of the last share using the sharing API - Then the fields of the last response about user "Brian" sharing with user "Alice" should include + Then the info about the last share by user "Brian" with user "Alice" should include | uid_owner | %username% | | share_with | %username% | | file_target | | @@ -153,8 +142,7 @@ Feature: share resources where the sharee receives the share in multiple ways | 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 - And user "Alice" gets the info of the last share using the sharing API - Then the fields of the last response about user "Carol" sharing with user "Alice" should include + Then the info about the last share by user "Carol" with user "Alice" should include | uid_owner | %username% | | share_with | %username% | | file_target | | @@ -184,8 +172,7 @@ Feature: share resources where the sharee receives the share in multiple ways 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 - And user "Alice" gets the info of the last share using the sharing API - Then the fields of the last response about user "Brian" sharing with user "Alice" should include + Then the info about the last share by user "Brian" with user "Alice" should include | uid_owner | %username% | | share_with | %username% | | file_target | | @@ -193,8 +180,7 @@ Feature: share resources where the sharee receives the share in multiple ways | permissions | read,delete | When user "Carol" shares folder "zzzfolder" with user "Alice" with permissions "read,share" using the sharing API And user "Alice" accepts share "/zzzfolder" offered by user "Carol" using the sharing API - And user "Alice" gets the info of the last share using the sharing API - Then the fields of the last response about user "Carol" sharing with user "Alice" should include + Then the info about the last share by user "Carol" with user "Alice" should include | uid_owner | %username% | | share_with | %username% | | file_target | | @@ -224,17 +210,22 @@ Feature: share resources where the sharee receives the share in multiple ways 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" - 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 content of file "Shares/lorem.txt" for user "Brian" should be "Shared content" + 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 "" + 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 | - | 1 | - | 2 | + | 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 @@ -247,17 +238,29 @@ Feature: share resources where the sharee receives the share in multiple ways | /parent/child1/child2 | And user "Alice" has been added to group "grp1" And user "Brian" has been added to group "grp1" - When user "Carol" shares folder "/parent" with user "Brian" with permissions "all" using the sharing API - And user "Carol" shares folder "/parent/child1" with group "grp1" with permissions "read" using the sharing API - And user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API - And user "Brian" accepts share "" offered by user "Carol" using the sharing API - And user "Alice" accepts share "" offered by user "Carol" using the sharing API - Then 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 "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 "" offered by user "Carol" + And user "Alice" has accepted share "" offered by user "Carol" + When user "Brian" creates folder "/Shares/parent/fo1" using the WebDAV API + Then the HTTP status code should be "201" + When user "Brian" creates folder "/Shares/parent/child1/fo2" using the WebDAV API + Then the HTTP status code should be "201" And as "Brian" folder "/Shares/child1" should exist - And user "Brian" should not be able to create folder "/Shares/child1/fo3" + When user "Brian" creates folder "/Shares/child1/fo3" using the WebDAV API + Then the HTTP status code should be "403" And as "Alice" folder "/Shares/child1" should exist - And user "Alice" should not be able to create folder "/Shares/child1/fo3" + When user "Alice" creates folder "/Shares/child1/fo3" using the WebDAV API + Then the HTTP status code should be "403" @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 @issue-2440 Examples: | path | @@ -280,16 +283,27 @@ Feature: share resources where the sharee receives the share in multiple ways 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" - When user "Carol" shares folder "/parent" with user "Brian" with permissions "all" using the sharing API - And user "Carol" shares folder "/parent/child1" with group "grp1" with permissions "read" using the sharing API - And user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API - And user "Brian" accepts share "" offered by user "Carol" using the sharing API - And user "Alice" accepts share "" offered by user "Carol" using the sharing API - Then user "Brian" should be able to rename file "/Shares/parent/child1/child2/textfile-2.txt" to "/Shares/parent/child1/child2/rename.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 | + And user "Brian" has accepted share "/parent" offered by user "Carol" + And user "Brian" has accepted share "" offered by user "Carol" + And user "Alice" has accepted share "" offered by user "Carol" + When user "Brian" moves file "/Shares/parent/child1/child2/textfile-2.txt" to "/Shares/parent/child1/child2/rename.txt" using the WebDAV API + Then the HTTP status code should be "201" And as "Brian" file "/Shares/child1/child2/rename.txt" should exist - And user "Brian" should not be able to rename file "/Shares/child1/child2/rename.txt" to "/Shares/child1/child2/rename2.txt" + When user "Brian" moves file "/Shares/child1/child2/rename.txt" to "/Shares/child1/child2/rename2.txt" using the WebDAV API + Then the HTTP status code should be "403" And as "Alice" file "/Shares/child1/child2/rename.txt" should exist - And user "Alice" should not be able to rename file "/Shares/child1/child2/rename.txt" to "/Shares/child1/child2/rename2.txt" + When user "Alice" moves file "/Shares/child1/child2/rename.txt" to "/Shares/child1/child2/rename2.txt" using the WebDAV API + Then the HTTP status code should be "403" @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 @issue-2440 Examples: | path | @@ -312,16 +326,28 @@ Feature: share resources where the sharee receives the share in multiple ways 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" - When user "Carol" shares folder "/parent" with user "Brian" with permissions "all" using the sharing API - And user "Carol" shares folder "/parent/child1" with group "grp1" with permissions "read" using the sharing API - And user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API - And user "Brian" accepts share "" offered by user "Carol" using the sharing API - And user "Alice" accepts share "" offered by user "Carol" using the sharing API - Then user "Brian" should be able to delete file "/Shares/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 | + And user "Brian" has accepted share "/parent" offered by user "Carol" + And user "Brian" has accepted share "" offered by user "Carol" + And user "Alice" has accepted share "" offered by user "Carol" + When user "Brian" deletes file "/Shares/parent/child1/child2/textfile-2.txt" using the WebDAV API + Then the HTTP status code should be "204" + And as "Brian" file "/Shares/child1/child2/textfile-2.txt" should not exist And as "Brian" folder "/Shares/child1" should exist - And user "Brian" should not be able to delete folder "/Shares/child1/child2" + When user "Brian" deletes folder "/Shares/child1/child2" using the WebDAV API + Then the HTTP status code should be "403" And as "Alice" folder "/Shares/child1" should exist - And user "Alice" should not be able to delete folder "/Shares/child1/child2" + When user "Alice" deletes folder "/Shares/child1/child2" using the WebDAV API + Then the HTTP status code should be "403" @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 @issue-2440 Examples: | path | @@ -343,13 +369,29 @@ Feature: share resources where the sharee receives the share in multiple ways | /parent/child1/child2 | And user "Alice" has been added to group "grp1" And user "Brian" has been added to group "grp1" - When user "Carol" shares folder "/parent" with user "Brian" with permissions "all" using the sharing API - And user "Carol" shares folder "/parent/child1" with group "grp1" with permissions "read" using the sharing API - And user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API - And user "Brian" accepts share "" offered by user "Carol" using the sharing API - And user "Alice" accepts share "" offered by user "Carol" using the sharing API - Then user "Brian" should be able to share folder "/Shares/parent" with user "Alice" with permissions "read" using the sharing API - And user "Alice" accepts share "/parent" offered by user "Brian" using the sharing API + 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 "" offered by user "Carol" + And user "Alice" has accepted share "" 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" + When user "Alice" accepts share "/parent" offered by user "Brian" using the sharing API + And the HTTP status code should be "200" + And the OCS status code should be "100" And as "Brian" folder "/Shares/child1" should exist And as "Alice" folder "/Shares/child1" should exist And as "Alice" folder "/Shares/parent" should exist @@ -374,17 +416,33 @@ Feature: share resources where the sharee receives the share in multiple ways | /parent/child1/child2 | And user "Alice" has been added to group "grp1" And user "Brian" has been added to group "grp1" - When user "Carol" shares folder "/parent" with group "grp1" with permissions "read" using the sharing API - And user "Carol" shares folder "/parent/child1" with user "Brian" with permissions "all" using the sharing API - And user "Brian" accepts share "" 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 user "Brian" should be able to create folder "/Shares/child1/fo1" - And user "Brian" should be able to create folder "/Shares/child1/child2/fo2" + 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 | + And user "Brian" has accepted share "" offered by user "Carol" + And user "Brian" has accepted share "/parent" offered by user "Carol" + And user "Alice" has accepted share "/parent" offered by user "Carol" + When user "Brian" creates folder "/Shares/child1/fo1" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" folder "/Shares/child1/fo1" should exist + When user "Brian" creates folder "/Shares/child1/child2/fo2" using the WebDAV API + Then the HTTP status code should be "201" + And as "Brian" folder "/Shares/child1/child2/fo2" should exist And as "Brian" folder "/Shares/parent" should exist - And user "Brian" should not be able to create folder "/Shares/parent/fo3" + When user "Brian" creates folder "/Shares/parent/fo3" using the WebDAV API + Then the HTTP status code should be "403" + And as "Brian" folder "/Shares/parent/fo3" should not exist And as "Alice" folder "/Shares/parent" should exist - And user "Alice" should not be able to create folder "/Shares/parent/fo3" + When user "Alice" creates folder "/Shares/parent/fo3" using the WebDAV API + Then the HTTP status code should be "403" + And as "Alice" folder "/Shares/parent/fo3" should not exist @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 Examples: | path | @@ -407,12 +465,22 @@ Feature: share resources where the sharee receives the share in multiple ways 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" - When user "Carol" shares folder "/parent" with group "grp1" with permissions "read" using the sharing API - And user "Carol" shares folder "/parent/child1" with user "Brian" with permissions "all" using the sharing API - And user "Brian" accepts share "" offered by user "Carol" using the sharing API + 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 "" 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 user "Brian" should be able to rename file "/Shares/child1/child2/textfile-2.txt" to "/Shares/child1/child2/rename.txt" + 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 as "Brian" file "/Shares/parent/child1/child2/rename.txt" should exist And user "Brian" should not be able to rename file "/Shares/parent/child1/child2/rename.txt" to "/Shares/parent/child1/child2/rename2.txt" And as "Alice" file "/Shares/parent/child1/child2/rename.txt" should exist @@ -439,12 +507,22 @@ Feature: share resources where the sharee receives the share in multiple ways 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" - When user "Carol" shares folder "/parent" with group "grp1" with permissions "read" using the sharing API - And user "Carol" shares folder "/parent/child1" with user "Brian" with permissions "all" using the sharing API - And user "Brian" accepts share "" offered by user "Carol" using the sharing API + 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 "" 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 user "Brian" should be able to delete file "/Shares/child1/child2/textfile-2.txt" + 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 as "Brian" folder "/Shares/parent" should exist And user "Brian" should not be able to delete folder "/Shares/parent/child1" And as "Alice" folder "/Shares/parent" should exist @@ -470,9 +548,17 @@ Feature: share resources where the sharee receives the share in multiple ways | /parent/child1/child2 | And user "Alice" has been added to group "grp1" And user "Brian" has been added to group "grp1" - When user "Carol" shares folder "/parent" with group "grp1" with permissions "read" using the sharing API - And user "Carol" shares folder "/parent/child1" with user "Brian" with permissions "all" using the sharing API - And user "Brian" accepts share "" offered by user "Carol" using the sharing API + 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 "" 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 user "Brian" should be able to share folder "/Shares/child1" with user "Alice" with permissions "read" using the sharing API @@ -506,9 +592,17 @@ Feature: share resources where the sharee receives the share in multiple ways 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" - When user "Carol" shares folder "/parent" with group "grp1" with permissions "all" using the sharing API - And user "Carol" shares folder "/parent/child1" with group "grp2" with permissions "read" using the sharing API - And user "Alice" accepts share "/parent" offered by user "Carol" using the sharing API + 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 "" offered by user "Carol" using the sharing API Then 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" @@ -540,9 +634,13 @@ Feature: share resources where the sharee receives the share in multiple ways 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" - When user "Alice" shares folder "parent" with group "grp" with permissions "read" using the sharing API - And user "Brian" accepts share "/parent" offered by user "Alice" using the sharing API - And user "Brian" moves folder "/Shares/parent" to "/Shares/sharedParent" using the WebDAV API + 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" + When user "Brian" moves folder "/Shares/parent" to "/Shares/sharedParent" using the WebDAV API And user "Alice" shares folder "parent" with user "Brian" 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". diff --git a/tests/acceptance/features/bootstrap/Sharing.php b/tests/acceptance/features/bootstrap/Sharing.php index bf518c58d80d..257a54ee6d20 100644 --- a/tests/acceptance/features/bootstrap/Sharing.php +++ b/tests/acceptance/features/bootstrap/Sharing.php @@ -1658,6 +1658,7 @@ public function userSharesFileWithGroupUsingTheSharingApi( $group, $permissions ); + $this->pushToLastStatusCodesArrays(); } /** @@ -1915,6 +1916,40 @@ public function userGetsInfoOfLastShareUsingTheSharingApi(string $user, ?string } $language = TranslationHelper::getLanguage($language); $this->getShareData($user, (string)$share_id, $language); + $this->pushToLastStatusCodesArrays(); + } + + /** + * @Then /^the info about the last share by user "([^"]*)" with (user|group) "([^"]*)" should include$/ + * + * @param string $sharer + * @param string $userOrGroup + * @param string $sharee + * @param TableNode $table + * + * @return void + * @throws Exception + */ + public function theInfoAboutTheLastShareByUserWithUserShouldInclude( + string $sharer, + string $userOrGroup, + string $sharee, + TableNode $table + ):void { + $this->userGetsInfoOfLastShareUsingTheSharingApi($sharer); + $rows = $table->getRows(); + $infoTable = []; + for ($index = 0; $index < \count($rows); $index++) { + if ($rows[$index][0] === "ocs_status_code") { + $this->ocsContext->theOCSStatusCodeShouldBe($rows[$index][1]); + } elseif ($rows[$index][0] === "http_status_code") { + $this->thenTheHTTPStatusCodeShouldBe($rows[$index][1]); + } else { + $infoTable[$index] = $rows[$index]; + } + } + $table = new TableNode($infoTable); + $this->checkFieldsOfLastResponseToUser($sharer, $sharee, $table); } /** @@ -3099,6 +3134,24 @@ public function userHasAcceptedThePendingShareOfferedBy($user, $share, $offeredB ); } + /** + * @Then /^user "([^"]*)" should be able to accept pending share "([^"]*)" offered by user "([^"]*)"$/ + * + * @param string $user + * @param string $share + * @param string $offeredBy + * + * @return void + * @throws Exception + */ + public function userShouldBeAbleToAcceptShareOfferedBy( + string $user, + string $share, + string $offeredBy + ) { + $this->userHasAcceptedThePendingShareOfferedBy($user, $share, $offeredBy); + } + /** * * @Then /^the sharing API should report to user "([^"]*)" that these shares are in the (pending|accepted|declined) state$/