From bdeae2c2adfda70564b814ada91b5d257aea4eed Mon Sep 17 00:00:00 2001 From: HariBhandari07 Date: Wed, 23 Sep 2020 14:39:49 +0545 Subject: [PATCH] [Tests-Only] Refactor apiShareCreateSpecial1 to use Shares folder --- .drone.star | 3 +- tests/acceptance/config/behat.yml | 15 +- .../createShareExpirationDate.feature | 2 +- .../createShareReceivedInMultipleWays.feature | 2 +- .../createShareUniqueReceivedNames.feature | 2 +- ...createShareWhenExcludedFromSharing.feature | 2 +- .../createShareExpirationDate.feature | 760 ++++++++++++++++++ .../createShareReceivedInMultipleWays.feature | 192 +++++ .../createShareUniqueReceivedNames.feature | 24 + ...createShareWhenExcludedFromSharing.feature | 80 ++ 10 files changed, 1075 insertions(+), 7 deletions(-) rename tests/acceptance/features/{apiShareCreateSpecial1 => apiShareCreateSpecialRoot1}/createShareExpirationDate.feature (99%) rename tests/acceptance/features/{apiShareCreateSpecial1 => apiShareCreateSpecialRoot1}/createShareReceivedInMultipleWays.feature (99%) rename tests/acceptance/features/{apiShareCreateSpecial1 => apiShareCreateSpecialRoot1}/createShareUniqueReceivedNames.feature (88%) rename tests/acceptance/features/{apiShareCreateSpecial1 => apiShareCreateSpecialRoot1}/createShareWhenExcludedFromSharing.feature (98%) create mode 100644 tests/acceptance/features/apiShareCreateSpecialShares1/createShareExpirationDate.feature create mode 100644 tests/acceptance/features/apiShareCreateSpecialShares1/createShareReceivedInMultipleWays.feature create mode 100644 tests/acceptance/features/apiShareCreateSpecialShares1/createShareUniqueReceivedNames.feature create mode 100644 tests/acceptance/features/apiShareCreateSpecialShares1/createShareWhenExcludedFromSharing.feature diff --git a/.drone.star b/.drone.star index fc9c5806a667..a797b49c0562 100644 --- a/.drone.star +++ b/.drone.star @@ -89,7 +89,8 @@ config = { 'apiProvisioning-v2', 'apiProvisioningGroups-v1', 'apiProvisioningGroups-v2', - 'apiShareCreateSpecial1', + 'apiShareCreateSpecialRoot1', + 'apiShareCreateSpecialShares1', 'apiShareCreateSpecialRoot2', 'apiShareCreateSpecialShares2', 'apiSharees', diff --git a/tests/acceptance/config/behat.yml b/tests/acceptance/config/behat.yml index aa08263dc88a..0f9e7b2dbb59 100644 --- a/tests/acceptance/config/behat.yml +++ b/tests/acceptance/config/behat.yml @@ -143,9 +143,20 @@ default: - OccContext: - OccUsersGroupsContext: - apiShareCreateSpecial1: + apiShareCreateSpecialRoot1: paths: - - '%paths.base%/../features/apiShareCreateSpecial1' + - '%paths.base%/../features/apiShareCreateSpecialRoot1' + context: *common_ldap_suite_context + contexts: + - FeatureContext: *common_feature_context_params + - OccContext: + - TrashbinContext: + - WebDavPropertiesContext: + - AppConfigurationContext: + + apiShareCreateSpecialShares1: + paths: + - '%paths.base%/../features/apiShareCreateSpecialShares1' context: *common_ldap_suite_context contexts: - FeatureContext: *common_feature_context_params diff --git a/tests/acceptance/features/apiShareCreateSpecial1/createShareExpirationDate.feature b/tests/acceptance/features/apiShareCreateSpecialRoot1/createShareExpirationDate.feature similarity index 99% rename from tests/acceptance/features/apiShareCreateSpecial1/createShareExpirationDate.feature rename to tests/acceptance/features/apiShareCreateSpecialRoot1/createShareExpirationDate.feature index 0e2982b99897..4ff61de105f3 100644 --- a/tests/acceptance/features/apiShareCreateSpecial1/createShareExpirationDate.feature +++ b/tests/acceptance/features/apiShareCreateSpecialRoot1/createShareExpirationDate.feature @@ -1,4 +1,4 @@ -@api @files_sharing-app-required @toImplementOnOCIS @issue-ocis-reva-41 @issue-ocis-reva-243 @issue-ocis-reva-333 +@api @files_sharing-app-required @notToImplementOnOCIS Feature: a default expiration date can be specified for shares with users or groups Background: diff --git a/tests/acceptance/features/apiShareCreateSpecial1/createShareReceivedInMultipleWays.feature b/tests/acceptance/features/apiShareCreateSpecialRoot1/createShareReceivedInMultipleWays.feature similarity index 99% rename from tests/acceptance/features/apiShareCreateSpecial1/createShareReceivedInMultipleWays.feature rename to tests/acceptance/features/apiShareCreateSpecialRoot1/createShareReceivedInMultipleWays.feature index 26ac962d5fe2..1a15a0b6f9b9 100644 --- a/tests/acceptance/features/apiShareCreateSpecial1/createShareReceivedInMultipleWays.feature +++ b/tests/acceptance/features/apiShareCreateSpecialRoot1/createShareReceivedInMultipleWays.feature @@ -1,4 +1,4 @@ -@api @files_sharing-app-required @toImplementOnOCIS @issue-ocis-reva-34 +@api @files_sharing-app-required @notToImplementOnOCIS Feature: share resources where the sharee receives the share in multiple ways Background: diff --git a/tests/acceptance/features/apiShareCreateSpecial1/createShareUniqueReceivedNames.feature b/tests/acceptance/features/apiShareCreateSpecialRoot1/createShareUniqueReceivedNames.feature similarity index 88% rename from tests/acceptance/features/apiShareCreateSpecial1/createShareUniqueReceivedNames.feature rename to tests/acceptance/features/apiShareCreateSpecialRoot1/createShareUniqueReceivedNames.feature index 098084b9d932..57a46a656f81 100644 --- a/tests/acceptance/features/apiShareCreateSpecial1/createShareUniqueReceivedNames.feature +++ b/tests/acceptance/features/apiShareCreateSpecialRoot1/createShareUniqueReceivedNames.feature @@ -1,4 +1,4 @@ -@api @files_sharing-app-required @toImplementOnOCIS @issue-ocis-reva-11 @issue-ocis-reva-243 +@api @files_sharing-app-required @notToImplementOnOCIS Feature: resources shared with the same name are received with unique names Background: diff --git a/tests/acceptance/features/apiShareCreateSpecial1/createShareWhenExcludedFromSharing.feature b/tests/acceptance/features/apiShareCreateSpecialRoot1/createShareWhenExcludedFromSharing.feature similarity index 98% rename from tests/acceptance/features/apiShareCreateSpecial1/createShareWhenExcludedFromSharing.feature rename to tests/acceptance/features/apiShareCreateSpecialRoot1/createShareWhenExcludedFromSharing.feature index 96d3424812c5..ce5e0ef94c51 100644 --- a/tests/acceptance/features/apiShareCreateSpecial1/createShareWhenExcludedFromSharing.feature +++ b/tests/acceptance/features/apiShareCreateSpecialRoot1/createShareWhenExcludedFromSharing.feature @@ -1,4 +1,4 @@ -@api @files_sharing-app-required @toImplementOnOCIS @issue-ocis-reva-41 +@api @files_sharing-app-required @notToImplementOnOCIS Feature: cannot share resources when in a group that is excluded from sharing Background: diff --git a/tests/acceptance/features/apiShareCreateSpecialShares1/createShareExpirationDate.feature b/tests/acceptance/features/apiShareCreateSpecialShares1/createShareExpirationDate.feature new file mode 100644 index 000000000000..7c288a2dd3bb --- /dev/null +++ b/tests/acceptance/features/apiShareCreateSpecialShares1/createShareExpirationDate.feature @@ -0,0 +1,760 @@ +@api @files_sharing-app-required @toImplementOnOCIS @issue-ocis-reva-41 @issue-ocis-reva-243 @issue-ocis-reva-333 +Feature: a default expiration date can be specified for shares with users or groups + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and skeleton files + + @skipOnOcV10.3 + Scenario Outline: sharing with default expiration date enabled but not enforced for users, user shares without specifying expireDate + Given using OCS API version "" + 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 + When user "Alice" shares folder "/FOLDER" with user "Brian" using the sharing API + And user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API + Then the OCS status code should be "" + And the HTTP 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 | 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 users, user shares with expiration date + Given using OCS API version "" + 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 + When user "Alice" creates a share using the sharing API with settings + | path | /FOLDER | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDate | +15 days | + And user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API + 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 | /Shares/Shares/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 | + + @skipOnOcV10.3 + Scenario Outline: sharing with default expiration date not enabled, user shares with expiration date set + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + When user "Alice" creates a share using the sharing API with settings + | path | /FOLDER | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDate | +15 days | + And user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API + 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 | /Shares/Shares/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 | + + @skipOnOcV10.3 + Scenario Outline: sharing with default expiration date enabled but not enforced for users, user shares with expiration date and then disables + Given using OCS API version "" + 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 + When user "Alice" creates a share using the sharing API with settings + | path | /FOLDER | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDate | +15 days | + And user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API + 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 | /Shares/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 | + | 1 | + | 2 | + + @skipOnOcV10.3 + Scenario Outline: sharing with default expiration date enabled and enforced for users, user shares with expiration date and then disables + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + 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 + When user "Alice" creates a share using the sharing API with settings + | path | /FOLDER | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + And user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API + 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 | /Shares/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 | + | 1 | + | 2 | + + @skipOnOcV10.3 + Scenario Outline: sharing with default expiration date enabled but not enforced for groups, user shares without specifying expireDate + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + When user "Alice" shares folder "/FOLDER" with group "grp1" using the sharing API + And user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API + Then the OCS status code should be "" + And the HTTP 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 | 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 with expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + When user "Alice" creates a share using the sharing API with settings + | path | /FOLDER | + | shareType | group | + | shareWith | grp1 | + | permissions | read,share | + | expireDate | +15 days | + And user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API + 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 group "grp1" should include + | share_type | group | + | file_target | /Shares/Shares/FOLDER | + | uid_owner | %username% | + | expiration | +15 days | + | share_with | grp1 | + 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 | + + @skipOnOcV10.3 + Scenario Outline: sharing with default expiration date not enabled for groups, user shares with expiration date set + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + When user "Alice" creates a share using the sharing API with settings + | path | /FOLDER | + | shareType | group | + | shareWith | grp1 | + | permissions | read,share | + | expireDate | +15 days | + And user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API + 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 group "grp1" should include + | share_type | group | + | file_target | /Shares/Shares/FOLDER | + | uid_owner | %username% | + | expiration | +15 days | + | share_with | grp1 | + 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 | + + @skipOnOcV10.3 + Scenario Outline: sharing with default expiration date enabled but not enforced for groups, user shares with expiration date and then disables + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + When user "Alice" creates a share using the sharing API with settings + | path | /FOLDER | + | shareType | group | + | shareWith | grp1 | + | permissions | read,share | + | expireDate | +15 days | + And user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API + 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 | /Shares/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 | + | 1 | + | 2 | + + @skipOnOcV10.3 + Scenario Outline: sharing with default expiration date enabled and enforced for groups, user shares with expiration date and then disables + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + When user "Alice" creates a share using the sharing API with settings + | path | /FOLDER | + | shareType | group | + | shareWith | grp1 | + | permissions | read,share | + | expireDate | +3 days | + And user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API + 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 | /Shares/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 | + | 1 | + | 2 | + + @skipOnOcV10.3 + Scenario Outline: sharing with default expiration date enabled and enforced for users, user shares without setting expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + 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 + When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API + And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + Then the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_type | user | + | file_target | /Shares/Shares/textfile0.txt | + | 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 | + | 1 | + | 2 | + + @skipOnOcV10.3 + Scenario Outline: sharing with default expiration date enabled and enforced for users, user shares with expiration date more than the default + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + 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 + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDate | +10 days | + Then the HTTP status code should be "" + And the OCS status code should be "404" + And the OCS status message should be "Cannot set expiration date more than 7 days in the future" + And user "Brian" should not have any received shares + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + @skipOnOcV10.3 + Scenario Outline: sharing with default expiration date enabled and enforced for users/max expire date is set, user shares without setting expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + 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 + When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API + And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + Then the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_type | user | + | file_target | /Shares/Shares/textfile0.txt | + | uid_owner | %username% | + | share_with | %username% | + | 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 | + + @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 + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + 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 + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDate | +40 days | + Then the HTTP status code should be "" + And the OCS status code should be "404" + And the OCS status message should be "Cannot set expiration date more than 30 days in the future" + And user "Brian" should not have any received shares + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + @skipOnOcV10.3 + Scenario Outline: sharing with default expiration date enabled and enforced for users/max expire date is set, user shares and changes the max expire date greater than the previous one + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + 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 + When user "Alice" shares file "textfile0.txt" with user "Brian" with permissions "read,share" using the sharing API + And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" 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 | + Examples: + | 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 + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + 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 + When user "Alice" shares file "textfile0.txt" with user "Brian" with permissions "read,share" using the sharing API + And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" 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 | + Examples: + | 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 + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + When user "Alice" shares file "textfile0.txt" with group "grp1" using the sharing API + And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" 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 | /Shares/Shares/textfile0.txt | + | uid_owner | %username% | + | share_with | grp1 | + | 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 | + | 1 | + | 2 | + + @skipOnOcV10.3 + Scenario Outline: sharing with default expiration date enabled and enforced for groups, user shares with expiration date more than the default + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | group | + | shareWith | grp1 | + | permissions | read,share | + | expireDate | +10 days | + Then the HTTP status code should be "" + And the OCS status code should be "404" + And the OCS status message should be "Cannot set expiration date more than 7 days in the future" + And user "Brian" should not have any received shares + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + @skipOnOcV10.3 + Scenario Outline: sharing with default expiration date enabled and enforced for groups/max expire date is set, user shares without setting expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + When user "Alice" shares file "textfile0.txt" with group "grp1" using the sharing API + And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" 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 | /Shares/Shares/textfile0.txt | + | uid_owner | %username% | + | share_with | grp1 | + | 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 | + + @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 + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | group | + | shareWith | grp1 | + | permissions | read,share | + | expireDate | +40 days | + Then the HTTP status code should be "" + And the OCS status code should be "404" + And the OCS status message should be "Cannot set expiration date more than 30 days in the future" + And user "Brian" should not have any received shares + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 404 | + + @skipOnOcV10.3 + Scenario Outline: sharing with default expiration date enabled for groups/max expire date is set, user shares and changes the max expire date greater than the previous one + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + When user "Alice" shares file "textfile0.txt" with group "grp1" with permissions "read,share" using the sharing API + And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" 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 the response when user "Brian" gets the info of the last share should include + | expiration | +30 days | + Examples: + | 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 + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + When user "Alice" shares file "textfile0.txt" with group "grp1" with permissions "read,share" using the sharing API + And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" 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 + | 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 | + + @skipOnOcV10.3 + Scenario Outline: sharing with default expiration date enforced for users, user shares to a group without setting an expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + 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 group "grp1" has been created + And user "Brian" has been added to group "grp1" + When user "Alice" shares file "FOLDER" with group "grp1" with permissions "read,share" using the sharing API + And user "Brian" accepts share "/FOLDER" offered by user "Alice" 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 | | + And the response when user "Brian" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + @skipOnOcV10.3 + Scenario Outline: sharing with default expiration date enforced for groups, user shares to another user + Given using OCS API version "" + And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes" + And user "Brian" has been created with default attributes and without skeleton files + When user "Alice" shares file "/FOLDER" with user "Brian" with permissions "read,share" using the sharing API + And user "Brian" accepts share "/FOLDER" offered by user "Alice" 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 | | + And the response when user "Brian" gets the info of the last share should include + | expiration | | + Examples: + | ocs_api_version | + | 1 | + | 2 | + + @skipOnOcV10.3 + Scenario Outline: sharing with default expiration date enforced for users, user shares with invalid expiration date set + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + 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 + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDateAsString | INVALID-DATE | + Then the HTTP status code should be "" + And the OCS status code should be "" + 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 | + | 1 | 404 | 200 | + | 2 | 404 | 404 | + + @skipOnOcV10.3 + Scenario Outline: sharing with default expiration date enforced for users, user shares with different time format + Given using OCS API version "2" + 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 + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDateAsString | | + And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + Then the HTTP status code should be "200" + And the OCS status code should be "200" + Then the fields of the last response to user "Alice" should include + | expiration | 2050-12-11 | + And the response when user "Brian" gets the info of the last share should include + | expiration | 2050-12-11 | + Examples: + | date | + | 2050-12-11 | + | 11-12-2050 | + | 12/11/2050 | + | 11.12.2050 | + | 11.12.2050 12:30:40 | + + @skipOnOcV10.3 + Scenario Outline: user shares with humanized expiration date format + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" + And user "Brian" has been created with default attributes and without skeleton files + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDateAsString | | + And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + Then 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 | + + @skipOnOcV10.3 + Scenario Outline: user shares with humanized expiration date format in past + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" + And user "Brian" has been created with default attributes and without skeleton files + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDateAsString | yesterday | + Then the HTTP status code should be "" + And the OCS status code should be "" + 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 | 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 | + + @skipOnOcV10.3 + Scenario Outline: user shares with invalid humanized expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "" + And user "Brian" has been created with default attributes and without skeleton files + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDateAsString | 123 | + Then the HTTP status code should be "" + And the OCS status code should be "" + 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 | + + @skipOnOcV10.3 + Scenario Outline: sharing with default expiration date enforced for users, user shares with past expiration date set + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + 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 + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + | expireDateAsString | -10 days | + Then the HTTP status code should be "" + And the OCS status code should be "" + 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 | + + @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 + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "0" + And user "Brian" has been created with default attributes and without skeleton files + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + Then 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 | + + @skipOnOcV10.3 + Scenario Outline: sharing with default expiration date enforced for users, max expire date is 1, user shares without specifying expiration date + Given using OCS API version "" + And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes" + And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "1" + And user "Brian" has been created with default attributes and without skeleton files + When user "Alice" creates a share using the sharing API with settings + | path | textfile0.txt | + | shareType | user | + | shareWith | Brian | + | permissions | read,share | + And user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API + Then 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 | diff --git a/tests/acceptance/features/apiShareCreateSpecialShares1/createShareReceivedInMultipleWays.feature b/tests/acceptance/features/apiShareCreateSpecialShares1/createShareReceivedInMultipleWays.feature new file mode 100644 index 000000000000..d868c9a2fb7b --- /dev/null +++ b/tests/acceptance/features/apiShareCreateSpecialShares1/createShareReceivedInMultipleWays.feature @@ -0,0 +1,192 @@ +@api @files_sharing-app-required @toImplementOnOCIS @issue-ocis-reva-34 +Feature: share resources where the sharee receives the share in multiple ways + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and skeleton files + + Scenario Outline: Creating a new share with user who already received a share through their group + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And user "Alice" has shared file "welcome.txt" with group "grp1" + And user "Brian" has accepted share "/welcome.txt" offered by user "Alice" + When user "Alice" shares file "/welcome.txt" with user "Brian" using the sharing API + And user "Brian" accepts share "/welcome.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 the fields of the last response to user "Alice" sharing with user "Brian" should include + | share_with | %username% | + | share_with_displayname | %displayname% | + | file_target | /Shares/welcome (2).txt | + | path | /Shares/welcome (2).txt | + | permissions | share,read,update | + | uid_owner | %username% | + | displayname_owner | %displayname% | + | item_type | file | + | mimetype | text/plain | + | storage_id | ANY_VALUE | + | share_type | user | + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-reva-243 + Scenario Outline: Share of folder and sub-folder to same user - core#20645 + Given using OCS API version "" + And user "Brian" has been created with default attributes and skeleton files + And group "grp4" has been created + And user "Brian" has been added to group "grp4" + When user "Alice" shares folder "/PARENT" with user "Brian" using the sharing API + And user "Brian" accepts share "/PARENT" offered by user "Alice" using the sharing API + And user "Alice" shares folder "/PARENT/CHILD" with group "grp4" using the sharing API + And user "Brian" accepts share "/PARENT/CHILD" offered by user "Alice" using the sharing API + Then user "Brian" should see the following elements + | /FOLDER/ | + | /Shares/PARENT/ | + | /Shares/PARENT/parent.txt | + | /PARENT/ | + | /PARENT/parent.txt | + | /Shares/CHILD/ | + | /Shares/CHILD/child.txt | + And the OCS status code should be "" + And the HTTP status code should be "200" + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-reva-243 + Scenario Outline: sharing subfolder when parent already shared + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Alice" has created folder "/test" + And user "Alice" has created folder "/test/sub" + And user "Alice" has shared folder "/test" with group "grp1" + When user "Alice" shares folder "/test/sub" with user "Brian" using the sharing API + And user "Brian" accepts share "/test/sub" offered by user "Alice" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Brian" folder "/Shares/sub" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-reva-243 + Scenario Outline: sharing subfolder when parent already shared with group of sharer + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp0" has been created + And user "Alice" has been added to group "grp0" + And user "Alice" has created folder "/test" + And user "Alice" has created folder "/test/sub" + And user "Alice" has shared folder "/test" with group "grp0" + When user "Alice" shares folder "/test/sub" with user "Brian" using the sharing API + And user "Brian" accepts share "/test/sub" offered by user "Alice" using the sharing API + Then the OCS status code should be "" + And the HTTP status code should be "200" + And as "Brian" folder "/Shares/sub" should exist + Examples: + | ocs_api_version | ocs_status_code | + | 1 | 100 | + | 2 | 200 | + + @issue-ocis-reva-243 + Scenario Outline: multiple users share a file with the same name but different permissions to a user + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And user "Brian" has uploaded file with content "First data" to "/randomfile.txt" + And user "Carol" has uploaded file with content "Second data" to "/randomfile.txt" + When user "Brian" shares file "randomfile.txt" with user "Alice" with permissions "read" using the sharing API + And user "Alice" accepts share "/randomfile.txt" offered by user "Brian" using the sharing API + 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 + | uid_owner | %username% | + | share_with | %username% | + | file_target | /Shares/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" 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 + | uid_owner | %username% | + | share_with | %username% | + | file_target | /Shares/randomfile (2).txt | + | item_type | file | + | permissions | read,update | + And the content of file "/Shares/randomfile.txt" for user "Alice" should be "First data" + And the content of file "/Shares/randomfile (2).txt" for user "Alice" should be "Second data" + Examples: + | ocs_api_version | + | 1 | + | 2 | + + @issue-ocis-reva-243 + Scenario Outline: multiple users share a folder with the same name to a user + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And user "Brian" has created folder "/zzzfolder" + And user "Brian" has created folder "zzzfolder/Brian" + And user "Carol" has created folder "/zzzfolder" + And user "Carol" has created folder "zzzfolder/Carol" + When user "Brian" shares folder "zzzfolder" with user "Alice" with permissions "read,delete" using the sharing API + And user "Alice" accepts share "/zzzfolder" offered by user "Brian" using the sharing API + 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 + | uid_owner | %username% | + | share_with | %username% | + | file_target | /Shares/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" 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 + | uid_owner | %username% | + | share_with | %username% | + | file_target | /Shares/zzzfolder (2) | + | item_type | folder | + | permissions | read,share | + And as "Alice" folder "/Shares/zzzfolder/Brian" should exist + And as "Alice" folder "/Shares/zzzfolder (2)/Carol" should exist + Examples: + | 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 + Given using OCS API version "" + And these users have been created with default attributes and without skeleton files: + | username | + | Brian | + | Carol | + And these groups have been created: + | groupname | + | grp1 | + And user "Brian" has been added to group "grp1" + And user "Alice" has uploaded file with content "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 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 | diff --git a/tests/acceptance/features/apiShareCreateSpecialShares1/createShareUniqueReceivedNames.feature b/tests/acceptance/features/apiShareCreateSpecialShares1/createShareUniqueReceivedNames.feature new file mode 100644 index 000000000000..0a003c39bc9a --- /dev/null +++ b/tests/acceptance/features/apiShareCreateSpecialShares1/createShareUniqueReceivedNames.feature @@ -0,0 +1,24 @@ +@api @files_sharing-app-required @toImplementOnOCIS @issue-ocis-reva-11 @issue-ocis-reva-243 +Feature: resources shared with the same name are received with unique names + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And using OCS API version "1" + And these users have been created with default attributes and without skeleton files: + | username | + | Alice | + | Brian | + | Carol | + + @smokeTest + Scenario: unique target names for incoming shares + Given user "Alice" has created folder "/foo" + And user "Brian" has created folder "/foo" + When user "Alice" shares folder "/foo" with user "Carol" using the sharing API + And user "Carol" accepts share "/foo" offered by user "Alice" using the sharing API + And user "Brian" shares folder "/foo" with user "Carol" using the sharing API + And user "Carol" accepts share "/foo" offered by user "Brian" using the sharing API + Then user "Carol" should see the following elements + | /Shares/foo/ | + | /Shares/foo%20(2)/ | diff --git a/tests/acceptance/features/apiShareCreateSpecialShares1/createShareWhenExcludedFromSharing.feature b/tests/acceptance/features/apiShareCreateSpecialShares1/createShareWhenExcludedFromSharing.feature new file mode 100644 index 000000000000..a916da9f45d3 --- /dev/null +++ b/tests/acceptance/features/apiShareCreateSpecialShares1/createShareWhenExcludedFromSharing.feature @@ -0,0 +1,80 @@ +@api @files_sharing-app-required @toImplementOnOCIS @issue-ocis-reva-41 +Feature: cannot share resources when in a group that is excluded from sharing + + Background: + Given the administrator has set the default folder for received shares to "Shares" + And auto-accept shares has been disabled + And user "Alice" has been created with default attributes and skeleton files + + Scenario Outline: user who is excluded from sharing tries to share a file with another user + Given using OCS API version "" + And user "Brian" has been created with default attributes and skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And parameter "shareapi_exclude_groups" of app "core" has been set to "yes" + And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["grp1"]' + And user "Brian" has moved file "welcome.txt" to "fileToShare.txt" + When user "Brian" shares file "fileToShare.txt" with user "Alice" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And as "Alice" file "fileToShare.txt" should not exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 403 | + + Scenario Outline: user who is excluded from sharing tries to share a file with a group + Given using OCS API version "" + And user "Brian" has been created with default attributes and skeleton files + And user "Carol" has been created with default attributes and without skeleton files + And group "grp1" has been created + And group "grp2" has been created + And user "Brian" has been added to group "grp1" + And user "Carol" has been added to group "grp2" + And parameter "shareapi_exclude_groups" of app "core" has been set to "yes" + And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["grp1"]' + And user "Brian" has moved file "welcome.txt" to "fileToShare.txt" + When user "Brian" shares file "fileToShare.txt" with group "grp2" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And as "Carol" file "fileToShare.txt" should not exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 403 | + + Scenario Outline: user who is excluded from sharing tries to share a folder with another user + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp1" has been created + And user "Brian" has been added to group "grp1" + And parameter "shareapi_exclude_groups" of app "core" has been set to "yes" + And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["grp1"]' + And user "Brian" has created folder "folderToShare" + When user "Brian" shares folder "folderToShare" with user "Alice" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And as "Alice" folder "folderToShare" should not exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 403 | + + Scenario Outline: user who is excluded from sharing tries to share a folder with a group + Given using OCS API version "" + And user "Brian" has been created with default attributes and without skeleton files + And group "grp0" has been created + And group "grp1" has been created + And user "Alice" has been added to group "grp0" + And user "Brian" has been added to group "grp1" + And parameter "shareapi_exclude_groups" of app "core" has been set to "yes" + And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["grp0"]' + And user "Alice" has created folder "folderToShare" + When user "Alice" shares folder "folderToShare" with group "grp1" using the sharing API + Then the OCS status code should be "403" + And the HTTP status code should be "" + And as "Brian" folder "folderToShare" should not exist + Examples: + | ocs_api_version | http_status_code | + | 1 | 200 | + | 2 | 403 |