From 006713bd3bd8f3fe57b41ee41f87660e0a275644 Mon Sep 17 00:00:00 2001 From: sushmita56 Date: Wed, 9 Mar 2022 09:49:58 +0545 Subject: [PATCH 1/3] 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$/ From 8078e7757e9ac1da771c884fac81ae3779203a0d Mon Sep 17 00:00:00 2001 From: Parajuli Kiran Date: Mon, 28 Mar 2022 14:46:54 +0545 Subject: [PATCH 2/3] Addressed reviews Signed-off-by: Parajuli Kiran --- .../createShareExpirationDate.feature | 175 ++++++++---------- .../createShareReceivedInMultipleWays.feature | 30 +-- .../createShareReceivedInMultipleWays.feature | 47 +++-- .../acceptance/features/bootstrap/Sharing.php | 50 +++-- .../acceptance/features/bootstrap/WebDav.php | 1 + 5 files changed, 142 insertions(+), 161 deletions(-) diff --git a/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareExpirationDate.feature b/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareExpirationDate.feature index c5ce4362b8d7..7434a9212145 100644 --- a/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareExpirationDate.feature +++ b/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareExpirationDate.feature @@ -89,19 +89,17 @@ Feature: a default expiration date can be specified for shares with users or gro | expireDate | +15 days | 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 | | + | share_type | user | + | file_target | /FOLDER | + | uid_owner | %username% | + | expiration | +15 days | + | share_with | %username% | And the response when user "Brian" gets the info of the last share should include | expiration | +15 days | Examples: - | ocs_api_version | ocs_status_code | http_status_code | - | 1 | 100 | 200 | - | 2 | 200 | 200 | + | ocs_api_version | + | 1 | + | 2 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enabled and enforced for users, user shares with expiration date and then disables @@ -115,21 +113,19 @@ Feature: a default expiration date can be specified for shares with users or gro | shareType | user | | shareWith | Brian | | permissions | read,share | - When parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "no" + 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% | - | share_with | %username% | - | expiration | +7 days | - | ocs_status_code | | - | http_status_code | | + | share_type | user | + | file_target | /FOLDER | + | uid_owner | %username% | + | share_with | %username% | + | expiration | +7 days | And the response when user "Brian" gets the info of the last share should include | expiration | +7 days | Examples: - | ocs_api_version | ocs_status_code | http_status_code | - | 1 | 100 | 200 | - | 2 | 200 | 200 | + | ocs_api_version | + | 1 | + | 2 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enabled but not enforced for groups, user shares without specifying expireDate @@ -194,7 +190,7 @@ Feature: a default expiration date can be specified for shares with users or gro | permissions | read,share | | expireDate | +15 days | Then the OCS status code should be "" - And the HTTP status code should be "" + And the HTTP status code should be "200" And the fields of the last response to user "Alice" sharing with group "grp1" should include | share_type | group | | file_target | /FOLDER | @@ -204,9 +200,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 | +15 days | Examples: - | ocs_api_version | ocs_status_code | http_status_code | - | 1 | 100 | 200 | - | 2 | 200 | 200 | + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enabled but not enforced for groups, user shares with expiration date and then disables @@ -224,19 +220,17 @@ Feature: a default expiration date can be specified for shares with users or gro | expireDate | +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 | | + | share_type | group | + | file_target | /FOLDER | + | uid_owner | %username% | + | share_with | grp1 | + | expiration | +15 days | And the response when user "Brian" gets the info of the last share should include | expiration | +15 days | Examples: - | ocs_api_version | ocs_status_code | http_status_code | - | 1 | 100 | 200 | - | 2 | 200 | 200 | + | ocs_api_version | + | 1 | + | 2 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enabled and enforced for groups, user shares with expiration date and then disables @@ -255,19 +249,17 @@ Feature: a default expiration date can be specified for shares with users or gro | expireDate | +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 | | + | share_type | group | + | file_target | /FOLDER | + | uid_owner | %username% | + | share_with | grp1 | + | expiration | +3 days | And the response when user "Brian" gets the info of the last share should include | expiration | +3 days | Examples: - | ocs_api_version | ocs_status_code | http_status_code | - | 1 | 100 | 200 | - | 2 | 200 | 200 | + | ocs_api_version | + | 1 | + | 2 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enabled and enforced for users, user shares without setting expiration date @@ -278,7 +270,7 @@ Feature: a default expiration date can be specified for shares with users or gro 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 OCS status code should be "" - And the HTTP status code should be "" + And the HTTP status code should be "200" And the fields of the last response to user "Alice" sharing with user "Brian" should include | share_type | user | | file_target | /textfile0.txt | @@ -288,9 +280,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 | ocs_status_code | http_status_code | - | 1 | 100 | 200 | - | 2 | 200 | 200 | + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enabled and enforced for users, user shares with expiration date more than the default @@ -372,13 +364,11 @@ Feature: a default expiration date can be specified for shares with users or gro 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 | | + | expiration | +30 days | Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | + | ocs_api_version | + | 1 | + | 2 | @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 @@ -391,13 +381,11 @@ Feature: a default expiration date can be specified for shares with users or gro 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 | | + | expiration | +30 days | Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | + | ocs_api_version | + | 1 | + | 2 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enabled and enforced for groups, user shares without setting expiration date @@ -512,15 +500,13 @@ Feature: a default expiration date can be specified for shares with users or gro 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 | | + | 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 | ocs_status_code | - | 1 | 100 | - | 2 | 200 | + | ocs_api_version | + | 1 | + | 2 | @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 @@ -534,17 +520,14 @@ Feature: a default expiration date can be specified for shares with users or gro And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" 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 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 + Then the response when user "Alice" gets the info of the last share 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 | ocs_status_code | - | 1 | 100 | - | 2 | 200 | + | ocs_api_version | + | 1 | + | 2 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enforced for users, user shares to a group without setting an expiration date @@ -557,15 +540,13 @@ Feature: a default expiration date can be specified for shares with users or gro And user "Alice" has created folder "FOLDER" When user "Alice" shares file "FOLDER" with group "grp1" with permissions "read,share" using the sharing API Then the info about the last share by user "Alice" with group "grp1" should include - | expiration | | - | http_status_code | 200 | - | ocs_status_code | | + | expiration | | And the response when user "Brian" gets the info of the last share should include | expiration | | Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | + | ocs_api_version | + | 1 | + | 2 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enforced for groups, user shares to another user @@ -576,15 +557,13 @@ Feature: a default expiration date can be specified for shares with users or gro And user "Alice" has created folder "FOLDER" When user "Alice" shares file "/FOLDER" with user "Brian" with permissions "read,share" using the sharing API Then the info about the last share by user "Alice" with user "Brian" should include - | expiration | | - | http_status_code | 200 | - | ocs_status_code | | + | expiration | | And the response when user "Brian" gets the info of the last share should include | expiration | | Examples: - | ocs_api_version | ocs_status_code | - | 1 | 100 | - | 2 | 200 | + | ocs_api_version | + | 1 | + | 2 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enforced for users, user shares with invalid expiration date set @@ -708,17 +687,17 @@ Feature: a default expiration date can be specified for shares with users or gro | permissions | read,share | | expireDateAsString | 123 | Then the HTTP status code should be "" - And the OCS status code should be "" + And the OCS status code should be "404" And the OCS status message should be "Invalid date, date format must be YYYY-MM-DD" And user "Brian" should not have any received shares Examples: - | ocs_api_version | ocs_status_code | http_status_code | default | enforce | - | 1 | 404 | 200 | yes | yes | - | 2 | 404 | 404 | yes | yes | - | 1 | 404 | 200 | yes | no | - | 2 | 404 | 404 | yes | no | - | 1 | 404 | 200 | no | no | - | 2 | 404 | 404 | no | no | + | ocs_api_version | http_status_code | default | enforce | + | 1 | 200 | yes | yes | + | 2 | 404 | yes | yes | + | 1 | 200 | yes | no | + | 2 | 404 | yes | no | + | 1 | 200 | no | no | + | 2 | 404 | no | no | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enforced for users, user shares with past expiration date set @@ -734,13 +713,13 @@ Feature: a default expiration date can be specified for shares with users or gro | permissions | read,share | | expireDateAsString | -10 days | Then the HTTP status code should be "" - And the OCS status code should be "" + And the OCS status code should be "404" And the OCS status message should be "Expiration date is in the past" And user "Brian" should not have any received shares Examples: - | ocs_api_version | ocs_status_code | http_status_code | - | 1 | 404 | 200 | - | 2 | 404 | 404 | + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | @skipOnOcV10.3 @issue-36569 Scenario Outline: sharing with default expiration date enforced for users, max expire date is 0, user shares without specifying expiration date diff --git a/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareReceivedInMultipleWays.feature b/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareReceivedInMultipleWays.feature index b5efb1cedd12..ea939f615b8c 100644 --- a/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareReceivedInMultipleWays.feature +++ b/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareReceivedInMultipleWays.feature @@ -100,20 +100,16 @@ Feature: share resources where the sharee receives the share in multiple ways 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" gets the info of the last share using the sharing API - 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 + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Alice" the info about the last share by user "Brian" with user "Alice" should include | uid_owner | %username% | | share_with | %username% | | file_target | /randomfile.txt | | 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" gets the info of the last share using the sharing API - 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 + And as "Alice" the info about the last share by user "Carol" with user "Alice" should include | uid_owner | %username% | | share_with | %username% | | file_target | /randomfile (2).txt | @@ -138,20 +134,14 @@ Feature: share resources where the sharee receives the share in multiple ways 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" gets the info of the last share using the sharing API - 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 + And as "Alice" the info about the last share by user "Brian" with user "Alice" should include | uid_owner | %username% | | share_with | %username% | | file_target | /zzzfolder | | item_type | folder | | 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 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 + And as "Alice" the info about the last share by user "Carol" with user "Alice" should include | uid_owner | %username% | | share_with | %username% | | file_target | /zzzfolder (2) | @@ -160,9 +150,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 | ocs_status_code | - | 1 | 100 | - | 2 | 200 | + | ocs_api_version | + | 1 | + | 2 | @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 @@ -187,4 +177,4 @@ Feature: share resources where the sharee receives the share in multiple ways Examples: | ocs_api_version | ocs_status_code | | 1 | 100 | - | 2 | 200 | \ No newline at end of file + | 2 | 200 | diff --git a/tests/acceptance/features/apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature b/tests/acceptance/features/apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature index 94647ea0c5ee..dce1f72a89e2 100644 --- a/tests/acceptance/features/apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature +++ b/tests/acceptance/features/apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature @@ -134,7 +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 - Then the info about the last share by user "Brian" with user "Alice" should include + 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 | | @@ -142,7 +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 - Then the info about the last share by user "Carol" with user "Alice" should include + 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 | | @@ -172,7 +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 - Then the info about the last share by user "Brian" with user "Alice" should include + 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 | | @@ -180,7 +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 - Then the info about the last share by user "Carol" with user "Alice" should include + 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 | | @@ -258,9 +258,10 @@ Feature: share resources where the sharee receives the share in multiple ways And as "Brian" folder "/Shares/child1" should exist 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 as "Alice" folder "/Shares/child1/fo3" should not exist When user "Alice" creates folder "/Shares/child1/fo3" using the WebDAV API Then the HTTP status code should be "403" + And as "Alice" folder "/Shares/child1/fo3" should not exist @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 @issue-2440 Examples: | path | @@ -299,11 +300,15 @@ Feature: share resources where the sharee receives the share in multiple ways 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 + But as "Brian" file "/Shares/child1/child2/textfile-2.txt" should not exist 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 + But as "Alice" file "/Shares/child1/child2/rename2.txt" should not exist 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" + And as "Alice" file "/Shares/child1/child2/rename2.txt" should not exist + But as "Alice" file "/Shares/child1/child2/rename.txt" should exist @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 @issue-2440 Examples: | path | @@ -348,6 +353,7 @@ Feature: share resources where the sharee receives the share in multiple ways And as "Alice" folder "/Shares/child1" should exist When user "Alice" deletes folder "/Shares/child1/child2" using the WebDAV API Then the HTTP status code should be "403" + And as "Alice" folder "/Shares/child1/child2" should exist @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 @issue-2440 Examples: | path | @@ -389,9 +395,7 @@ Feature: share resources where the sharee receives the share in multiple ways | 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 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 @@ -426,23 +430,16 @@ Feature: share resources where the sharee receives the share in multiple ways | 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 - 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 - 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 + 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 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" @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 Examples: | path | diff --git a/tests/acceptance/features/bootstrap/Sharing.php b/tests/acceptance/features/bootstrap/Sharing.php index 257a54ee6d20..70189cb0e513 100644 --- a/tests/acceptance/features/bootstrap/Sharing.php +++ b/tests/acceptance/features/bootstrap/Sharing.php @@ -1920,10 +1920,31 @@ public function userGetsInfoOfLastShareUsingTheSharingApi(string $user, ?string } /** - * @Then /^the info about the last share by user "([^"]*)" with (user|group) "([^"]*)" should include$/ + * @Then /^as "([^"]*)" the info about the last share by user "([^"]*)" with user "([^"]*)" should include$/ + * + * @param string $requestor + * @param string $sharer + * @param string $sharee + * @param TableNode $table + * + * @return void + * @throws Exception + */ + public function asLastShareInfoAboutUserSharingWithUserShouldInclude( + string $requestor, + string $sharer, + string $sharee, + TableNode $table + ) { + $this->userGetsInfoOfLastShareUsingTheSharingApi($requestor); + $this->ocsContext->assertOCSResponseIndicatesSuccess(); + $this->checkFieldsOfLastResponseToUser($sharer, $sharee, $table); + } + + /** + * @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 * @@ -1932,24 +1953,10 @@ public function userGetsInfoOfLastShareUsingTheSharingApi(string $user, ?string */ 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); + $this->asLastShareInfoAboutUserSharingWithUserShouldInclude($sharer, $sharer, $sharee, $table); } /** @@ -2275,6 +2282,13 @@ public function theResponseWhenUserGetsInfoOfLastShareShouldInclude( 200, "Error getting info of last share for user $user" ); + $this->ocsContext->assertOCSResponseIndicatesSuccess( + __METHOD__ . + ' Error getting info of last share for user $user\n' . + $this->ocsContext->getOCSResponseStatusMessage( + $this->getResponse() + ) . '"' + ); $this->checkFields($user, $body); } @@ -2286,7 +2300,6 @@ public function theResponseWhenUserGetsInfoOfLastShareShouldInclude( * * @return void * @throws Exception - * */ public function informationOfLastShareShouldInclude( string $user, @@ -3132,6 +3145,7 @@ public function userHasAcceptedThePendingShareOfferedBy($user, $share, $offeredB 200, __METHOD__ . " could not accept the pending share $share to $user by $offeredBy" ); + $this->ocsContext->assertOCSResponseIndicatesSuccess(); } /** diff --git a/tests/acceptance/features/bootstrap/WebDav.php b/tests/acceptance/features/bootstrap/WebDav.php index c5ca4891ee01..d75068849430 100644 --- a/tests/acceptance/features/bootstrap/WebDav.php +++ b/tests/acceptance/features/bootstrap/WebDav.php @@ -2074,6 +2074,7 @@ public function userHasUploadedAFileTo(string $user, string $source, string $des "HTTP status code was not 201 or 204 while trying to upload file '$source' to '$destination' for user '$user'" ); $this->emptyLastHTTPStatusCodesArray(); + $this->emptyLastOCSStatusCodesArray(); } /** From a17e280bfc7f5ae6c8cbfb03553d62f68ce3f165 Mon Sep 17 00:00:00 2001 From: Parajuli Kiran Date: Mon, 4 Apr 2022 18:29:15 +0545 Subject: [PATCH 3/3] Adjust reviews in apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature Signed-off-by: Parajuli Kiran Signed-off-by: Kiran Parajuli --- .../createShareExpirationDate.feature | 64 ++++---- .../createShareReceivedInMultipleWays.feature | 144 ++++++++---------- .../acceptance/features/bootstrap/Sharing.php | 21 +-- .../acceptance/features/bootstrap/WebDav.php | 7 + 4 files changed, 112 insertions(+), 124 deletions(-) diff --git a/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareExpirationDate.feature b/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareExpirationDate.feature index 7434a9212145..e7b5bba7c4a7 100644 --- a/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareExpirationDate.feature +++ b/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareExpirationDate.feature @@ -12,15 +12,15 @@ Feature: a default expiration date can be specified for shares with users or gro And user "Alice" has created folder "FOLDER" When user "Alice" shares folder "/FOLDER" with user "Brian" using the sharing API Then the OCS status code should be "" - And the HTTP 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 | | And the response when user "Brian" gets the info of the last share should include | expiration | | Examples: - | ocs_api_version | ocs_status_code | http_status_code | - | 1 | 100 | 200 | - | 2 | 200 | 200 | + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enabled but not enforced for users, user shares with expiration date @@ -35,7 +35,7 @@ Feature: a default expiration date can be specified for shares with users or gro | permissions | read,share | | expireDate | +15 days | Then the OCS status code should be "" - And the HTTP status code should be "" + And the HTTP status code should be "200" And the fields of the last response to user "Alice" sharing with user "Brian" should include | share_type | user | | file_target | /FOLDER | @@ -45,9 +45,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 | +15 days | Examples: - | ocs_api_version | ocs_status_code | http_status_code | - | 1 | 100 | 200 | - | 2 | 200 | 200 | + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date not enabled, user shares with expiration date set @@ -61,7 +61,7 @@ Feature: a default expiration date can be specified for shares with users or gro | permissions | read,share | | expireDate | +15 days | Then the OCS status code should be "" - And the HTTP status code should be "" + And the HTTP status code should be "200" And the fields of the last response to user "Alice" sharing with user "Brian" should include | share_type | user | | file_target | /FOLDER | @@ -71,9 +71,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 | +15 days | Examples: - | ocs_api_version | ocs_status_code | http_status_code | - | 1 | 100 | 200 | - | 2 | 200 | 200 | + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enabled but not enforced for users, user shares with expiration date and then disables @@ -88,7 +88,8 @@ Feature: a default expiration date can be specified for shares with users or gro | permissions | read,share | | expireDate | +15 days | 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 + Then the HTTP status code should be "200" + And the info about the last share by user "Alice" with user "Brian" should include | share_type | user | | file_target | /FOLDER | | uid_owner | %username% | @@ -114,7 +115,8 @@ Feature: a default expiration date can be specified for shares with users or gro | shareWith | Brian | | permissions | read,share | 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 + Then the HTTP status code should be "200" + And the info about the last share by user "Alice" with user "Brian" should include | share_type | user | | file_target | /FOLDER | | uid_owner | %username% | @@ -137,15 +139,15 @@ Feature: a default expiration date can be specified for shares with users or gro And user "Brian" has been added to group "grp1" When user "Alice" shares folder "/FOLDER" with group "grp1" using the sharing API Then the OCS status code should be "" - And the HTTP 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 | | And the response when user "Brian" gets the info of the last share should include | expiration | | Examples: - | ocs_api_version | ocs_status_code | http_status_code | - | 1 | 100 | 200 | - | 2 | 200 | 200 | + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date enabled but not enforced for groups, user shares with expiration date @@ -162,7 +164,7 @@ Feature: a default expiration date can be specified for shares with users or gro | permissions | read,share | | expireDate | +15 days | Then the OCS status code should be "" - And the HTTP status code should be "" + And the HTTP status code should be "200" And the fields of the last response to user "Alice" sharing with group "grp1" should include | share_type | group | | file_target | /FOLDER | @@ -172,9 +174,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 | +15 days | Examples: - | ocs_api_version | ocs_status_code | http_status_code | - | 1 | 100 | 200 | - | 2 | 200 | 200 | + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | @skipOnOcV10.3 Scenario Outline: sharing with default expiration date not enabled for groups, user shares with expiration date set @@ -219,7 +221,8 @@ Feature: a default expiration date can be specified for shares with users or gro | permissions | read,share | | expireDate | +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 + Then the HTTP status code should be "200" + And the info about the last share by user "Alice" with group "grp1" should include | share_type | group | | file_target | /FOLDER | | uid_owner | %username% | @@ -248,7 +251,8 @@ Feature: a default expiration date can be specified for shares with users or gro | permissions | read,share | | expireDate | +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 + Then the HTTP status code should be "200" + And the info about the last share by user "Alice" with group "grp1" should include | share_type | group | | file_target | /FOLDER | | uid_owner | %username% | @@ -380,7 +384,8 @@ Feature: a default expiration date can be specified for shares with users or gro And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" 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 + Then the HTTP status code should be "200" + And the info about the last share by user "Alice" with user "Brian" should include | expiration | +30 days | Examples: | ocs_api_version | @@ -499,7 +504,8 @@ Feature: a default expiration date can be specified for shares with users or gro And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" 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 + Then the HTTP status code should be "200" + And the info about the last share by user "Alice" with user "Brian" should include | expiration | +30 days | And the response when user "Brian" gets the info of the last share should include | expiration | +30 days | @@ -520,7 +526,8 @@ Feature: a default expiration date can be specified for shares with users or gro And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt" 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" - Then the response when user "Alice" gets the info of the last share should include + Then the HTTP status code should be "200" + And the response when user "Alice" gets the info of the last share should include | expiration | +30 days | And the response when user "Brian" gets the info of the last share should include | expiration | +30 days | @@ -539,7 +546,8 @@ 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 - Then the info about the last share by user "Alice" with group "grp1" should include + Then the HTTP status code should be "200" + And the info about the last share by user "Alice" with group "grp1" should include | expiration | | And the response when user "Brian" gets the info of the last share should include | expiration | | diff --git a/tests/acceptance/features/apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature b/tests/acceptance/features/apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature index dce1f72a89e2..72fc54a3a413 100644 --- a/tests/acceptance/features/apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature +++ b/tests/acceptance/features/apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature @@ -179,7 +179,9 @@ Feature: share resources where the sharee receives the share in multiple ways | item_type | folder | | 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 + Then the HTTP status code should be "200" + And the OCS status code should be "" + 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% | @@ -190,15 +192,15 @@ Feature: share resources where the sharee receives the share in multiple ways And as "Alice" folder "/Shares/zzzfolder (2)/Carol" should exist @skipOnOcis Examples: - | ocs_api_version | file_target_1 | file_target_2 | - | 1 | /Shares/zzzfolder | /Shares/zzzfolder (2) | - | 2 | /Shares/zzzfolder | /Shares/zzzfolder (2) | + | 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 | - | 1 | /zzzfolder | /zzzfolder (2) | - | 2 | /zzzfolder | /zzzfolder (2) | + | 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 Scenario Outline: share with a group and then add a user to that group that already has a file with the shared name @@ -248,20 +250,14 @@ Feature: share resources where the sharee receives the share in multiple ways | 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 - 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/fo3" should not exist - When user "Alice" creates folder "/Shares/child1/fo3" using the WebDAV API - Then the HTTP status code should be "403" - And as "Alice" folder "/Shares/child1/fo3" should not exist + When 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 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" @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 @issue-2440 Examples: | path | @@ -294,21 +290,14 @@ Feature: share resources where the sharee receives the share in multiple ways | 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 - But as "Brian" file "/Shares/child1/child2/textfile-2.txt" should not exist - 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 - But as "Alice" file "/Shares/child1/child2/rename2.txt" should not exist - 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" - And as "Alice" file "/Shares/child1/child2/rename2.txt" should not exist - But as "Alice" file "/Shares/child1/child2/rename.txt" should exist + When 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 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" @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 @issue-2440 Examples: | path | @@ -341,19 +330,14 @@ Feature: share resources where the sharee receives the share in multiple ways | 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 - 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 - When user "Alice" deletes folder "/Shares/child1/child2" using the WebDAV API - Then the HTTP status code should be "403" - And as "Alice" folder "/Shares/child1/child2" should exist + When 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 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" @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 @issue-2440 Examples: | path | @@ -478,9 +462,7 @@ Feature: share resources where the sharee receives the share in multiple ways 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 And user "Alice" should not be able to rename file "/Shares/parent/child1/child2/rename.txt" to "/Shares/parent/child1/child2/rename2.txt" @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 @issue-ocis-2440 Examples: @@ -520,9 +502,7 @@ Feature: share resources where the sharee receives the share in multiple ways 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 And user "Alice" should not be able to delete folder "/Shares/parent/child1" @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 @issue-ocis-2440 Examples: @@ -558,8 +538,10 @@ Feature: share resources where the sharee receives the share in multiple ways 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 - And user "Alice" accepts share "" offered by user "Brian" 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 "" 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 @@ -601,7 +583,9 @@ Feature: share resources where the sharee receives the share in multiple ways | 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" + 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" @@ -636,20 +620,22 @@ Feature: share resources where the sharee receives the share in multiple ways | 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 + 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 "" + 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" - Then as "Brian" folder "Shares/parent" should not exist + 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 | - | 1 | - | 2 | + | 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 @@ -660,10 +646,14 @@ 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" shares folder "parent" with user "Brian" with permissions "all" using the sharing 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" + 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 @@ -671,7 +661,6 @@ Feature: share resources where the sharee receives the share in multiple ways 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 - And user "Brian" should be able to delete file "Shares/parent/child/lorem.txt" Examples: | ocs_api_version | | 1 | @@ -686,19 +675,20 @@ 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 "all" 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" shares folder "parent" with user "Brian" with permissions "read" using the sharing API + 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 "" + 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" - Then as "Brian" folder "Shares/parent" should not exist + 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 - And user "Brian" should be able to delete file "Shares/parent/child/lorem.txt" Examples: - | ocs_api_version | - | 1 | - | 2 | + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | diff --git a/tests/acceptance/features/bootstrap/Sharing.php b/tests/acceptance/features/bootstrap/Sharing.php index 70189cb0e513..3392bb821c55 100644 --- a/tests/acceptance/features/bootstrap/Sharing.php +++ b/tests/acceptance/features/bootstrap/Sharing.php @@ -3131,6 +3131,7 @@ public function userAcceptsThePendingShareOfferedBy(string $user, string $share, /** * @Given /^user "([^"]*)" has accepted the (?:first|next|) pending share "([^"]*)" offered by user "([^"]*)"$/ + * @Then /^user "([^"]*)" should be able to accept pending share "([^"]*)" offered by user "([^"]*)"$/ * * @param string $user * @param string $share @@ -3139,7 +3140,7 @@ public function userAcceptsThePendingShareOfferedBy(string $user, string $share, * @return void * @throws Exception */ - public function userHasAcceptedThePendingShareOfferedBy($user, $share, $offeredBy) { + public function userHasAcceptedThePendingShareOfferedBy(string $user, string $share, string $offeredBy) { $this->userAcceptsThePendingShareOfferedBy($user, $share, $offeredBy); $this->theHTTPStatusCodeShouldBe( 200, @@ -3148,24 +3149,6 @@ public function userHasAcceptedThePendingShareOfferedBy($user, $share, $offeredB $this->ocsContext->assertOCSResponseIndicatesSuccess(); } - /** - * @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$/ diff --git a/tests/acceptance/features/bootstrap/WebDav.php b/tests/acceptance/features/bootstrap/WebDav.php index d75068849430..fb406b9a8738 100644 --- a/tests/acceptance/features/bootstrap/WebDav.php +++ b/tests/acceptance/features/bootstrap/WebDav.php @@ -846,6 +846,7 @@ public function theUserShouldNotBeAbleToRenameEntryTo(string $user, string $entr $this->asFileOrFolderShouldExist($user, $entry, $source); $this->userMovesFileUsingTheAPI($user, $source, "", $destination); $this->asFileOrFolderShouldExist($user, $entry, $source); + $this->asFileOrFolderShouldNotExist($user, $entry, $destination); } /** @@ -3653,11 +3654,17 @@ public function userShouldBeAbleToCreateFolder(string $user, string $destination * @param string $destination * * @return void + * @throws Exception */ public function userShouldNotBeAbleToCreateFolder(string $user, string $destination):void { $user = $this->getActualUsername($user); $this->userCreatesFolder($user, $destination); $this->theHTTPStatusCodeShouldBeFailure(); + $this->asFileOrFolderShouldNotExist( + $user, + "folder", + $destination + ); } /**