diff --git a/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareExpirationDate.feature b/tests/acceptance/features/apiShareCreateSpecialToRoot1/createShareExpirationDate.feature index 9191a162282f..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 @@ -81,15 +81,15 @@ 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 + When the administrator sets parameter "shareapi_default_expire_date_user_share" of app "core" to "no" + 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% | @@ -109,14 +109,14 @@ 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 + When the administrator sets parameter "shareapi_default_expire_date_user_share" of app "core" to "no" + 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% | @@ -139,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 @@ -164,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 | @@ -174,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 @@ -192,7 +192,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 | @@ -202,9 +202,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 @@ -214,15 +214,15 @@ 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 + When the administrator sets parameter "shareapi_default_expire_date_group_share" of app "core" to "no" + 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% | @@ -244,15 +244,15 @@ 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 + When the administrator sets parameter "shareapi_default_expire_date_group_share" of app "core" to "no" + 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% | @@ -273,7 +273,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 "200" + 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 +284,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 users, user shares with expiration date more than the default @@ -317,7 +319,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 +330,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,11 +365,10 @@ 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 | Examples: | ocs_api_version | | 1 | @@ -379,11 +382,11 @@ 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 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 | | 1 | @@ -399,7 +402,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 +413,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 +452,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 +463,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,10 +502,10 @@ 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 + 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 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 | @@ -517,10 +524,10 @@ 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" gets the info of the last share using the sharing API - Then the fields of the last response to user "Alice" should include + 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 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,8 +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 - 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 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 | | @@ -557,8 +564,7 @@ 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 + Then the info about the last share by user "Alice" with user "Brian" should include | expiration | | And the response when user "Brian" gets the info of the last share should include | expiration | | @@ -628,24 +634,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 @@ -687,17 +695,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 @@ -713,13 +721,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 @@ -734,14 +742,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 +766,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 +784,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 +806,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 +828,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..ea939f615b8c 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 | @@ -100,16 +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 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 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 | @@ -118,9 +118,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 @@ -134,16 +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 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 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) | @@ -171,10 +169,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 | 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..72fc54a3a413 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 as "Alice" 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 as "Alice" the info about the last share by user "Carol" with user "Alice" should include | uid_owner | %username% | | share_with | %username% | | file_target | | @@ -184,17 +172,17 @@ 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 as "Alice" the info about the last share by user "Brian" with user "Alice" should include | uid_owner | %username% | | share_with | %username% | | file_target | | | 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 - 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 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% | | file_target | | @@ -204,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 @@ -224,17 +212,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,16 +240,23 @@ 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 "Carol" has created a share with settings + | path | /parent | + | shareType | user | + | shareWith | Brian | + | permissions | all | + And user "Carol" has created a share with settings + | path | /parent/child1 | + | shareType | group | + | shareWith | grp1 | + | permissions | read | + When user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API And user "Brian" accepts share "" 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" + 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 as "Brian" folder "/Shares/child1" should exist - And user "Brian" should not be able to create folder "/Shares/child1/fo3" - And as "Alice" folder "/Shares/child1" should exist And user "Alice" should not be able to create folder "/Shares/child1/fo3" @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 @issue-2440 Examples: @@ -280,15 +280,23 @@ 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 "Carol" has created a share with settings + | path | /parent | + | shareType | user | + | shareWith | Brian | + | permissions | all | + And user "Carol" has created a share with settings + | path | /parent/child1 | + | shareType | group | + | shareWith | grp1 | + | permissions | read | + When user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API And user "Brian" accepts share "" 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 as "Brian" file "/Shares/child1/child2/rename.txt" should exist + 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 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" @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 @issue-2440 Examples: @@ -312,15 +320,23 @@ 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 "Carol" has created a share with settings + | path | /parent | + | shareType | user | + | shareWith | Brian | + | permissions | all | + And user "Carol" has created a share with settings + | path | /parent/child1 | + | shareType | group | + | shareWith | grp1 | + | permissions | read | + When user "Brian" accepts share "/parent" offered by user "Carol" using the sharing API And user "Brian" accepts share "" 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 as "Brian" folder "/Shares/child1" should exist + 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 as "Alice" folder "/Shares/child1" should exist And user "Alice" should not be able to delete folder "/Shares/child1/child2" @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 @issue-2440 Examples: @@ -343,13 +359,27 @@ 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" + 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 @@ -374,16 +404,25 @@ 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 create folder "/Shares/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 "Brian" should be able to create folder "/Shares/child1/fo1" And user "Brian" should be able to create folder "/Shares/child1/child2/fo2" - And as "Brian" folder "/Shares/parent" should exist + 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 as "Alice" folder "/Shares/parent" should exist And user "Alice" should not be able to create folder "/Shares/parent/fo3" @skipOnOcV10.6 @skipOnOcV10.7 @skipOnOcV10.8.0 Examples: @@ -407,15 +446,23 @@ 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" - And as "Brian" file "/Shares/parent/child1/child2/rename.txt" should exist + Then the HTTP status code of responses on all endpoints should be "200" + And the OCS status code of responses on all endpoints should be "100" + And user "Brian" should be able to rename file "/Shares/child1/child2/textfile-2.txt" to "/Shares/child1/child2/rename.txt" And user "Brian" should not be able to rename file "/Shares/parent/child1/child2/rename.txt" to "/Shares/parent/child1/child2/rename2.txt" - And 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: @@ -439,15 +486,23 @@ 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" - And as "Brian" folder "/Shares/parent" should exist + Then the HTTP status code of responses on all endpoints should be "200" + And the OCS status code of responses on all endpoints should be "100" + And user "Brian" should be able to delete file "/Shares/child1/child2/textfile-2.txt" And user "Brian" should not be able to delete folder "/Shares/parent/child1" - And 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: @@ -470,13 +525,23 @@ 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 - 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 @@ -506,11 +571,21 @@ 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" + 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" @@ -540,21 +615,27 @@ 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" using the sharing API + And user "Alice" has created a share with settings + | path | parent | + | shareType | group | + | shareWith | grp | + | permissions | read | + When user "Brian" accepts share "/parent" offered by user "Alice" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "" + 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 @@ -565,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 @@ -576,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 | @@ -591,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 bf518c58d80d..3392bb821c55 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,47 @@ public function userGetsInfoOfLastShareUsingTheSharingApi(string $user, ?string } $language = TranslationHelper::getLanguage($language); $this->getShareData($user, (string)$share_id, $language); + $this->pushToLastStatusCodesArrays(); + } + + /** + * @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 $sharee + * @param TableNode $table + * + * @return void + * @throws Exception + */ + public function theInfoAboutTheLastShareByUserWithUserShouldInclude( + string $sharer, + string $sharee, + TableNode $table + ):void { + $this->asLastShareInfoAboutUserSharingWithUserShouldInclude($sharer, $sharer, $sharee, $table); } /** @@ -2240,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); } @@ -2251,7 +2300,6 @@ public function theResponseWhenUserGetsInfoOfLastShareShouldInclude( * * @return void * @throws Exception - * */ public function informationOfLastShareShouldInclude( string $user, @@ -3083,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 @@ -3091,12 +3140,13 @@ 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, __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..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); } /** @@ -2074,6 +2075,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(); } /** @@ -3652,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 + ); } /**