From 7db5b86bd47d32bea1ae592798de2a3b9c2970a8 Mon Sep 17 00:00:00 2001 From: Swikriti Tripathi Date: Mon, 17 Apr 2023 17:05:12 +0545 Subject: [PATCH] Refactor the syntax of the scenarios in local API tests --- .../assignRole.feature | 7 +- .../createShareToSharesFolder.feature | 2 +- .../webDavPUTAuthInvalid.feature | 2 +- .../delayPostprocessing.feature | 3 + .../features/apiContract/copy.feature | 5 +- .../features/apiContract/propfind.feature | 4 +- .../features/apiContract/sharesReport.feature | 8 +- .../apiContract/spacesSharesReport.feature | 4 +- .../acceptance/features/apiCors/cors.feature | 7 +- .../features/apiGraph/addUserToGroup.feature | 4 +- .../apiGraph/changeOwnPassword.feature | 4 +- .../features/apiGraph/createGroup.feature | 4 +- .../apiGraph/createGroupCaseSensitive.feature | 3 + .../features/apiGraph/createUser.feature | 14 +- .../features/apiGraph/deleteUser.feature | 22 +- .../features/apiGraph/editUser.feature | 33 ++- .../features/apiGraph/getApplications.feature | 1 + .../features/apiGraph/getGroup.feature | 4 +- .../features/apiGraph/getUser.feature | 4 +- .../features/apiSpaces/changeSpaces.feature | 29 +- .../features/apiSpaces/createSpace.feature | 6 +- .../apiSpaces/disableAndDeleteSpaces.feature | 2 +- .../features/apiSpaces/download.feature | 8 +- .../apiSpaces/editPublicLinkOfSpace.feature | 6 +- .../features/apiSpaces/filePreviews.feature | 8 +- .../features/apiSpaces/listSpaces.feature | 17 +- .../features/apiSpaces/notification.feature | 1 + .../features/apiSpaces/quota.feature | 17 +- .../apiSpaces/removeSpaceObjects.feature | 11 +- .../features/apiSpaces/resharing.feature | 20 +- .../apiSpaces/restoreSpaceObjects.feature | 10 +- .../features/apiSpaces/restoreSpaces.feature | 9 +- .../features/apiSpaces/search.feature | 20 +- .../apiSpaces/spaceManagement.feature | 35 +-- .../acceptance/features/apiSpaces/tag.feature | 26 +- .../features/apiSpaces/uploadSpaces.feature | 11 +- .../changingFilesShare.feature | 7 +- .../features/apiSpacesShares/checksum.feature | 7 +- .../apiSpacesShares/copySpaces.feature | 62 ++-- .../apiSpacesShares/etagPropagation.feature | 279 +++++++++--------- .../features/apiSpacesShares/favorite.feature | 3 + .../apiSpacesShares/moveSpaces.feature | 32 +- .../apiSpacesShares/shareOperations.feature | 83 +++--- .../apiSpacesShares/shareSpaces.feature | 49 +-- .../shareSpacesViaLink.feature | 11 +- .../shareSubItemOfSpace.feature | 16 +- .../shareSubItemOfSpaceViaPublicLink.feature | 39 +-- .../apiSpacesShares/shareUploadTUS.feature | 30 +- .../features/bootstrap/GraphContext.php | 2 +- 49 files changed, 528 insertions(+), 463 deletions(-) diff --git a/tests/acceptance/features/apiAccountsHashDifficulty/assignRole.feature b/tests/acceptance/features/apiAccountsHashDifficulty/assignRole.feature index 8ce10f389..26bb74d92 100644 --- a/tests/acceptance/features/apiAccountsHashDifficulty/assignRole.feature +++ b/tests/acceptance/features/apiAccountsHashDifficulty/assignRole.feature @@ -1,9 +1,10 @@ @api Feature: assign role - As an admin, I want to assign roles to users. - I cannot change my own role. - Users without an admin role cannot get the list of roles, assignments list and assign roles to users + As an admin, + I want to assign roles to users + So that I can provide them different authority + Scenario Outline: only admin user can see all existing roles Given user "Alice" has been created with default attributes and without skeleton files And the administrator has given "Alice" the role "" using the settings api diff --git a/tests/acceptance/features/apiAccountsHashDifficulty/createShareToSharesFolder.feature b/tests/acceptance/features/apiAccountsHashDifficulty/createShareToSharesFolder.feature index 7c5a3a7aa..3d4c1aad8 100644 --- a/tests/acceptance/features/apiAccountsHashDifficulty/createShareToSharesFolder.feature +++ b/tests/acceptance/features/apiAccountsHashDifficulty/createShareToSharesFolder.feature @@ -8,7 +8,7 @@ Feature: sharing See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839 - Scenario Outline: Creating a share of a file with a user + Scenario Outline: creating a share of a file with a user Given auto-accept shares has been disabled And using OCS API version "" And user "Alice" has been created with default attributes and without skeleton files diff --git a/tests/acceptance/features/apiAccountsHashDifficulty/webDavPUTAuthInvalid.feature b/tests/acceptance/features/apiAccountsHashDifficulty/webDavPUTAuthInvalid.feature index 5a54999e2..8825f948a 100644 --- a/tests/acceptance/features/apiAccountsHashDifficulty/webDavPUTAuthInvalid.feature +++ b/tests/acceptance/features/apiAccountsHashDifficulty/webDavPUTAuthInvalid.feature @@ -1,7 +1,7 @@ @api @skipOnReva Feature: attempt to PUT files with invalid password As an admin - I want to the system to be secure when passwords are stored with the full hash difficulty + I want the system to be secure when passwords are stored with the full hash difficulty So that unauthorised users do not have access to data Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production diff --git a/tests/acceptance/features/apiAsyncUpload/delayPostprocessing.feature b/tests/acceptance/features/apiAsyncUpload/delayPostprocessing.feature index f50b23926..5c07df275 100644 --- a/tests/acceptance/features/apiAsyncUpload/delayPostprocessing.feature +++ b/tests/acceptance/features/apiAsyncUpload/delayPostprocessing.feature @@ -1,5 +1,8 @@ @api Feature: delay post-processing of uploaded files + As a user + I want to delay the post-processing of uploaded files + So that I can check the early request Background: Given user "Alice" has been created with default attributes and without skeleton files diff --git a/tests/acceptance/features/apiContract/copy.feature b/tests/acceptance/features/apiContract/copy.feature index 984812a61..fe922fecc 100644 --- a/tests/acceptance/features/apiContract/copy.feature +++ b/tests/acceptance/features/apiContract/copy.feature @@ -1,6 +1,9 @@ @api @skipOnOcV10 Feature: Copy test - check that the Copy response contains all the relevant values + As a user + I want to check the PROPFIND response + So that I can make sure that the response contains all the relevant values + Background: Given these users have been created with default attributes and without skeleton files: diff --git a/tests/acceptance/features/apiContract/propfind.feature b/tests/acceptance/features/apiContract/propfind.feature index f778ab51a..3b646c118 100644 --- a/tests/acceptance/features/apiContract/propfind.feature +++ b/tests/acceptance/features/apiContract/propfind.feature @@ -1,6 +1,8 @@ @api @skipOnOcV10 Feature: Propfind test - check that the PROPFIND response contains all the relevant values + As a user + I want to check the PROPFIND response + So that I can make sure that the response contains all the relevant values Background: Given these users have been created with default attributes and without skeleton files: diff --git a/tests/acceptance/features/apiContract/sharesReport.feature b/tests/acceptance/features/apiContract/sharesReport.feature index 44b21502b..42db33a29 100644 --- a/tests/acceptance/features/apiContract/sharesReport.feature +++ b/tests/acceptance/features/apiContract/sharesReport.feature @@ -1,6 +1,8 @@ @api Feature: REPORT request to Shares space - Check that the REPORT response contains all relevant details for Shares + As a user + I want to check the share REPORT response + So that I can make sure that the response contains all the relevant details for shares Background: Given these users have been created with default attributes and without skeleton files: @@ -13,7 +15,7 @@ Feature: REPORT request to Shares space And user "Alice" has shared entry "/folderMain" with user "Brian" with permissions "17" - Scenario Outline: Check the REPORT response of the found folder + Scenario Outline: check the REPORT response of the found folder Given using DAV path And user "Brian" has accepted share "/folderMain" offered by user "Alice" When user "Brian" searches for "SubFolder1" using the WebDAV API @@ -32,7 +34,7 @@ Feature: REPORT request to Shares space | new | - Scenario Outline: Check the REPORT response of the found file + Scenario Outline: check the REPORT response of the found file Given using DAV path And user "Brian" has accepted share "/folderMain" offered by user "Alice" And user "Alice" has uploaded file with content "Not all those who wander are lost." to "/folderMain/SubFolder1/subFOLDER2/frodo.txt" diff --git a/tests/acceptance/features/apiContract/spacesSharesReport.feature b/tests/acceptance/features/apiContract/spacesSharesReport.feature index 651e9f6e6..0a75691d5 100644 --- a/tests/acceptance/features/apiContract/spacesSharesReport.feature +++ b/tests/acceptance/features/apiContract/spacesSharesReport.feature @@ -1,6 +1,8 @@ @api @skipOnOcV10 Feature: Report test - check that the REPORT response contains all the relevant value + As a user + I want to check the share REPORT response + So that I can make sure that the response contains all the relevant details for shares Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839 diff --git a/tests/acceptance/features/apiCors/cors.feature b/tests/acceptance/features/apiCors/cors.feature index 31959e39f..63d3eebe9 100644 --- a/tests/acceptance/features/apiCors/cors.feature +++ b/tests/acceptance/features/apiCors/cors.feature @@ -2,12 +2,15 @@ # CORS_ALLOWED_ORIGINS=https://aphno.badal @api @skipOnOcV10 Feature: CORS headers + As a user + I want to send a cross-origin request + So that I can check if the correct headers are set Background: Given user "Alice" has been created with default attributes and without skeleton files @issue-5195 - Scenario Outline: CORS headers should be returned when setting CORS domain sending Origin header + Scenario Outline: CORS headers should be returned when setting CORS domain sending origin header Given using OCS API version "" When user "Alice" sends HTTP method "GET" to OCS API endpoint "" with headers | header | value | @@ -28,7 +31,7 @@ Feature: CORS headers | 2 | /apps/files_sharing/api/v1/shares | 200 | 200 | - Scenario Outline: CORS headers should not be returned when CORS domain does not match Origin header + Scenario Outline: CORS headers should not be returned when CORS domain does not match origin header Given using OCS API version "" When user "Alice" sends HTTP method "GET" to OCS API endpoint "" with headers | header | value | diff --git a/tests/acceptance/features/apiGraph/addUserToGroup.feature b/tests/acceptance/features/apiGraph/addUserToGroup.feature index 468a598db..1d842f704 100644 --- a/tests/acceptance/features/apiGraph/addUserToGroup.feature +++ b/tests/acceptance/features/apiGraph/addUserToGroup.feature @@ -120,10 +120,10 @@ Feature: add users to group | Alice | var/../etc | @issue-5938 - Scenario Outline: user other than the admin tries to add himself to a group + Scenario Outline: user other than the admin tries to add herself to a group Given the administrator has given "Alice" the role "" using the settings api And group "groupA" has been created - When user "Alice" tries to add himself to group "groupA" using the Graph API + When user "Alice" tries to add herself to group "groupA" using the Graph API Then the HTTP status code should be "403" And the JSON data of the response should match """ diff --git a/tests/acceptance/features/apiGraph/changeOwnPassword.feature b/tests/acceptance/features/apiGraph/changeOwnPassword.feature index f1d42fbe7..5266c63e5 100644 --- a/tests/acceptance/features/apiGraph/changeOwnPassword.feature +++ b/tests/acceptance/features/apiGraph/changeOwnPassword.feature @@ -1,6 +1,8 @@ @api Feature: an user changes its own password - + As a user + I want to change my password + So that I can use new combination as password Scenario Outline: change own password Given user "Alice" has been created with default attributes and without skeleton files diff --git a/tests/acceptance/features/apiGraph/createGroup.feature b/tests/acceptance/features/apiGraph/createGroup.feature index a061a813e..98b89d1e1 100644 --- a/tests/acceptance/features/apiGraph/createGroup.feature +++ b/tests/acceptance/features/apiGraph/createGroup.feature @@ -1,6 +1,8 @@ @api @skipOnOcV10 Feature: create group - Only user with admin permissions can create new groups + As an admin + I want to create a group + So that I can add users to the group Background: Given user "Alice" has been created with default attributes and without skeleton files diff --git a/tests/acceptance/features/apiGraph/createGroupCaseSensitive.feature b/tests/acceptance/features/apiGraph/createGroupCaseSensitive.feature index a70ee76c2..fa4c6bdd1 100644 --- a/tests/acceptance/features/apiGraph/createGroupCaseSensitive.feature +++ b/tests/acceptance/features/apiGraph/createGroupCaseSensitive.feature @@ -1,5 +1,8 @@ @api Feature: create groups, group names are case insensitive + As an admin + I want to create group with similar cases + SO that I can check if the group name are case sensitive @issue-3516 Scenario Outline: group names are case insensitive, creating groups with different upper and lower case names diff --git a/tests/acceptance/features/apiGraph/createUser.feature b/tests/acceptance/features/apiGraph/createUser.feature index 1f9f220cf..83a50424a 100644 --- a/tests/acceptance/features/apiGraph/createUser.feature +++ b/tests/acceptance/features/apiGraph/createUser.feature @@ -1,6 +1,8 @@ @api @skipOnOcV10 Feature: create user - Only user with admin permissions can create new user + As a admin + I want to create a user + So that the user can use the application Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839 @@ -9,7 +11,7 @@ Feature: create user Given user "Alice" has been created with default attributes and without skeleton files @issue-3516 - Scenario Outline: the admin creates a user + Scenario Outline: admin creates a user Given the administrator has given "Alice" the role "Admin" using the settings api When the user "Alice" creates a new user using GraphAPI with the following settings: | userName | | @@ -35,7 +37,7 @@ Feature: create user | Alice | same userName | new@example.org | 123 | 400 | true | should | - Scenario: a user cannot be created with empty name + Scenario: user cannot be created with empty name Given the administrator has given "Alice" the role "Admin" using the settings api When the user "Alice" creates a new user using GraphAPI with the following settings: | userName | | @@ -46,7 +48,7 @@ Feature: create user Then the HTTP status code should be "400" - Scenario Outline: a user without admin right cannot create a user + Scenario Outline: user without admin right cannot create a user Given the administrator has given "Alice" the role "" using the settings api When the user "Alice" creates a new user using GraphAPI with the following settings: | userName | user | @@ -63,7 +65,7 @@ Feature: create user | Guest | @issue-3516 @skipOnStable2.0 - Scenario: a user cannot be created with the name of the disabled user + Scenario: user cannot be created with the name of the disabled user Given user "Brian" has been created with default attributes and without skeleton files And the administrator has given "Alice" the role "Admin" using the settings api And the user "Alice" has disabled user "Brian" using the Graph API @@ -76,7 +78,7 @@ Feature: create user Then the HTTP status code should be "400" @skipOnStable2.0 - Scenario: a user can be created with the name of the deleted user + Scenario: user can be created with the name of the deleted user Given user "Brian" has been created with default attributes and without skeleton files And the administrator has given "Alice" the role "Admin" using the settings api And the user "Alice" has deleted a user "Brian" using the Graph API diff --git a/tests/acceptance/features/apiGraph/deleteUser.feature b/tests/acceptance/features/apiGraph/deleteUser.feature index 653d9d3ed..31789e09c 100644 --- a/tests/acceptance/features/apiGraph/deleteUser.feature +++ b/tests/acceptance/features/apiGraph/deleteUser.feature @@ -1,6 +1,8 @@ @api @skipOnOcV10 Feature: delete user - Only user with admin permission can delete user + As an admin + I want to be able to delete users + So that I can remove unnecessary users Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839 @@ -9,7 +11,7 @@ Feature: delete user Given user "Alice" has been created with default attributes and without skeleton files - Scenario Outline: the admin user deletes a user + Scenario Outline: admin user deletes a user Given the administrator has given "Alice" the role "Admin" using the settings api And the user "Alice" has created a new user using the Graph API with the following settings: | userName | | @@ -26,7 +28,7 @@ Feature: delete user | name | pass with space | example@example.org | my pass | - Scenario: Delete a user and specify the user name in different case + Scenario: delete a user and specify the user name in different case Given user "brand-new-user" has been created with default attributes and without skeleton files And the administrator has given "Alice" the role "Admin" using the settings api When the user "Alice" deletes a user "Brand-New-User" using the Graph API @@ -34,7 +36,7 @@ Feature: delete user And user "brand-new-user" should not exist - Scenario Outline: the admin user deletes another user with different role + Scenario Outline: admin user deletes another user with different role Given user "Brian" has been created with default attributes and without skeleton files And the administrator has given "Alice" the role "Admin" using the settings api And the administrator has given "Brian" the role "" using the settings api @@ -49,14 +51,14 @@ Feature: delete user | Guest | - Scenario: the admin user tries to delete his/her own account + Scenario: admin user tries to delete his/her own account Given the administrator has given "Alice" the role "Admin" using the settings api When the user "Alice" deletes a user "Alice" using the Graph API Then the HTTP status code should be "403" And user "Alice" should exist - Scenario Outline: Non-admin user tries to delete his/her own account + Scenario Outline: non-admin user tries to delete his/her own account Given the administrator has given "Alice" the role "" using the settings api When the user "Alice" deletes a user "Alice" using the Graph API Then the HTTP status code should be "401" @@ -68,13 +70,13 @@ Feature: delete user | Guest | - Scenario: the admin user tries to delete a nonexistent user + Scenario: admin user tries to delete a nonexistent user Given the administrator has given "Alice" the role "Admin" using the settings api When the user "Alice" tries to delete a nonexistent user using the Graph API Then the HTTP status code should be "404" - Scenario Outline: Non-admin user tries to delete a nonexistent user + Scenario Outline: non-admin user tries to delete a nonexistent user Given the administrator has given "Alice" the role "" using the settings api When the user "Alice" tries to delete a nonexistent user using the Graph API Then the HTTP status code should be "401" @@ -85,7 +87,7 @@ Feature: delete user | Guest | - Scenario Outline: Non-admin user tries to delete another user with different role + Scenario Outline: non-admin user tries to delete another user with different role Given user "Brian" has been created with default attributes and without skeleton files And the administrator has given "Brian" the role "" using the settings api And the administrator has given "Alice" the role "" using the settings api @@ -108,7 +110,7 @@ Feature: delete user | Guest | Admin | - Scenario: the admin user deletes a disabled user + Scenario: admin user deletes a disabled user Given the administrator has given "Alice" the role "Admin" using the settings api And user "Brian" has been created with default attributes and without skeleton files And the user "Alice" has disabled user "Brian" using the Graph API diff --git a/tests/acceptance/features/apiGraph/editUser.feature b/tests/acceptance/features/apiGraph/editUser.feature index 2d54e6cb3..cce245866 100644 --- a/tests/acceptance/features/apiGraph/editUser.feature +++ b/tests/acceptance/features/apiGraph/editUser.feature @@ -1,5 +1,8 @@ @api @skipOnOcV10 Feature: edit user + As an admin + I want to be able to edit user information + So that I can manage user Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839 @@ -14,7 +17,7 @@ Feature: edit user | password | 1234 | - Scenario Outline: the admin user can edit another user's email + Scenario Outline: admin user can edit another user's email When the user "Alice" changes the email of user "Brian" to "" using the Graph API Then the HTTP status code should be "" And the user information of "Brian" should match this JSON schema @@ -41,7 +44,7 @@ Feature: edit user | change to a invalid email | invalidEmail | 400 | brian@example.com | @skipOnStable2.0 @issue-5763 - Scenario Outline: the admin user can edit another user's name + Scenario Outline: admin user can edit another user's name Given user "Carol" has been created with default attributes and without skeleton files When the user "Alice" changes the user name of user "Carol" to "" using the Graph API Then the HTTP status code should be "" @@ -68,7 +71,7 @@ Feature: edit user | empty user name | | 200 | Brian | @skipOnStable2.0 - Scenario: the admin user changes the name of a user to the name of an existing disabled user + Scenario: admin user changes the name of a user to the name of an existing disabled user Given the user "Alice" has created a new user using the Graph API with the following settings: | userName | sam | | displayName | sam | @@ -94,7 +97,7 @@ Feature: edit user """ @skipOnStable2.0 - Scenario: the admin user changes the name of a user to the name of a previously deleted user + Scenario: admin user changes the name of a user to the name of a previously deleted user Given the user "Alice" has created a new user using the Graph API with the following settings: | userName | sam | | displayName | sam | @@ -120,7 +123,7 @@ Feature: edit user """ - Scenario Outline: a normal user should not be able to change their email address + Scenario Outline: normal user should not be able to change their email address Given the administrator has given "Brian" the role "" using the settings api When the user "Brian" tries to change the email of user "Brian" to "newemail@example.com" using the Graph API Then the HTTP status code should be "401" @@ -146,7 +149,7 @@ Feature: edit user | Guest | - Scenario Outline: a normal user should not be able to edit another user's email + Scenario Outline: normal user should not be able to edit another user's email Given the administrator has given "Brian" the role "" using the settings api And the user "Alice" has created a new user using the Graph API with the following settings: | userName | Carol | @@ -187,7 +190,7 @@ Feature: edit user | Guest | Admin | - Scenario Outline: the admin user can edit another user display name + Scenario Outline: admin user can edit another user display name When the user "Alice" changes the display name of user "Brian" to "" using the Graph API Then the HTTP status code should be "200" And the user information of "Brian" should match this JSON schema @@ -213,7 +216,7 @@ Feature: edit user | displayName with characters | *:!;_+-&#(?) | 200 | *:!;_+-&#(?) | - Scenario Outline: a normal user should not be able to change his/her own display name + Scenario Outline: normal user should not be able to change his/her own display name Given the administrator has given "Brian" the role "" using the settings api When the user "Brian" tries to change the display name of user "Brian" to "Brian Murphy" using the Graph API Then the HTTP status code should be "401" @@ -239,7 +242,7 @@ Feature: edit user | Guest | - Scenario Outline: a normal user should not be able to edit another user's display name + Scenario Outline: normal user should not be able to edit another user's display name Given the administrator has given "Brian" the role "" using the settings api And the user "Alice" has created a new user using the Graph API with the following settings: | userName | Carol | @@ -280,14 +283,14 @@ Feature: edit user | Guest | Admin | - Scenario: the admin user resets password of another user + Scenario: admin user resets password of another user Given user "Brian" has uploaded file with content "test file for reset password" to "/resetpassword.txt" When the user "Alice" resets the password of user "Brian" to "newpassword" using the Graph API Then the HTTP status code should be "200" And the content of file "resetpassword.txt" for user "Brian" using password "newpassword" should be "test file for reset password" - Scenario Outline: a normal user should not be able to reset the password of another user + Scenario Outline: normal user should not be able to reset the password of another user Given the administrator has given "Brian" the role "" using the settings api And the user "Alice" has created a new user using the Graph API with the following settings: | userName | Carol | @@ -316,7 +319,7 @@ Feature: edit user | Guest | Admin | @skipOnStable2.0 - Scenario: the admin user disables another user + Scenario: admin user disables another user When the user "Alice" disables user "Brian" using the Graph API Then the HTTP status code should be "200" When user "Alice" gets information of user "Brian" using Graph API @@ -358,7 +361,7 @@ Feature: edit user """ @skipOnStable2.0 - Scenario Outline: a normal user should not be able to disable another user + Scenario Outline: normal user should not be able to disable another user Given user "Carol" has been created with default attributes and without skeleton files And the administrator has given "Brian" the role "" using the settings api When the user "Brian" tries to disable user "Carol" using the Graph API @@ -407,7 +410,7 @@ Feature: edit user | Guest | @skipOnStable2.0 - Scenario: the admin user enables disabled user + Scenario: admin user enables disabled user Given the user "Alice" has disabled user "Brian" using the Graph API When the user "Alice" enables user "Brian" using the Graph API Then the HTTP status code should be "200" @@ -450,7 +453,7 @@ Feature: edit user """ @skipOnStable2.0 - Scenario Outline: a normal user should not be able to enable another user + Scenario Outline: normal user should not be able to enable another user Given user "Carol" has been created with default attributes and without skeleton files And the user "Alice" has disabled user "Carol" using the Graph API And the administrator has given "Brian" the role "" using the settings api diff --git a/tests/acceptance/features/apiGraph/getApplications.feature b/tests/acceptance/features/apiGraph/getApplications.feature index 3133619f8..e3472068b 100644 --- a/tests/acceptance/features/apiGraph/getApplications.feature +++ b/tests/acceptance/features/apiGraph/getApplications.feature @@ -2,6 +2,7 @@ Feature: get applications As an user I want to be able to get applications information with existings roles + So that I can see which role blongs to what user Background: Given user "Alice" has been created with default attributes and without skeleton files diff --git a/tests/acceptance/features/apiGraph/getGroup.feature b/tests/acceptance/features/apiGraph/getGroup.feature index a6f4b3d00..e03c7a01f 100644 --- a/tests/acceptance/features/apiGraph/getGroup.feature +++ b/tests/acceptance/features/apiGraph/getGroup.feature @@ -384,7 +384,7 @@ Feature: get groups and their members | Guest | - Scenario: Get details of a group + Scenario: get details of a group Given group "tea-lover" has been created When user "Alice" gets details of the group "tea-lover" using the Graph API Then the HTTP status code should be "200" @@ -410,7 +410,7 @@ Feature: get groups and their members """ - Scenario Outline: Get details of group with UTF-8 characters name + Scenario Outline: get details of group with UTF-8 characters name Given group "" has been created When user "Alice" gets details of the group "" using the Graph API Then the HTTP status code should be "200" diff --git a/tests/acceptance/features/apiGraph/getUser.feature b/tests/acceptance/features/apiGraph/getUser.feature index aba8bb658..0aa129413 100644 --- a/tests/acceptance/features/apiGraph/getUser.feature +++ b/tests/acceptance/features/apiGraph/getUser.feature @@ -752,7 +752,7 @@ Feature: get users @skipOnStable2.0 - Scenario: admin user gets all users of certain groups + Scenario: admin user gets all users of two groups Given the administrator has given "Alice" the role "Admin" using the settings api And user "Carol" has been created with default attributes and without skeleton files And group "tea-lover" has been created @@ -761,7 +761,7 @@ Feature: get users And user "Alice" has been added to group "tea-lover" And user "Brian" has been added to group "coffee-lover" And user "Carol" has been added to group "wine-lover" - When the user "Alice" gets all users from that are members in the group "tea-lover" or the group "coffee-lover" using the Graph API + When the user "Alice" gets all users that are members in the group "tea-lover" or the group "coffee-lover" using the Graph API Then the HTTP status code should be "200" And the JSON data of the response should contain the user "Alice Hansen" in the item 'value', the user-details should match """ diff --git a/tests/acceptance/features/apiSpaces/changeSpaces.feature b/tests/acceptance/features/apiSpaces/changeSpaces.feature index eb6c63ac5..3b87e3ca0 100644 --- a/tests/acceptance/features/apiSpaces/changeSpaces.feature +++ b/tests/acceptance/features/apiSpaces/changeSpaces.feature @@ -2,6 +2,7 @@ Feature: Change data of space As a user with space admin rights I want to be able to change the data of a created space (increase the quota, change name, etc.) + So that I can manage them Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839 @@ -23,7 +24,7 @@ Feature: Change data of space And using spaces DAV path - Scenario Outline: Only space admin user can change the name of a Space via the Graph API + Scenario Outline: only space admin user can change the name of a space via the Graph API When user "" changes the name of the "Project Jupiter" space to "" Then the HTTP status code should be "" And for user "" the JSON response should contain space called "" and match @@ -53,7 +54,7 @@ Feature: Change data of space | Bob | 403 | Project Jupiter | - Scenario: Only space admin user can change the description(subtitle) of a Space via the Graph API + Scenario: only space admin user can change the description(subtitle) of a space via the Graph API When user "Alice" changes the description of the "Project Jupiter" space to "The Death Star is a fictional mobile space station" Then the HTTP status code should be "200" And for user "Alice" the JSON response should contain space called "Project Jupiter" and match @@ -83,7 +84,7 @@ Feature: Change data of space """ - Scenario Outline: Viewer and editor cannot change the description(subtitle) of a Space via the Graph API + Scenario Outline: viewer and editor cannot change the description(subtitle) of a space via the Graph API When user "" changes the description of the "Project Jupiter" space to "The Death Star is a fictional mobile space station" Then the HTTP status code should be "" Examples: @@ -92,7 +93,7 @@ Feature: Change data of space | Bob | 403 | - Scenario Outline: An user tries to increase the quota of a Space via the Graph API + Scenario Outline: user tries to increase the quota of a Space via the Graph API When user "" changes the quota of the "Project Jupiter" space to "100" Then the HTTP status code should be "" And for user "" the JSON response should contain space called "Project Jupiter" and match @@ -131,7 +132,7 @@ Feature: Change data of space | Bob | 403 | 20 | - Scenario Outline: An space admin user set no restriction quota of a Space via the Graph API + Scenario Outline: space admin user set no restriction quota of a Space via the Graph API When user "Alice" changes the quota of the "Project Jupiter" space to "" Then the HTTP status code should be "200" When user "Alice" uploads a file inside space "Project Jupiter" with content "some content" to "file.txt" using the WebDAV API @@ -175,7 +176,7 @@ Feature: Change data of space | -1 | - Scenario: An user space admin set readme file as description of the space via the Graph API + Scenario: user space admin set readme file as description of the space via the Graph API Given user "Alice" has created a folder ".space" in space "Project Jupiter" And user "Alice" has uploaded a file inside space "Project Jupiter" with content "space description" to ".space/readme.md" When user "Alice" sets the file ".space/readme.md" as a description in a special section of the "Project Jupiter" space @@ -257,7 +258,7 @@ Feature: Change data of space And for user "Alice" the content of the file ".space/readme.md" of the space "Project Jupiter" should be "space description" - Scenario Outline: An user member of the space changes readme file + Scenario Outline: user member of the space changes readme file Given user "Alice" has created a folder ".space" in space "Project Jupiter" And user "Alice" has uploaded a file inside space "Project Jupiter" with content "space description" to ".space/readme.md" And user "Alice" has set the file ".space/readme.md" as a description in a special section of the "Project Jupiter" space @@ -344,7 +345,7 @@ Feature: Change data of space | Bob | 403 | 17 | space description | - Scenario Outline: An user space admin and editor set image file as space image of the space via the Graph API + Scenario Outline: user space admin and editor set image file as space image of the space via the Graph API Given user "Alice" has created a folder ".space" in space "Project Jupiter" And user "" has uploaded a file inside space "Project Jupiter" with content "" to ".space/" When user "" sets the file ".space/" as a space image in a special section of the "Project Jupiter" space @@ -429,14 +430,14 @@ Feature: Change data of space | Brian | spaceImage.png | spaceImage.png | image/png | | Alice | spaceImage.gif | spaceImage.gif | image/gif | - Scenario: An user viewer cannot set image file as space image of the space via the Graph API + Scenario: user viewer cannot set image file as space image of the space via the Graph API Given user "Alice" has created a folder ".space" in space "Project Jupiter" And user "Alice" has uploaded a file inside space "Project Jupiter" with content "" to ".space/someImageFile.jpg" When user "Bob" sets the file ".space/someImageFile.jpg" as a space image in a special section of the "Project Jupiter" space Then the HTTP status code should be "403" - Scenario Outline: An user set new readme file as description of the space via the Graph API + Scenario Outline: user set new readme file as description of the space via the graph API Given user "Alice" has created a folder ".space" in space "Project Jupiter" And user "Alice" has uploaded a file inside space "Project Jupiter" with content "space description" to ".space/readme.md" And user "Alice" has set the file ".space/readme.md" as a description in a special section of the "Project Jupiter" space @@ -522,7 +523,7 @@ Feature: Change data of space | Bob | 403 | 17 | space description | - Scenario Outline: An user set new image file as space image of the space via the Graph API + Scenario Outline: user set new image file as space image of the space via the Graph API Given user "Alice" has created a folder ".space" in space "Project Jupiter" And user "Alice" has uploaded a file inside space "Project Jupiter" with content "" to ".space/spaceImage.jpeg" And user "Alice" has set the file ".space/spaceImage.jpeg" as a space image in a special section of the "Project Jupiter" space @@ -607,7 +608,7 @@ Feature: Change data of space | Brian | - Scenario Outline: An admin user set own quota of a personal space via the Graph API + Scenario Outline: admin user set own quota of a personal space via the Graph API When user "Admin" changes the quota of the "Admin" space to "" Then the HTTP status code should be "200" When user "Admin" uploads a file inside space "Admin" with content "file is more than 15 bytes" to "file.txt" using the WebDAV API @@ -620,7 +621,7 @@ Feature: Change data of space | -1 | between "201" and "204" | - Scenario Outline: An admin user set an user personal space quota of via the Graph API + Scenario Outline: admin user set an user personal space quota of via the Graph API When user "Admin" changes the quota of the "Brian Murphy" space to "" Then the HTTP status code should be "200" When user "Brian" uploads a file inside space "Brian Murphy" with content "file is more than 15 bytes" to "file.txt" using the WebDAV API @@ -666,7 +667,7 @@ Feature: Change data of space | -1 | between "201" and "204" | 0 | 26 | - Scenario: user sends invalid space uuid via the Graph API + Scenario: user sends invalid space uuid via the graph API When user "Admin" tries to change the name of the "non-existing" space to "new name" Then the HTTP status code should be "404" When user "Admin" tries to change the quota of the "non-existing" space to "10" diff --git a/tests/acceptance/features/apiSpaces/createSpace.feature b/tests/acceptance/features/apiSpaces/createSpace.feature index 20a06dff5..2500e7c51 100644 --- a/tests/acceptance/features/apiSpaces/createSpace.feature +++ b/tests/acceptance/features/apiSpaces/createSpace.feature @@ -8,7 +8,7 @@ Feature: create space Given user "Alice" has been created with default attributes and without skeleton files @issue-5938 - Scenario Outline: user with role user and guest can't create Space via Graph API + Scenario Outline: user with role user and guest can't create space via Graph API Given the administrator has given "Alice" the role "" using the settings api When user "Alice" tries to create a space "Project Mars" of type "project" with the default quota using the Graph API Then the HTTP status code should be "403" @@ -19,7 +19,7 @@ Feature: create space | Guest | - Scenario Outline: an admin or space admin user can create a Space via the Graph API with a default quota + Scenario Outline: admin or space admin user can create a space via the Graph API with a default quota Given the administrator has given "Alice" the role "" using the settings api When user "Alice" creates a space "Project Mars" of type "project" with the default quota using the Graph API Then the HTTP status code should be "201" @@ -90,7 +90,7 @@ Feature: create space | Space Admin | - Scenario Outline: an admin or space admin user can create a Space via the Graph API with certain quota + Scenario Outline: admin or space admin user can create a space via the Graph API with certain quota Given the administrator has given "Alice" the role "" using the settings api When user "Alice" creates a space "Project Venus" of type "project" with quota "2000" using the Graph API Then the HTTP status code should be "201" diff --git a/tests/acceptance/features/apiSpaces/disableAndDeleteSpaces.feature b/tests/acceptance/features/apiSpaces/disableAndDeleteSpaces.feature index 63108b8ad..5c3ccb784 100644 --- a/tests/acceptance/features/apiSpaces/disableAndDeleteSpaces.feature +++ b/tests/acceptance/features/apiSpaces/disableAndDeleteSpaces.feature @@ -223,7 +223,7 @@ Feature: Disabling and deleting space | Space Admin | - Scenario Outline: user with role user and guest cannot delete others disabled Space via the Graph API + Scenario Outline: user with role user and guest cannot delete others disabled space via the Graph API Given the administrator has given "Carol" the role "" using the settings api And user "Alice" has disabled a space "Project Moon" When user "Carol" tries to delete a space "Project Moon" owned by user "Alice" diff --git a/tests/acceptance/features/apiSpaces/download.feature b/tests/acceptance/features/apiSpaces/download.feature index 05bc54d2d..76163acb2 100644 --- a/tests/acceptance/features/apiSpaces/download.feature +++ b/tests/acceptance/features/apiSpaces/download.feature @@ -1,6 +1,8 @@ @api @skipOnOcV10 Feature: Download file in project space - As a user with different role, I want to be able to download files + As a user with different role + I want to be able to download files + So that I can have it in my local storage Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839 @@ -23,7 +25,7 @@ Feature: Download file in project space | role | viewer | - Scenario Outline: A user downloads a file in the project space + Scenario Outline: user downloads a file in the project space When user "" downloads the file "file.txt" of the space "download file" using the WebDAV API Then the HTTP status code should be "200" And the following headers should be set @@ -55,7 +57,7 @@ Feature: Download file in project space | Brian | - Scenario: A user viewer cannot get the old version of the file in the project space + Scenario: user with role viewer cannot get the old version of the file in the project space Given user "Alice" has uploaded a file inside space "download file" with content "new content" to "file.txt" When user "Bob" tries to get version of the file "file.txt" with the index "1" of the space "download file" using the WebDAV API Then the HTTP status code should be "403" diff --git a/tests/acceptance/features/apiSpaces/editPublicLinkOfSpace.feature b/tests/acceptance/features/apiSpaces/editPublicLinkOfSpace.feature index 9f3e825b7..6658b3537 100644 --- a/tests/acceptance/features/apiSpaces/editPublicLinkOfSpace.feature +++ b/tests/acceptance/features/apiSpaces/editPublicLinkOfSpace.feature @@ -25,7 +25,7 @@ Feature: A manager of the space can edit public link And user "Alice" has uploaded a file inside space "edit space" with content "some content" to "test.txt" - Scenario Outline: A manager of the space can edit public link. + Scenario Outline: manager of the space can edit public link. Given using OCS API version "2" When user "Alice" updates the last public link share using the sharing API with | permissions | | @@ -51,7 +51,7 @@ Feature: A manager of the space can edit public link | 15 | read,update,create,delete | | newName | - Scenario Outline: All members can see a created public link + Scenario Outline: members can see a created public link Given using OCS API version "2" When user "Alice" shares a space "edit space" with settings: | shareWith | Brian | @@ -67,7 +67,7 @@ Feature: A manager of the space can edit public link | viewer | - Scenario Outline: Members of the space try to edit a public link + Scenario Outline: members of the space try to edit a public link Given using OCS API version "2" And user "Alice" has shared a space "edit space" with settings: | shareWith | Brian | diff --git a/tests/acceptance/features/apiSpaces/filePreviews.feature b/tests/acceptance/features/apiSpaces/filePreviews.feature index 6d861d3e8..d46dfe938 100644 --- a/tests/acceptance/features/apiSpaces/filePreviews.feature +++ b/tests/acceptance/features/apiSpaces/filePreviews.feature @@ -1,6 +1,8 @@ @api @skipOnOcV10 Feature: Preview file in project space - As a user, I want to be able to download different files for the preview + As a user + I want to be able to download different files for the preview + So that I can preview the thumbnail of the file Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839 @@ -14,7 +16,7 @@ Feature: Preview file in project space And using spaces DAV path - Scenario Outline: An user can preview created txt files in the project space + Scenario Outline: user can preview created txt files in the project space Given user "Alice" has uploaded a file inside space "previews of the files" with content "test" to "" When user "Alice" downloads the preview of "" of the space "previews of the files" with width "" and height "" using the WebDAV API Then the HTTP status code should be "200" @@ -24,7 +26,7 @@ Feature: Preview file in project space | /name with spaces.txt | 1200 | 1200 | - Scenario Outline: An user can preview image files in the project space + Scenario Outline: user can preview image files in the project space Given using spaces DAV path And user "Alice" has uploaded a file from "" to "" via TUS inside of the space "previews of the files" using the WebDAV API When user "Alice" downloads the preview of "" of the space "previews of the files" with width "" and height "" using the WebDAV API diff --git a/tests/acceptance/features/apiSpaces/listSpaces.feature b/tests/acceptance/features/apiSpaces/listSpaces.feature index ecf6c528b..c823faeb3 100644 --- a/tests/acceptance/features/apiSpaces/listSpaces.feature +++ b/tests/acceptance/features/apiSpaces/listSpaces.feature @@ -1,7 +1,8 @@ @api @skipOnOcV10 Feature: List and create spaces As a user - I want to be able to work with personal and project spaces + I want to be able to list project spaces + So that I can retrive the information about them Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839 @@ -11,7 +12,7 @@ Feature: List and create spaces And using spaces DAV path - Scenario: An ordinary user can request information about their Space via the Graph API + Scenario: ordinary user can request information about their Space via the Graph API When user "Alice" lists all available spaces via the GraphApi Then the HTTP status code should be "200" And the JSON response should contain space called "Alice Hansen" and match @@ -77,7 +78,7 @@ Feature: List and create spaces """ - Scenario: An ordinary user can request information about their Space via the Graph API using a filter + Scenario: ordinary user can request information about their Space via the Graph API using a filter Given user "Brian" has been created with default attributes and without skeleton files And user "Brian" has created folder "folder" And user "Brian" has shared folder "folder" with user "Alice" with permissions "31" @@ -173,7 +174,7 @@ Feature: List and create spaces And the json responded should only contain spaces of type "personal" - Scenario: An ordinary user will not see any space when using a filter for project + Scenario: ordinary user will not see any space when using a filter for project Given the administrator has given "Alice" the role "Space Admin" using the settings api And user "Alice" has created a space "my project" of type "project" with quota "20" When user "Alice" lists all available spaces via the GraphApi with query "$filter=driveType eq 'project'" @@ -206,13 +207,13 @@ Feature: List and create spaces And the json responded should not contain a space with name "Alice Hansen" - Scenario: An ordinary user can access their Space via the webDav API + Scenario: ordinary user can access their space via the webDav API When user "Alice" lists all available spaces via the GraphApi And user "Alice" lists the content of the space with the name "Alice Hansen" using the WebDav Api Then the HTTP status code should be "207" - Scenario: A user can list his personal space via multiple endpoints + Scenario: user can list his personal space via multiple endpoints When user "Alice" lists all available spaces via the GraphApi with query "$filter=driveType eq 'personal'" Then the HTTP status code should be "200" And the JSON response should contain space called "Alice Hansen" owned by "Alice" and match @@ -312,7 +313,7 @@ Feature: List and create spaces """ - Scenario Outline: A user can list his created spaces via multiple endpoints + Scenario Outline: user can list his created spaces via multiple endpoints Given the administrator has given "Alice" the role "" using the settings api When user "Alice" creates a space "Project Venus" of type "project" with quota "2000" using the Graph API Then the HTTP status code should be "201" @@ -442,7 +443,7 @@ Feature: List and create spaces | Space Admin | - Scenario Outline: A user cannot list space by id if he is not member of the space + Scenario Outline: user cannot list space by id if he is not member of the space Given the administrator has given "Alice" the role "" using the settings api And user "Admin" has created a space "Project Venus" with the default quota using the GraphApi When user "Alice" tries to look up the single space "Project Venus" owned by the user "Admin" by using its id diff --git a/tests/acceptance/features/apiSpaces/notification.feature b/tests/acceptance/features/apiSpaces/notification.feature index f88a72c3f..e3ec19992 100644 --- a/tests/acceptance/features/apiSpaces/notification.feature +++ b/tests/acceptance/features/apiSpaces/notification.feature @@ -2,6 +2,7 @@ Feature: Notification As a user I want to be notified of actions related to me + So that I can stay updated about the information Background: Given these users have been created with default attributes and without skeleton files: diff --git a/tests/acceptance/features/apiSpaces/quota.feature b/tests/acceptance/features/apiSpaces/quota.feature index bbb973aae..3e9f385c3 100644 --- a/tests/acceptance/features/apiSpaces/quota.feature +++ b/tests/acceptance/features/apiSpaces/quota.feature @@ -1,7 +1,10 @@ @api @skipOnOcV10 Feature: State of the quota As a user - I want to be able to see the state of the quota and and not let the quota overrun: + I want to be able to see the state of the quota + So that I will not let the quota overrun + + quota state indication: | 0 - 75% | normal | | 76 - 90% | nearing | @@ -17,7 +20,7 @@ Feature: State of the quota And using spaces DAV path - Scenario Outline: Quota information is returned in the list of spaces returned via the Graph API + Scenario Outline: quota information is returned in the list of spaces returned via the Graph API Given user "Alice" has created a space "" of type "project" with quota "" When user "Alice" uploads a file inside space "" with content "" to "test.txt" using the WebDAV API Then for user "Alice" the JSON response should contain space called "" and match @@ -74,13 +77,13 @@ Feature: State of the quota | Quota100% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1234567890 | exceeded | 100 | 0 | 100 | - Scenario: A file cannot be uploaded if there is insufficient quota + Scenario: file cannot be uploaded if there is insufficient quota Given user "Alice" has created a space "Project Alfa" of type "project" with quota "10" When user "Alice" uploads a file inside space "Project Alfa" with content "More than 10 bytes" to "test.txt" using the WebDAV API Then the HTTP status code should be "507" - Scenario: A folder can be created even if there is insufficient quota for file content + Scenario: folder can be created even if there is insufficient quota for file content Given user "Alice" has created a space "Project Beta" of type "project" with quota "7" And user "Alice" has uploaded a file inside space "Project Beta" with content "7 bytes" to "test.txt" When user "Alice" creates a folder "NewFolder" in space "Project Beta" using the WebDav Api @@ -89,21 +92,21 @@ Feature: State of the quota | NewFolder | - Scenario: A file can be overwritten if there is enough quota + Scenario: file can be overwritten if there is enough quota Given user "Alice" has created a space "Project Gamma" of type "project" with quota "10" And user "Alice" has uploaded a file inside space "Project Gamma" with content "7 bytes" to "test.txt" When user "Alice" uploads a file inside space "Project Gamma" with content "0010 bytes" to "test.txt" using the WebDAV API Then the HTTP status code should be "204" - Scenario: A file cannot be overwritten if there is insufficient quota + Scenario: file cannot be overwritten if there is insufficient quota When user "Alice" has created a space "Project Delta" of type "project" with quota "10" And user "Alice" has uploaded a file inside space "Project Delta" with content "7 bytes" to "test.txt" When user "Alice" uploads a file inside space "Project Delta" with content "00011 bytes" to "test.txt" using the WebDAV API Then the HTTP status code should be "507" - Scenario Outline: Check the relative amount of quota of personal space + Scenario Outline: check the relative amount of quota of personal space Given user "Admin" has changed the quota of the personal space of "Alice Hansen" space to "10000" And user "Alice" has uploaded file "" to "/demo.txt" When the user "Alice" requests these endpoints with "GET" with basic auth diff --git a/tests/acceptance/features/apiSpaces/removeSpaceObjects.feature b/tests/acceptance/features/apiSpaces/removeSpaceObjects.feature index a136cfba2..f5fbc4faf 100644 --- a/tests/acceptance/features/apiSpaces/removeSpaceObjects.feature +++ b/tests/acceptance/features/apiSpaces/removeSpaceObjects.feature @@ -2,8 +2,7 @@ Feature: Remove files, folder As a user I want to be able to remove files, folders - Users with the editor role can also remove objects - Users with the viewer role cannot remove objects + So that I can remove unnecessary objects Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839 @@ -20,7 +19,7 @@ Feature: Remove files, folder And user "Alice" has uploaded a file inside space "delete objects" with content "some content" to "text.txt" - Scenario Outline: An user deletes a folder with some subfolders in a Space via the webDav API + Scenario Outline: user deletes a folder with some subfolders in a space via the webDav API Given user "Alice" has shared a space "delete objects" with settings: | shareWith | Brian | | role | | @@ -37,7 +36,7 @@ Feature: Remove files, folder | Brian | viewer | 403 | should | should not | - Scenario Outline: An user deletes a subfolder in a Space via the webDav API + Scenario Outline: user deletes a subfolder in a space via the webDav API Given user "Alice" has shared a space "delete objects" with settings: | shareWith | Brian | | role | | @@ -56,7 +55,7 @@ Feature: Remove files, folder | Brian | viewer | 403 | should | should not | - Scenario Outline: An user deletes a file in a Space via the webDav API + Scenario Outline: user deletes a file in a space via the webDav API Given user "Alice" has shared a space "delete objects" with settings: | shareWith | Brian | | role | | @@ -101,7 +100,7 @@ Feature: Remove files, folder | Brian | viewer | 403 | should | should not | 12 | - Scenario: An user is unable to delete a Space via the webDav API + Scenario: user is unable to delete a space via the webDav API When user "Alice" removes the folder "" from space "delete objects" Then the HTTP status code should be "405" And for user "Alice" the JSON response should contain space called "delete objects" and match diff --git a/tests/acceptance/features/apiSpaces/resharing.feature b/tests/acceptance/features/apiSpaces/resharing.feature index 6a3eca755..9608481f4 100644 --- a/tests/acceptance/features/apiSpaces/resharing.feature +++ b/tests/acceptance/features/apiSpaces/resharing.feature @@ -1,6 +1,8 @@ @api @skipOnOcV10 Feature: Resharing - It is possible to reshare files + As a user + I want to reshare resources + So that other users can have access to it Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839 @@ -24,7 +26,7 @@ Feature: Resharing And user "Damian" has accepted share "/folder" offered by user "Carol" - Scenario Outline: You should only be able to see direct outgoing shares not all the chain: + Scenario Outline: user should only be able to see direct outgoing shares not all the chain Given user "Brian" has shared folder "Shares/folder" with user "Fred" with permissions "17" And user "Fred" has accepted share "/folder" offered by user "Brian" When user "" gets all the shares inside the folder "Shares/folder" using the sharing API @@ -43,7 +45,7 @@ Feature: Resharing | Fred | 0 | should not be | should not be | should not be | - Scenario: Owners can see all the chain: + Scenario: owners can see all the chain When user "Alice" gets all the shares inside the folder "folder" using the sharing API Then the OCS status code should be "100" And the HTTP status code should be "200" @@ -53,13 +55,13 @@ Feature: Resharing And user "Damian" should be included in the response - Scenario: You can't share with more permissions than you have + Scenario: user can't share with more permissions than they have When user "Damian" shares folder "Shares/folder" with user "Ember" with permissions "31" using the sharing API Then the OCS status code should be "404" And the OCS status message should be "Cannot set the requested share permissions" - Scenario Outline: Editing reshares + Scenario Outline: editing reshares Given user "Carol" has shared folder "Shares/folder" with user "Fred" with permissions "17" And user "Fred" has accepted share "/folder" offered by user "Carol" When user "" updates the last share using the sharing API with @@ -73,7 +75,7 @@ Feature: Resharing | Carol | 100 | should be | - Scenario Outline: Deleting reshares + Scenario Outline: deleting reshares Given user "Carol" has shared folder "Shares/folder" with user "Gina" with permissions "17" And user "Gina" has accepted share "/folder" offered by user "Carol" When user "" deletes the last share using the sharing API @@ -87,7 +89,7 @@ Feature: Resharing | Carol | 100 | should not exist | - Scenario Outline: Resharing with different permissions + Scenario Outline: resharing folder with different permissions When user "" shares folder "Shares/folder" with user "Ember" with permissions "" using the sharing API Then the OCS status code should be "" Examples: @@ -99,7 +101,7 @@ Feature: Resharing | Damian | 31 | 404 | - Scenario Outline: Resharing files with different permissions + Scenario Outline: Rrsharing files with different permissions Given user "Alice" has uploaded file with content "Random data" to "/file.txt" And user "Alice" has shared file "/file.txt" with user "Brian" with permissions "" And user "Brian" has accepted share "/file.txt" offered by user "Alice" @@ -112,7 +114,7 @@ Feature: Resharing | 19 | 19 | 100 | - Scenario Outline: Resharing with group with different permissions + Scenario Outline: resharing with group with different permissions Given group "security department" has been created And the administrator has added a user "Ember" to the group "security department" using GraphApi And the administrator has added a user "Fred" to the group "security department" using GraphApi diff --git a/tests/acceptance/features/apiSpaces/restoreSpaceObjects.feature b/tests/acceptance/features/apiSpaces/restoreSpaceObjects.feature index 356a689ea..2cecbf57b 100644 --- a/tests/acceptance/features/apiSpaces/restoreSpaceObjects.feature +++ b/tests/acceptance/features/apiSpaces/restoreSpaceObjects.feature @@ -2,7 +2,7 @@ Feature: Restore files, folder As a user with manager and editor role I want to be able to restore files, folders - Users with the viewer role cannot restore objects + So that I can get the resources that were accidentaly deleted Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839 @@ -21,7 +21,7 @@ Feature: Restore files, folder And user "Alice" has uploaded a file inside space "restore objects" with content "test" to "newFolder/file.txt" - Scenario Outline: The user with different role can see deleted objects in trash bin of the space via the webDav API + Scenario Outline: user with different role can see deleted objects in trash bin of the space via the webDav API Given user "Alice" has shared a space "restore objects" with settings: | shareWith | Brian | | role | | @@ -38,7 +38,7 @@ Feature: Restore files, folder | Brian | viewer | - Scenario Outline: The user can restore a folder with some objects from the trash via the webDav API + Scenario Outline: user can restore a folder with some objects from the trash via the webDav API Given user "Alice" has shared a space "restore objects" with settings: | shareWith | Brian | | role | | @@ -56,7 +56,7 @@ Feature: Restore files, folder | Brian | viewer | 403 | should not | should | - Scenario Outline: The user can restore a file from the trash via the webDav API + Scenario Outline: user can restore a file from the trash via the webDav API Given user "Alice" has shared a space "restore objects" with settings: | shareWith | Brian | | role | | @@ -74,7 +74,7 @@ Feature: Restore files, folder | Brian | viewer | 403 | should not | should | - Scenario: The user can restore a file even if there is not enough quota to do so + Scenario: user can restore a file even if there is not enough quota to do so Given user "Admin" has changed the quota of the "Brian Murphy" space to "30" And user "Brian" has uploaded file with content "file is less than 30 bytes" to "/file.txt" And user "Brian" has uploaded file with content "reduceContent" to "/file.txt" diff --git a/tests/acceptance/features/apiSpaces/restoreSpaces.feature b/tests/acceptance/features/apiSpaces/restoreSpaces.feature index 94b78f4ed..1dd7583ee 100644 --- a/tests/acceptance/features/apiSpaces/restoreSpaces.feature +++ b/tests/acceptance/features/apiSpaces/restoreSpaces.feature @@ -1,9 +1,8 @@ @api @skipOnOcV10 Feature: Restoring space As a manager of space - I want to be able to restore a disabled space. - Only manager can restore disabled space - The restored space must be visible to the other participants without loss of data + I want to be able to restore a disabled space + So that I can retrieve all the data belonging to the space Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839 @@ -19,13 +18,13 @@ Feature: Restoring space And using spaces DAV path - Scenario: An owner can restore a Space via the Graph API + Scenario: owner can restore a space via the Graph API Given user "Alice" has disabled a space "restore a space" When user "Alice" restores a disabled space "restore a space" Then the HTTP status code should be "200" - Scenario: Participants can see the data after the space is restored + Scenario: participants can see the data after the space is restored Given user "Alice" has created a folder "mainFolder" in space "restore a space" And user "Alice" has uploaded a file inside space "restore a space" with content "example" to "test.txt" And user "Alice" has shared a space "restore a space" with settings: diff --git a/tests/acceptance/features/apiSpaces/search.feature b/tests/acceptance/features/apiSpaces/search.feature index 2e6d4db7d..86505f557 100644 --- a/tests/acceptance/features/apiSpaces/search.feature +++ b/tests/acceptance/features/apiSpaces/search.feature @@ -1,6 +1,8 @@ @api @skipOnOcV10 Feature: Search - It is possible to search files in the Shares and the project space + As a user + I want to search for resources in the space + So that I can get them quickly Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839 @@ -18,7 +20,7 @@ Feature: Search And using new DAV path - Scenario: Alice can find data from the project space + Scenario: user can find data from the project space When user "Alice" searches for "fol" using the WebDAV API Then the HTTP status code should be "207" And the search result should contain "4" entries @@ -29,7 +31,7 @@ Feature: Search | /folderMain/SubFolder1/subFOLDER2/insideTheFolder.txt | - Scenario: Alice can find data from the project space + Scenario: user can only find data that they searched for from the project space When user "Alice" searches for "SUB" using the WebDAV API Then the HTTP status code should be "207" And the search result should contain "2" entries @@ -41,7 +43,7 @@ Feature: Search | /folderMain/SubFolder1/subFOLDER2/insideTheFolder.txt | - Scenario: Brian can find data from the Shares + Scenario: user can find data from the shares Given user "Alice" has created a share inside of space "find data" with settings: | path | folderMain | | shareWith | Brian | @@ -57,7 +59,7 @@ Feature: Search And for user "Brian" the search result should contain space "mountpoint/folderMain" - Scenario: User can find hidden file + Scenario: user can find hidden file Given user "Alice" has created a folder ".space" in space "find data" When user "Alice" searches for ".sp" using the WebDAV API Then the HTTP status code should be "207" @@ -66,7 +68,7 @@ Feature: Search | /.space | - Scenario: User cannot find pending folder + Scenario: user cannot find pending share Given user "Alice" has created a share inside of space "find data" with settings: | path | folderMain | | shareWith | Brian | @@ -80,7 +82,7 @@ Feature: Search | /SubFolder1/subFOLDER2/insideTheFolder.txt | - Scenario: User cannot find declined folder + Scenario: user cannot find declined share Given user "Alice" has created a share inside of space "find data" with settings: | path | folderMain | | shareWith | Brian | @@ -95,14 +97,14 @@ Feature: Search | /SubFolder1/subFOLDER2/insideTheFolder.txt | - Scenario: User cannot find deleted folder + Scenario: user cannot find deleted folder Given user "Alice" has removed the folder "folderMain" from space "find data" When user "Alice" searches for "folderMain" using the WebDAV API Then the HTTP status code should be "207" And the search result should contain "0" entries - Scenario: User can find project space by name + Scenario: user can find project space by name When user "Alice" searches for "find data" using the WebDAV API Then the HTTP status code should be "207" And the search result should contain "1" entries diff --git a/tests/acceptance/features/apiSpaces/spaceManagement.feature b/tests/acceptance/features/apiSpaces/spaceManagement.feature index b51ffd16d..cdd89a1ea 100644 --- a/tests/acceptance/features/apiSpaces/spaceManagement.feature +++ b/tests/acceptance/features/apiSpaces/spaceManagement.feature @@ -2,9 +2,10 @@ Feature: Space management As a user with space admin permission I want to be able to manage all existing project space - - I can get all project space where I am not member using "graph/v1.0/drives" endpoint - - I can edit space: change quota, name, description - - I can enable, disable, delete space + So that + - I can get all project space where I am not member using "graph/v1.0/drives" endpoint + - I can edit space: change quota, name, description + - I can enable, disable, delete space Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839 @@ -21,7 +22,7 @@ Feature: Space management And user "Alice" has created a space "Project" of type "project" with quota "10" - Scenario: The space admin user can see another project space even if he is not member of the space + Scenario: space admin user can see another project space even if he is not member of the space When user "Brian" lists all spaces via the GraphApi with query "$filter=driveType eq 'project'" Then the HTTP status code should be "200" And the JSON response should contain space called "Project" and match @@ -52,7 +53,7 @@ Feature: Space management And the json responded should not contain a space with name "Alice Hansen" - Scenario: The space admin user can see another personal spaces + Scenario: space admin user can see another personal spaces When user "Brian" lists all spaces via the GraphApi with query "$filter=driveType eq 'personal'" Then the HTTP status code should be "200" And the JSON response should contain space called "Alice Hansen" and match @@ -83,14 +84,14 @@ Feature: Space management And the json responded should not contain a space with name "Project" - Scenario: The user without space admin permissions cannot see another spaces + Scenario: user without space admin permission cannot see another spaces When user "Carol" tries to list all spaces via the GraphApi Then the HTTP status code should be "200" And the json responded should not contain a space with name "Project" And the json responded should not contain a space with name "Alice Hansen" @skipOnStable2.0 - Scenario: The space admin user changes the name of the project space + Scenario: space admin user changes the name of the project space When user "Brian" changes the name of the "Project" space to "New Name" owned by user "Alice" Then the HTTP status code should be "200" And for user "Alice" the JSON response should contain space called "New Name" and match @@ -110,7 +111,7 @@ Feature: Space management """ - Scenario: The user without space admin permissions tries to change the name of the project space + Scenario: user without space admin permission tries to change the name of the project space When user "Carol" tries to change the name of the "Project" space to "New Name" owned by user "Alice" Then the HTTP status code should be "403" And for user "Alice" the JSON response should contain space called "Project" and match @@ -130,7 +131,7 @@ Feature: Space management """ @skipOnStable2.0 - Scenario: The space admin user changes the description of the project space + Scenario: space admin user changes the description of the project space When user "Brian" changes the description of the "Project" space to "New description" owned by user "Alice" Then the HTTP status code should be "200" And for user "Alice" the JSON response should contain space called "Project" and match @@ -150,7 +151,7 @@ Feature: Space management """ - Scenario: The user without space admin permissions tries to change the description of the project space + Scenario: user without space admin permission tries to change the description of the project space Given user "Alice" has changed the description of the "Project" space to "old description" When user "Carol" tries to change the description of the "Project" space to "New description" owned by user "Alice" Then the HTTP status code should be "403" @@ -171,7 +172,7 @@ Feature: Space management """ @skipOnStable2.0 - Scenario: The space admin user disables the project space + Scenario: space admin user disables the project space When user "Brian" disables a space "Project" owned by user "Alice" Then the HTTP status code should be "204" And for user "Alice" the JSON response should contain space called "Project" and match @@ -212,12 +213,12 @@ Feature: Space management """ - Scenario: The user without space admin permissions tries to disable the project space + Scenario: user without space admin permission tries to disable the project space When user "Carol" tries to disable a space "Project" owned by user "Alice" Then the HTTP status code should be "403" - Scenario Outline: The space admin user tries to disable the personal space + Scenario Outline: space admin user tries to disable the personal space When user "" disables a space "Alice Hansen" owned by user "Alice" Then the HTTP status code should be "403" Examples: @@ -226,14 +227,14 @@ Feature: Space management | Carol | @skipOnStable2.0 - Scenario: The space admin user deletes the project space + Scenario: space admin user deletes the project space Given user "Alice" has disabled a space "Project" When user "Brian" deletes a space "Project" owned by user "Alice" Then the HTTP status code should be "204" And the user "Alice" should not have a space called "Project" - Scenario: The user without space admin permissions tries to delete the project space + Scenario: user without space admin permission tries to delete the project space Given user "Alice" has disabled a space "Project" When user "Carol" tries to delete a space "Project" owned by user "Alice" Then the HTTP status code should be "403" @@ -275,13 +276,13 @@ Feature: Space management """ @skipOnStable2.0 - Scenario: The space admin user enables the project space + Scenario: space admin user enables the project space Given user "Alice" has disabled a space "Project" When user "Brian" restores a disabled space "Project" owned by user "Alice" Then the HTTP status code should be "200" - Scenario: The user without space admin permissions tries to enable the project space + Scenario: user without space admin permission tries to enable the project space Given user "Alice" has disabled a space "Project" When user "Carol" tries to restore a disabled space "Project" owned by user "Alice" Then the HTTP status code should be "404" diff --git a/tests/acceptance/features/apiSpaces/tag.feature b/tests/acceptance/features/apiSpaces/tag.feature index 5cb8e2092..5f931e91d 100644 --- a/tests/acceptance/features/apiSpaces/tag.feature +++ b/tests/acceptance/features/apiSpaces/tag.feature @@ -1,6 +1,8 @@ @api @skipOnOcV10 @skipOnStable2.0 Feature: Tag - The user can add a tag to resources for sorting and quick search + As a user + I wan to tag resources + So that I can sort and search them quickly Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839 @@ -17,7 +19,7 @@ Feature: Tag And user "Alice" has uploaded a file inside space "use-tag" with content "some content" to "folderMain/insideTheFolder.txt" - Scenario: Alice creates tags for resources in the project space + Scenario: user creates tags for resources in the project space Given user "Alice" has shared a space "use-tag" with settings: | shareWith | Brian | | role | viewer | @@ -52,7 +54,7 @@ Feature: Tag | fileTag | - Scenario: Alice creates tags for resources in the personal space + Scenario: user creates tags for resources in the personal space Given user "Alice" has created a folder "folderMain" in space "Alice Hansen" And user "Alice" has uploaded a file inside space "Alice Hansen" with content "some content" to "file.txt" When user "Alice" creates the following tags for folder "folderMain" of space "Alice Hansen": @@ -82,7 +84,7 @@ Feature: Tag | tag with symbol @^$#^%$@%!_+) | - Scenario Outline: Member of the space tries to create tag + Scenario Outline: member of the space tries to create tag Given user "Alice" has shared a space "use-tag" with settings: | shareWith | Brian | | role | | @@ -102,7 +104,7 @@ Feature: Tag | manager | 200 | should | - Scenario: The recipient has a created tags if share is accepted + Scenario: recipient has a created tags if share is accepted Given user "Alice" has created the following tags for folder "folderMain" of the space "use-tag": | folderTag | | marketing | @@ -123,7 +125,7 @@ Feature: Tag | marketing | - Scenario Outline: The recipient of the shared resource tries to create a tag + Scenario Outline: recipient of the shared resource tries to create a tag Given user "Alice" has created a share inside of space "use-tag" with settings: | path | folderMain | | shareWith | Brian | @@ -148,7 +150,7 @@ Feature: Tag | manager | folder | folderMain | 200 | should | - Scenario Outline: The recipient of the shared resource tries to remove a tag + Scenario Outline: recipient of the shared resource tries to remove a tag Given user "Alice" has created a share inside of space "use-tag" with settings: | path | folderMain | | shareWith | Brian | @@ -176,7 +178,7 @@ Feature: Tag | manager | folder | folderMain | 200 | should not | - Scenario: User removes folder tags + Scenario: user removes folder tags Given user "Alice" has created the following tags for folder "folderMain" of the space "use-tag": | folderTag | | marketing | @@ -191,7 +193,7 @@ Feature: Tag | oc:tags | development | - Scenario: User lists tags after deleting some folder tags + Scenario: user lists tags after deleting some folder tags Given user "Alice" has created the following tags for folder "folderMain" of the space "use-tag": | folderTag | | marketing | @@ -209,7 +211,7 @@ Feature: Tag | marketing | - Scenario: User lists the tags after deleting a folder + Scenario: user lists the tags after deleting a folder Given user "Alice" has created the following tags for folder "folderMain" of the space "use-tag": | folderTag | | marketing | @@ -222,7 +224,7 @@ Feature: Tag | marketing | - Scenario: User lists the tags after deleting a space + Scenario: user lists the tags after deleting a space Given user "Alice" has created the following tags for folder "folderMain" of the space "use-tag": | folderTag | | marketing | @@ -241,7 +243,7 @@ Feature: Tag | marketing | - Scenario: User lists the tags after restoring a deleted folder + Scenario: user lists the tags after restoring a deleted folder Given user "Alice" has created the following tags for folder "folderMain" of the space "use-tag": | folderTag | | marketing | diff --git a/tests/acceptance/features/apiSpaces/uploadSpaces.feature b/tests/acceptance/features/apiSpaces/uploadSpaces.feature index aec32d16a..1f7d58291 100644 --- a/tests/acceptance/features/apiSpaces/uploadSpaces.feature +++ b/tests/acceptance/features/apiSpaces/uploadSpaces.feature @@ -2,6 +2,7 @@ Feature: Upload files into a space As an user I want to be able to create folders and files in the space + So that I can store various information in them Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839 @@ -17,7 +18,7 @@ Feature: Upload files into a space And using spaces DAV path - Scenario Outline: An user creates a folder in the Space via the Graph API + Scenario Outline: user creates a folder in the space via the Graph API Given user "Alice" has shared a space "Project Ceres" with settings: | shareWith | Brian | | role | | @@ -32,7 +33,7 @@ Feature: Upload files into a space | viewer | 403 | should not | - Scenario Outline: An user uploads a file in shared Space via the Graph API + Scenario Outline: user uploads a file in shared space via the Graph API Given user "Alice" has shared a space "Project Ceres" with settings: | shareWith | Brian | | role | | @@ -75,7 +76,7 @@ Feature: Upload files into a space | viewer | 403 | should not | 0 | - Scenario: An user can create subfolders in a Space via the Graph API + Scenario: user can create subfolders in a space via the Graph API When user "Alice" creates a subfolder "mainFolder/subFolder1/subFolder2" in space "Project Ceres" using the WebDav Api Then the HTTP status code should be "201" And for user "Alice" the space "Project Ceres" should contain these entries: @@ -84,7 +85,7 @@ Feature: Upload files into a space | subFolder2 | - Scenario: An user can create a folder and upload a file to a Space + Scenario: user can create a folder and upload a file to a space When user "Alice" creates a folder "NewFolder" in space "Project Ceres" using the WebDav Api Then the HTTP status code should be "201" And user "Alice" uploads a file inside space "Project Ceres" with content "Test" to "test.txt" using the WebDAV API @@ -94,7 +95,7 @@ Feature: Upload files into a space | test.txt | - Scenario: An user cannot create a folder or a file in a Space if they do not have permission + Scenario: user cannot create a folder or a file in a space if they do not have permission When user "Bob" creates a folder "forAlice" in space "Project Ceres" owned by the user "Alice" using the WebDav Api Then the HTTP status code should be "404" When user "Bob" uploads a file inside space "Project Ceres" owned by the user "Alice" with content "Test" to "test.txt" using the WebDAV API diff --git a/tests/acceptance/features/apiSpacesShares/changingFilesShare.feature b/tests/acceptance/features/apiSpacesShares/changingFilesShare.feature index c369f9026..b1946f675 100644 --- a/tests/acceptance/features/apiSpacesShares/changingFilesShare.feature +++ b/tests/acceptance/features/apiSpacesShares/changingFilesShare.feature @@ -1,5 +1,8 @@ @api @skipOnOcV10 -Feature: +Feature: change shared resource + As a user + I want to change the shared resource + So that I can organize them as per my necessity Background: Given using spaces DAV path @@ -9,7 +12,7 @@ Feature: | Brian | @issue-4421 - Scenario: Move files between shares by different users + Scenario: move files between shares by different users Given user "Carol" has been created with default attributes and without skeleton files And user "Alice" has uploaded file with content "some data" to "/textfile0.txt" And user "Alice" has created folder "/PARENT" diff --git a/tests/acceptance/features/apiSpacesShares/checksum.feature b/tests/acceptance/features/apiSpacesShares/checksum.feature index 645662042..cb5f3a7ad 100644 --- a/tests/acceptance/features/apiSpacesShares/checksum.feature +++ b/tests/acceptance/features/apiSpacesShares/checksum.feature @@ -1,5 +1,8 @@ @api @skipOnOcV10 Feature: checksums + As a user + I want to upload files with checksum + So that I can make sure that the files are uploaded with correct checksums Background: Given user "Alice" has been created with default attributes and without skeleton files @@ -8,7 +11,7 @@ Feature: checksums And user "Brian" has been created with default attributes and without skeleton files @files_sharing-app-required @issue-1291 - Scenario: Sharing a file with checksum should return the checksum in the propfind using new DAV path + Scenario: sharing a file with checksum should return the checksum in the propfind using new DAV path Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a" And user "Alice" has shared file "/myChecksumFile.txt" with user "Brian" And user "Brian" has accepted share "/myChecksumFile.txt" offered by user "Alice" @@ -17,7 +20,7 @@ Feature: checksums And the webdav checksum should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960" @files_sharing-app-required @issue-1291 - Scenario: Modifying a shared file should return correct checksum in the propfind using new DAV path + Scenario: modifying a shared file should return correct checksum in the propfind using new DAV path Given user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/myChecksumFile.txt" with checksum "MD5:d70b40f177b14b470d1756a3c12b963a" And user "Alice" has shared file "/myChecksumFile.txt" with user "Brian" And user "Brian" has accepted share "/myChecksumFile.txt" offered by user "Alice" diff --git a/tests/acceptance/features/apiSpacesShares/copySpaces.feature b/tests/acceptance/features/apiSpacesShares/copySpaces.feature index a5ff6f127..4e2310431 100644 --- a/tests/acceptance/features/apiSpacesShares/copySpaces.feature +++ b/tests/acceptance/features/apiSpacesShares/copySpaces.feature @@ -12,7 +12,7 @@ Feature: copy file And using spaces DAV path - Scenario Outline: Copying a file within a same space project with role manager and editor + Scenario Outline: copying a file within a same project space with role manager and editor Given the administrator has given "Alice" the role "Space Admin" using the settings api And user "Alice" has created a space "Project" with the default quota using the GraphApi And user "Alice" has created a folder "/newfolder" in space "Project" @@ -31,7 +31,7 @@ Feature: copy file | editor | - Scenario: Copying a file within a same space project with role viewer + Scenario: copying a file within a same project space with role viewer Given the administrator has given "Alice" the role "Space Admin" using the settings api And user "Alice" has created a space "Project" with the default quota using the GraphApi And user "Alice" has created a folder "/newfolder" in space "Project" @@ -45,7 +45,7 @@ Feature: copy file | /newfolder/insideSpace.txt | - Scenario Outline: User copies a file from a space project with a different role to a space project with the manager role + Scenario Outline: user copies a file from a project space with a different role to a project space with the manager role Given the administrator has given "Brian" the role "Space Admin" using the settings api And user "Brian" has created a space "Project1" with the default quota using the GraphApi And user "Brian" has created a space "Project2" with the default quota using the GraphApi @@ -69,7 +69,7 @@ Feature: copy file | editor | editor | - Scenario Outline: User copies a file from a space project with a different role to a space project with a viewer role + Scenario Outline: user copies a file from a project space with a different role to a project space with a viewer role Given the administrator has given "Brian" the role "Space Admin" using the settings api And user "Brian" has created a space "Project1" with the default quota using the GraphApi And user "Brian" has created a space "Project2" with the default quota using the GraphApi @@ -90,7 +90,7 @@ Feature: copy file | editor | - Scenario Outline: User copies a file from space project with different role to space personal + Scenario Outline: user copies a file from project space with different role to personal space Given the administrator has given "Brian" the role "Space Admin" using the settings api And user "Brian" has created a space "Project" with the default quota using the GraphApi And user "Brian" has uploaded a file inside space "Project" with content "Project content" to "/project.txt" @@ -109,7 +109,7 @@ Feature: copy file | viewer | - Scenario Outline: User copies a file from space project with different role to space Shares with editor role + Scenario Outline: user copies a file from project space with different role to share space with editor role Given the administrator has given "Brian" the role "Space Admin" using the settings api And user "Brian" has created a space "Project" with the default quota using the GraphApi And user "Brian" has created folder "/testshare" @@ -131,7 +131,7 @@ Feature: copy file | viewer | - Scenario Outline: User copies a file from space project with different role to Shares with viewer role + Scenario Outline: user copies a file from project space with different role to Shares with viewer role Given the administrator has given "Brian" the role "Space Admin" using the settings api And user "Brian" has created a space "Project" with the default quota using the GraphApi And user "Brian" has created folder "/testshare" @@ -152,7 +152,7 @@ Feature: copy file | viewer | - Scenario Outline: User copies a file from space personal to space project with different role + Scenario Outline: user copies a file from personal space to project space with different role Given the administrator has given "Brian" the role "Space Admin" using the settings api And user "Brian" has created a space "Project" with the default quota using the GraphApi And user "Brian" has shared a space "Project" with settings: @@ -170,7 +170,7 @@ Feature: copy file | editor | - Scenario: User copies a file from space personal to space project with role viewer + Scenario: user copies a file from personal space to project space with role viewer Given the administrator has given "Brian" the role "Space Admin" using the settings api And user "Brian" has created a space "Project" with the default quota using the GraphApi And user "Brian" has shared a space "Project" with settings: @@ -183,7 +183,7 @@ Feature: copy file | /personal.txt | - Scenario: User copies a file from space personal to space Shares with role editor + Scenario: user copies a file from personal space to share space with role editor Given user "Brian" has created folder "/testshare" And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "31" And user "Alice" has accepted share "/testshare" offered by user "Brian" @@ -195,7 +195,7 @@ Feature: copy file And for user "Alice" the content of the file "/testshare/personal.txt" of the space "Shares" should be "personal content" - Scenario: User copies a file from space personal to space Shares with role viewer + Scenario: user copies a file from personal space to share space with role viewer Given user "Brian" has created folder "/testshare" And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "17" And user "Alice" has accepted share "/testshare" offered by user "Brian" @@ -206,7 +206,7 @@ Feature: copy file | /testshare/personal.txt | - Scenario Outline: User copies a file from space Shares with different role to space personal + Scenario Outline: user copies a file from share space with different role to personal space Given the administrator has given "Brian" the role "Space Admin" using the settings api And user "Brian" has created folder "/testshare" And user "Brian" has uploaded file with content "testshare content" to "/testshare/testshare.txt" @@ -223,7 +223,7 @@ Feature: copy file | 17 | - Scenario Outline: User copies a file from space Shares with different role to space project with different role + Scenario Outline: user copies a file from share space with different role to project space with different role Given the administrator has given "Brian" the role "Space Admin" using the settings api And user "Brian" has created a space "Project" with the default quota using the GraphApi And user "Brian" has shared a space "Project" with settings: @@ -246,7 +246,7 @@ Feature: copy file | editor | 17 | - Scenario Outline: User copies a file from space Shares with different role to space project with role viewer + Scenario Outline: user copies a file from share space with different role to project space with role viewer Given the administrator has given "Brian" the role "Space Admin" using the settings api And user "Brian" has created a space "Project" with the default quota using the GraphApi And user "Brian" has shared a space "Project" with settings: @@ -266,7 +266,7 @@ Feature: copy file | 17 | - Scenario Outline: User copies a file from space Shares with different role to space Shares with role editor + Scenario Outline: user copies a file from share space with different role to share space with role editor Given user "Brian" has created folder "/testshare1" And user "Brian" has created folder "/testshare2" And user "Brian" has uploaded file with content "testshare1 content" to "/testshare1/testshare1.txt" @@ -288,7 +288,7 @@ Feature: copy file | 17 | - Scenario Outline: User copies a file from space Shares with different role to space Shares with role editor + Scenario Outline: user copies a file from share space with different role to share space with role viewer Given user "Brian" has created folder "/testshare1" And user "Brian" has created folder "/testshare2" And user "Brian" has uploaded file with content "testshare1 content" to "/testshare1/testshare1.txt" @@ -308,7 +308,7 @@ Feature: copy file | 17 | - Scenario Outline: Copying a folder within the same space project with different role + Scenario Outline: copying a folder within the same project space with different role Given the administrator has given "Alice" the role "Space Admin" using the settings api And user "Alice" has created a space "Project" with the default quota using the GraphApi And user "Alice" has created a folder "/folder1" in space "Project" @@ -328,7 +328,7 @@ Feature: copy file | viewer | should not | 403 | - Scenario Outline: User copies a folder from a space project with different role to a space project with different role + Scenario Outline: user copies a folder from a project space with different role to a project space with different role Given the administrator has given "Brian" the role "Space Admin" using the settings api And user "Brian" has created a space "Project1" with the default quota using the GraphApi And user "Brian" has created a space "Project2" with the default quota using the GraphApi @@ -355,7 +355,7 @@ Feature: copy file | viewer | viewer | 403 | should not | - Scenario Outline: User copies a folder from space project with different role to space personal + Scenario Outline: user copies a folder from project space with different role to personal space Given the administrator has given "Brian" the role "Space Admin" using the settings api And user "Brian" has created a space "Project" with the default quota using the GraphApi And user "Brian" has created a folder "/folder1" in space "Project" @@ -374,7 +374,7 @@ Feature: copy file | viewer | - Scenario Outline: User copies a folder from space project with different role to space Shares with different role + Scenario Outline: Uuer copies a folder from project space with different role to share space with different role Given the administrator has given "Brian" the role "Space Admin" using the settings api And user "Brian" has created a space "Project" with the default quota using the GraphApi And user "Brian" has created folder "/testshare" @@ -399,7 +399,7 @@ Feature: copy file | viewer | should not | 17 | 403 | - Scenario Outline: User copies a folder from space personal to space project with different role + Scenario Outline: user copies a folder from personal space to project space with different role Given the administrator has given "Brian" the role "Space Admin" using the settings api And user "Brian" has created a space "Project" with the default quota using the GraphApi And user "Brian" has shared a space "Project" with settings: @@ -418,7 +418,7 @@ Feature: copy file | viewer | should not | 403 | - Scenario Outline: User copies a folder from space personal to space Shares with different permmissions + Scenario Outline: user copies a folder from personal space to share space with different permmissions Given user "Brian" has created folder "/testshare" And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "" And user "Alice" has accepted share "/testshare" offered by user "Brian" @@ -434,7 +434,7 @@ Feature: copy file | 17 | should not | 403 | - Scenario Outline: User copies a folder from space Shares with different role to space personal + Scenario Outline: user copies a folder from share space with different role to personal space Given the administrator has given "Brian" the role "Space Admin" using the settings api And user "Brian" has created folder "/testshare" And user "Brian" has uploaded file with content "testshare content" to "/testshare/testshare.txt" @@ -451,7 +451,7 @@ Feature: copy file | 17 | - Scenario Outline: User copies a folder from space Shares with different role to space project with different role + Scenario Outline: user copies a folder from share space with different role to project space with different role Given the administrator has given "Brian" the role "Space Admin" using the settings api And user "Brian" has created a space "Project" with the default quota using the GraphApi And user "Brian" has shared a space "Project" with settings: @@ -474,7 +474,7 @@ Feature: copy file | editor | 17 | - Scenario Outline: User copies a folder from space Shares with different role to space project with role viewer + Scenario Outline: user copies a folder from share space with different role to project space with role viewer Given the administrator has given "Brian" the role "Space Admin" using the settings api And user "Brian" has created a space "Project" with the default quota using the GraphApi And user "Brian" has shared a space "Project" with settings: @@ -495,7 +495,7 @@ Feature: copy file | 17 | - Scenario: Copying a file to a folder with no permissions + Scenario: copying a file to a folder with no permissions Given using spaces DAV path And user "Brian" has created folder "/testshare" And user "Brian" has created a share with settings @@ -510,7 +510,7 @@ Feature: copy file And user "Alice" should not be able to download file "/testshare/textfile0.txt" from space "Shares" - Scenario: Copying a file to overwrite a file into a folder with no permissions + Scenario: copying a file to overwrite a file into a folder with no permissions Given using spaces DAV path And user "Brian" has created folder "/testshare" And user "Brian" has uploaded file with content "ownCloud test text file 1" to "/testshare/overwritethis.txt" @@ -735,7 +735,7 @@ Feature: copy file | file_target | /Shares/BRIAN-FOLDER | - Scenario: Copying a file with an option "keep both" inside of the project space + Scenario: copying a file with an option "keep both" inside of the project space Given the administrator has given "Alice" the role "Space Admin" using the settings api And user "Alice" has created a space "Project" with the default quota using the GraphApi And user "Alice" has created a folder "/newfolder" in space "Project" @@ -749,7 +749,7 @@ Feature: copy file And for user "Alice" the content of the file "/newfolder/insideSpace (1).txt" of the space "Project" should be "new content" @issue-4797 - Scenario: Copying a file with an option "replace" inside of the project space + Scenario: copying a file with an option "replace" inside of the project space Given the administrator has given "Alice" the role "Space Admin" using the settings api And user "Alice" has created a space "Project" with the default quota using the GraphApi And user "Alice" has created a folder "/newfolder" in space "Project" @@ -768,7 +768,7 @@ Feature: copy file And as "Alice" file "insideSpace.txt" should not exist in the trashbin of the space "Project" - Scenario: Copying a file from Personal to Shares with an option "keep both" + Scenario: copying a file from Personal to Shares with an option "keep both" Given the administrator has given "Alice" the role "Space Admin" using the settings api And user "Alice" has created a space "Project" with the default quota using the GraphApi And user "Alice" has created a folder "/newfolder" in space "Project" @@ -790,7 +790,7 @@ Feature: copy file | newfolder/personal (1).txt | @issue-4797 - Scenario: Copying a file from Personal to Shares with an option "replace" + Scenario: copying a file from Personal to Shares with an option "replace" Given the administrator has given "Alice" the role "Space Admin" using the settings api And user "Alice" has created a space "Project" with the default quota using the GraphApi And user "Alice" has created a folder "/newfolder" in space "Project" diff --git a/tests/acceptance/features/apiSpacesShares/etagPropagation.feature b/tests/acceptance/features/apiSpacesShares/etagPropagation.feature index 56f7cac9a..4a768cf71 100644 --- a/tests/acceptance/features/apiSpacesShares/etagPropagation.feature +++ b/tests/acceptance/features/apiSpacesShares/etagPropagation.feature @@ -1,5 +1,8 @@ @api Feature: check etag propagation after different file alterations + As a user + I want to check the etag + So that I can make sure that they are correct after different file alterations Background: Given these users have been created with default attributes and without skeleton files: @@ -25,17 +28,17 @@ Feature: check etag propagation after different file alterations When user "Brian" copies file "/upload/file.txt" to "/upload/renamed.txt" inside space "Shares" using the WebDAV API Then the HTTP status code should be "201" And these etags should have changed - | user | path | space | - | Alice | / | Personal | - | Alice | /upload | Personal | - | Alice | /upload/renamed.txt | Personal | - | Brian | / | Shares | - | Brian | /upload | Shares | - | Brian | /upload/renamed.txt | Shares | + | user | path | space | + | Alice | / | Personal | + | Alice | /upload | Personal | + | Alice | /upload/renamed.txt | Personal | + | Brian | / | Shares | + | Brian | /upload | Shares | + | Brian | /upload/renamed.txt | Shares | And these etags should not have changed - | user | path | space | - | Alice | /upload/file.txt | Personal | - | Brian | /upload/file.txt | Shares | + | user | path | space | + | Alice | /upload/file.txt | Personal | + | Brian | /upload/file.txt | Shares | Scenario: copying a file inside a folder as a sharer changes its etag for all collaborators @@ -53,20 +56,20 @@ Feature: check etag propagation after different file alterations When user "Alice" copies file "/upload/file.txt" to "/upload/renamed.txt" using the WebDAV API Then the HTTP status code should be "201" And these etags should have changed - | user | path | space | - | Alice | / | Personal | - | Alice | /upload | Personal | - | Alice | /upload/renamed.txt | Personal | - | Brian | / | Shares | - | Brian | /upload | Shares | - | Brian | /upload/renamed.txt | Shares | + | user | path | space | + | Alice | / | Personal | + | Alice | /upload | Personal | + | Alice | /upload/renamed.txt | Personal | + | Brian | / | Shares | + | Brian | /upload | Shares | + | Brian | /upload/renamed.txt | Shares | And these etags should not have changed - | user | path | space | - | Alice | /upload/file.txt | Personal | - | Brian | /upload/file.txt | Shares | + | user | path | space | + | Alice | /upload/file.txt | Personal | + | Brian | /upload/file.txt | Shares | - Scenario: as share receiver renaming a file inside a folder changes its etag for all collaborators + Scenario: share receiver renaming a file inside a folder changes its etag for all collaborators Given user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt" And user "Alice" has shared folder "/upload" with user "Brian" And user "Brian" has accepted share "/upload" offered by user "Alice" @@ -79,18 +82,18 @@ Feature: check etag propagation after different file alterations When user "Brian" moves file "/upload/file.txt" to "/upload/renamed.txt" in space "Shares" using the WebDAV API Then the HTTP status code should be "201" And these etags should have changed - | user | path | space | - | Alice | / | Personal | - | Alice | /upload | Personal | - | Brian | / | Shares | - | Brian | /upload | Shares | + | user | path | space | + | Alice | / | Personal | + | Alice | /upload | Personal | + | Brian | / | Shares | + | Brian | /upload | Shares | And these etags should not have changed - | user | path | space | - | Alice | /upload/renamed.txt | Personal | - | Brian | /upload/renamed.txt | Shares | + | user | path | space | + | Alice | /upload/renamed.txt | Personal | + | Brian | /upload/renamed.txt | Shares | - Scenario: as sharer renaming a file inside a folder changes its etag for all collaborators + Scenario: sharer renaming a file inside a folder changes its etag for all collaborators Given user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt" And user "Alice" has shared folder "/upload" with user "Brian" And user "Brian" has accepted share "/upload" offered by user "Alice" @@ -103,18 +106,18 @@ Feature: check etag propagation after different file alterations When user "Alice" moves file "/upload/file.txt" to "/upload/renamed.txt" using the WebDAV API Then the HTTP status code should be "201" And these etags should have changed - | user | path | space | - | Alice | / | Personal | - | Alice | /upload | Personal | - | Brian | / | Shares | - | Brian | /upload | Shares | + | user | path | space | + | Alice | / | Personal | + | Alice | /upload | Personal | + | Brian | / | Shares | + | Brian | /upload | Shares | And these etags should not have changed - | user | path | space | - | Alice | /upload/renamed.txt | Personal | - | Brian | /upload/renamed.txt | Shares | + | user | path | space | + | Alice | /upload/renamed.txt | Personal | + | Brian | /upload/renamed.txt | Shares | - Scenario: as sharer moving a file from one folder to an other changes the etags of both folders for all collaborators + Scenario: sharer moving a file from one folder to an other changes the etags of both folders for all collaborators Given user "Alice" has created folder "/dst" And user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt" And user "Alice" has shared folder "/upload" with user "Brian" @@ -131,16 +134,16 @@ Feature: check etag propagation after different file alterations When user "Alice" moves file "/upload/file.txt" to "/dst/file.txt" using the WebDAV API Then the HTTP status code should be "201" And these etags should have changed - | user | path | space | - | Alice | / | Personal | - | Alice | /upload | Personal | - | Alice | /dst | Personal | - | Brian | / | Shares | - | Brian | /upload | Shares | - | Brian | /dst | Shares | + | user | path | space | + | Alice | / | Personal | + | Alice | /upload | Personal | + | Alice | /dst | Personal | + | Brian | / | Shares | + | Brian | /upload | Shares | + | Brian | /dst | Shares | - Scenario: as share receiver moving a file from one folder to an other changes the etags of both folders for all collaborators + Scenario: share receiver moving a file from one folder to an other changes the etags of both folders for all collaborators Given user "Alice" has created folder "/dst" And user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt" And user "Alice" has shared folder "/upload" with user "Brian" @@ -156,16 +159,16 @@ Feature: check etag propagation after different file alterations When user "Brian" moves file "/upload/file.txt" to "/dst/file.txt" in space "Shares" using the WebDAV API Then the HTTP status code should be "201" And these etags should have changed - | user | path | space | - | Alice | / | Personal | - | Alice | /upload | Personal | - | Alice | /dst | Personal | - | Brian | / | Shares | - | Brian | /upload | Shares | - | Brian | /dst | Shares | + | user | path | space | + | Alice | / | Personal | + | Alice | /upload | Personal | + | Alice | /dst | Personal | + | Brian | / | Shares | + | Brian | /upload | Shares | + | Brian | /dst | Shares | - Scenario: as sharer moving a folder from one folder to an other changes the etags of both folders for all collaborators + Scenario: sharer moving a folder from one folder to an other changes the etags of both folders for all collaborators Given user "Alice" has created folder "/dst" And user "Alice" has created folder "/upload/toMove" And user "Alice" has shared folder "/upload" with user "Brian" @@ -181,16 +184,16 @@ Feature: check etag propagation after different file alterations When user "Alice" moves file "/upload/toMove" to "/dst/toMove" using the WebDAV API Then the HTTP status code should be "201" And these etags should have changed - | user | path | space | - | Alice | / | Personal | - | Alice | /upload | Personal | - | Alice | /dst | Personal | - | Brian | / | Shares | - | Brian | /upload | Shares | - | Brian | /dst | Shares | + | user | path | space | + | Alice | / | Personal | + | Alice | /upload | Personal | + | Alice | /dst | Personal | + | Brian | / | Shares | + | Brian | /upload | Shares | + | Brian | /dst | Shares | - Scenario: as share reciever moving a folder from one folder to an other changes the etags of both folders for all collaborators + Scenario: share reciever moving a folder from one folder to an other changes the etags of both folders for all collaborators Given user "Alice" has created folder "/dst" And user "Alice" has created folder "/upload/toMove" And user "Alice" has shared folder "/upload" with user "Brian" @@ -206,16 +209,16 @@ Feature: check etag propagation after different file alterations When user "Brian" moves file "/upload/toMove" to "/dst/toMove" in space "Shares" using the WebDAV API Then the HTTP status code should be "201" And these etags should have changed - | user | path | space | - | Alice | / | Personal | - | Alice | /upload | Personal | - | Alice | /dst | Personal | - | Brian | / | Shares | - | Brian | /upload | Shares | - | Brian | /dst | Shares | + | user | path | space | + | Alice | / | Personal | + | Alice | /upload | Personal | + | Alice | /dst | Personal | + | Brian | / | Shares | + | Brian | /upload | Shares | + | Brian | /dst | Shares | - Scenario: as share receiver creating a folder inside a folder received as a share changes its etag for all collaborators + Scenario: share receiver creating a folder inside a folder received as a share changes its etag for all collaborators Given user "Alice" has shared folder "/upload" with user "Brian" And user "Brian" has accepted share "/upload" offered by user "Alice" And user "Alice" has stored etag of element "/" inside space "Personal" @@ -225,14 +228,14 @@ Feature: check etag propagation after different file alterations When user "Brian" creates a subfolder "/upload/new" in space "Shares" using the WebDav Api Then the HTTP status code should be "201" And these etags should have changed - | user | path | space | - | Alice | / | Personal | - | Alice | /upload | Personal | - | Brian | / | Shares | - | Brian | /upload | Shares | + | user | path | space | + | Alice | / | Personal | + | Alice | /upload | Personal | + | Brian | / | Shares | + | Brian | /upload | Shares | - Scenario: as sharer creating a folder inside a shared folder changes etag for all collaborators + Scenario: sharer creating a folder inside a shared folder changes etag for all collaborators Given user "Alice" has shared folder "/upload" with user "Brian" And user "Brian" has accepted share "/upload" offered by user "Alice" And user "Alice" has stored etag of element "/" inside space "Personal" @@ -242,14 +245,14 @@ Feature: check etag propagation after different file alterations When user "Alice" creates folder "/upload/new" using the WebDAV API Then the HTTP status code should be "201" And these etags should have changed - | user | path | space | - | Alice | / | Personal | - | Alice | /upload | Personal | - | Brian | / | Shares | - | Brian | /upload | Shares | + | user | path | space | + | Alice | / | Personal | + | Alice | /upload | Personal | + | Brian | / | Shares | + | Brian | /upload | Shares | - Scenario: as share receiver uploading a file inside a folder received as a share changes its etag for all collaborators + Scenario: share receiver uploading a file inside a folder received as a share changes its etag for all collaborators Given user "Alice" has shared folder "/upload" with user "Brian" And user "Brian" has accepted share "/upload" offered by user "Alice" And user "Alice" has stored etag of element "/" inside space "Personal" @@ -259,14 +262,14 @@ Feature: check etag propagation after different file alterations When user "Brian" uploads a file inside space "Shares" with content "uploaded content" to "/upload/file.txt" using the WebDAV API Then the HTTP status code should be "201" And these etags should have changed - | user | path | space | - | Alice | / | Personal | - | Alice | /upload | Personal | - | Brian | / | Shares | - | Brian | /upload | Shares | + | user | path | space | + | Alice | / | Personal | + | Alice | /upload | Personal | + | Brian | / | Shares | + | Brian | /upload | Shares | - Scenario: as sharer uploading a file inside a shared folder should update etags for all collaborators + Scenario: sharer uploading a file inside a shared folder should update etags for all collaborators Given user "Alice" has shared folder "/upload" with user "Brian" And user "Brian" has accepted share "/upload" offered by user "Alice" And user "Alice" has stored etag of element "/" inside space "Personal" @@ -276,14 +279,14 @@ Feature: check etag propagation after different file alterations When user "Alice" uploads file with content "uploaded content" to "/upload/file.txt" using the WebDAV API Then the HTTP status code should be "201" And these etags should have changed - | user | path | space | - | Alice | / | Personal | - | Alice | /upload | Personal | - | Brian | / | Shares | - | Brian | /upload | Shares | + | user | path | space | + | Alice | / | Personal | + | Alice | /upload | Personal | + | Brian | / | Shares | + | Brian | /upload | Shares | - Scenario: as share receiver overwriting a file inside a received shared folder should update etags for all collaborators + Scenario: share receiver overwriting a file inside a received shared folder should update etags for all collaborators Given user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt" And user "Alice" has shared folder "/upload" with user "Brian" And user "Brian" has accepted share "/upload" offered by user "Alice" @@ -294,14 +297,14 @@ Feature: check etag propagation after different file alterations When user "Brian" uploads a file inside space "Shares" with content "new content" to "/upload/file.txt" using the WebDAV API Then the HTTP status code should be "204" And these etags should have changed - | user | path | space | - | Alice | / | Personal | - | Alice | /upload | Personal | - | Brian | / | Shares | - | Brian | /upload | Shares | + | user | path | space | + | Alice | / | Personal | + | Alice | /upload | Personal | + | Brian | / | Shares | + | Brian | /upload | Shares | - Scenario: as sharer overwriting a file inside a shared folder should update etags for all collaborators + Scenario: sharer overwriting a file inside a shared folder should update etags for all collaborators Given user "Alice" has uploaded file with content "uploaded content" to "/upload/file.txt" And user "Alice" has shared folder "/upload" with user "Brian" And user "Brian" has accepted share "/upload" offered by user "Alice" @@ -312,14 +315,14 @@ Feature: check etag propagation after different file alterations When user "Alice" uploads file with content "new content" to "/upload/file.txt" using the WebDAV API Then the HTTP status code should be "204" And these etags should have changed - | user | path | space | - | Alice | / | Personal | - | Alice | /upload | Personal | - | Brian | / | Shares | - | Brian | /upload | Shares | + | user | path | space | + | Alice | / | Personal | + | Alice | /upload | Personal | + | Brian | / | Shares | + | Brian | /upload | Shares | - Scenario: As share receiver deleting (removing) a file changes the etags of all parents for all collaborators + Scenario: share receiver deleting (removing) a file changes the etags of all parents for all collaborators Given user "Alice" has created folder "/upload/sub" And user "Alice" has uploaded file with content "uploaded content" to "/upload/sub/file.txt" And user "Alice" has shared folder "/upload" with user "Brian" @@ -334,19 +337,19 @@ Feature: check etag propagation after different file alterations When user "Brian" removes the file "upload/sub/file.txt" from space "Shares" Then the HTTP status code should be "204" And these etags should have changed - | user | path | space | - | Alice | / | Personal | - | Alice | /upload | Personal | - | Alice | /upload/sub | Personal | - | Brian | / | Shares | - | Brian | /upload | Shares | - | Brian | /upload/sub | Shares | + | user | path | space | + | Alice | / | Personal | + | Alice | /upload | Personal | + | Alice | /upload/sub | Personal | + | Brian | / | Shares | + | Brian | /upload | Shares | + | Brian | /upload/sub | Shares | And these etags should not have changed | user | path | space | | Brian | / | Personal | - Scenario: As sharer deleting (removing) a file changes the etags of all parents for all collaborators + Scenario: sharer deleting (removing) a file changes the etags of all parents for all collaborators Given user "Alice" has created folder "/upload/sub" And user "Alice" has uploaded file with content "uploaded content" to "/upload/sub/file.txt" And user "Alice" has shared folder "/upload" with user "Brian" @@ -361,19 +364,19 @@ Feature: check etag propagation after different file alterations When user "Alice" removes the file "upload/sub/file.txt" from space "Personal" Then the HTTP status code should be "204" And these etags should have changed - | user | path | space | - | Alice | / | Personal | - | Alice | /upload | Personal | - | Alice | /upload/sub | Personal | - | Brian | / | Shares | - | Brian | /upload | Shares | - | Brian | /upload/sub | Shares | + | user | path | space | + | Alice | / | Personal | + | Alice | /upload | Personal | + | Alice | /upload/sub | Personal | + | Brian | / | Shares | + | Brian | /upload | Shares | + | Brian | /upload/sub | Shares | And these etags should not have changed | user | path | space | | Brian | / | Personal | - Scenario: As share receiver deleting (removing) a folder changes the etags of all parents for all collaborators + Scenario: share receiver deleting (removing) a folder changes the etags of all parents for all collaborators Given user "Alice" has created folder "/upload/sub" And user "Alice" has created folder "/upload/sub/toDelete" And user "Alice" has shared folder "/upload" with user "Brian" @@ -388,19 +391,19 @@ Feature: check etag propagation after different file alterations When user "Brian" removes the file "upload/sub/toDelete" from space "Shares" Then the HTTP status code should be "204" And these etags should have changed - | user | path | space | - | Alice | / | Personal | - | Alice | /upload | Personal | - | Alice | /upload/sub | Personal | - | Brian | / | Shares | - | Brian | /upload | Shares | - | Brian | /upload/sub | Shares | + | user | path | space | + | Alice | / | Personal | + | Alice | /upload | Personal | + | Alice | /upload/sub | Personal | + | Brian | / | Shares | + | Brian | /upload | Shares | + | Brian | /upload/sub | Shares | And these etags should not have changed | user | path | space | | Brian | / | Personal | - Scenario: As sharer deleting (removing) a folder changes the etags of all parents for all collaborators + Scenario: sharer deleting (removing) a folder changes the etags of all parents for all collaborators Given user "Alice" has created folder "/upload/sub" And user "Alice" has created folder "/upload/sub/toDelete" And user "Alice" has shared folder "/upload" with user "Brian" @@ -415,13 +418,13 @@ Feature: check etag propagation after different file alterations When user "Alice" removes the file "upload/sub/toDelete" from space "Personal" Then the HTTP status code should be "204" And these etags should have changed - | user | path | space | - | Alice | / | Personal | - | Alice | /upload | Personal | - | Alice | /upload/sub | Personal | - | Brian | / | Shares | - | Brian | /upload | Shares | - | Brian | /upload/sub | Shares | + | user | path | space | + | Alice | / | Personal | + | Alice | /upload | Personal | + | Alice | /upload/sub | Personal | + | Brian | / | Shares | + | Brian | /upload | Shares | + | Brian | /upload/sub | Shares | And these etags should not have changed | user | path | space | | Brian | / | Personal | diff --git a/tests/acceptance/features/apiSpacesShares/favorite.feature b/tests/acceptance/features/apiSpacesShares/favorite.feature index b6b570568..6841c1305 100644 --- a/tests/acceptance/features/apiSpacesShares/favorite.feature +++ b/tests/acceptance/features/apiSpacesShares/favorite.feature @@ -1,5 +1,8 @@ @api @skipOnOcV10 Feature: favorite + As a user + I want to favouite resources + So that I can acesses them quickly Background: Given these users have been created with default attributes and without skeleton files: diff --git a/tests/acceptance/features/apiSpacesShares/moveSpaces.feature b/tests/acceptance/features/apiSpacesShares/moveSpaces.feature index 12dee42eb..def01d039 100644 --- a/tests/acceptance/features/apiSpacesShares/moveSpaces.feature +++ b/tests/acceptance/features/apiSpacesShares/moveSpaces.feature @@ -12,7 +12,7 @@ Feature: move (rename) file And using spaces DAV path - Scenario Outline: Moving a file within same space project with role manager and editor + Scenario Outline: moving a file within same space project with role manager and editor Given the administrator has given "Brian" the role "Space Admin" using the settings api And user "Brian" has created a space "Project" with the default quota using the GraphApi And user "Brian" has created a folder "newfolder" in space "Project" @@ -32,7 +32,7 @@ Feature: move (rename) file | editor | - Scenario: Moving a file within same space project with role viewer + Scenario: moving a file within same space project with role viewer Given the administrator has given "Brian" the role "Space Admin" using the settings api And user "Brian" has created a space "Project" with the default quota using the GraphApi And user "Brian" has created a folder "newfolder" in space "Project" @@ -48,7 +48,7 @@ Feature: move (rename) file | insideSpace.txt | - Scenario Outline: User moves a file from a space project with different a role to a space project with different role + Scenario Outline: user moves a file from a space project with different a role to a space project with different role Given the administrator has given "Brian" the role "Space Admin" using the settings api And user "Brian" has created a space "Project1" with the default quota using the GraphApi And user "Brian" has created a space "Project2" with the default quota using the GraphApi @@ -78,7 +78,7 @@ Feature: move (rename) file | viewer | viewer | 403 | - Scenario Outline: User moves a file from a space project with different role to a space personal + Scenario Outline: user moves a file from a space project with different role to a space personal Given the administrator has given "Brian" the role "Space Admin" using the settings api And user "Brian" has created a space "Project" with the default quota using the GraphApi And user "Brian" has uploaded a file inside space "Project" with content "Project content" to "project.txt" @@ -98,7 +98,7 @@ Feature: move (rename) file | viewer | 403 | - Scenario Outline: User moves a file from space project with different role to space Shares with different role (permission) + Scenario Outline: user moves a file from space project with different role to space Shares with different role (permission) Given the administrator has given "Brian" the role "Space Admin" using the settings api And user "Brian" has created a space "Project" with the default quota using the GraphApi And user "Brian" has created folder "/testshare" @@ -124,7 +124,7 @@ Feature: move (rename) file | viewer | 17 | - Scenario Outline: User moves a file from space personal to space project with different role + Scenario Outline: user moves a file from space personal to space project with different role Given the administrator has given "Brian" the role "Space Admin" using the settings api And user "Brian" has created a space "Project" with the default quota using the GraphApi And user "Brian" has shared a space "Project" with settings: @@ -144,7 +144,7 @@ Feature: move (rename) file | viewer | 403 | - Scenario Outline: User moves a file from space personal to space Shares with different role (permission) + Scenario Outline: user moves a file from space personal to space Shares with different role (permission) Given user "Brian" has created folder "/testshare" And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "" And user "Alice" has accepted share "/testshare" offered by user "Brian" @@ -162,7 +162,7 @@ Feature: move (rename) file | 1 | - Scenario Outline: User moves a file from space Shares with different role (permissions) to space personal + Scenario Outline: user moves a file from space Shares with different role (permissions) to space personal Given user "Brian" has created folder "/testshare" And user "Brian" has uploaded file with content "testshare content" to "/testshare/testshare.txt" And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "" @@ -180,7 +180,7 @@ Feature: move (rename) file | 1 | - Scenario Outline: User moves a file from space Shares with different role (permissions) to space project with different role + Scenario Outline: user moves a file from space Shares with different role (permissions) to space project with different role Given the administrator has given "Brian" the role "Space Admin" using the settings api And user "Brian" has created a space "Project" with the default quota using the GraphApi And user "Brian" has shared a space "Project" with settings: @@ -206,7 +206,7 @@ Feature: move (rename) file | viewer | 17 | - Scenario: User moves a file from space Shares with role editor to space Shares with role editor + Scenario: user moves a file from space Shares with role editor to space Shares with role editor Given user "Brian" has created folder "/testshare1" And user "Brian" has created folder "/testshare2" And user "Brian" has uploaded file with content "testshare1 content" to "/testshare1/testshare1.txt" @@ -224,7 +224,7 @@ Feature: move (rename) file | /testshare2/testshare1.txt | - Scenario: User moves a file from space Shares with role editor to space Shares with role viewer + Scenario: user moves a file from space Shares with role editor to space Shares with role viewer Given user "Brian" has created folder "/testshare1" And user "Brian" has created folder "/testshare2" And user "Brian" has uploaded file with content "testshare1 content" to "/testshare1/testshare1.txt" @@ -240,7 +240,7 @@ Feature: move (rename) file | /testshare2/testshare1.txt | - Scenario: User moves a file from space Shares with role viewer to space Shares with role editor + Scenario: user moves a file from space Shares with role viewer to space Shares with role editor Given user "Brian" has created folder "/testshare1" And user "Brian" has created folder "/testshare2" And user "Brian" has uploaded file with content "testshare1 content" to "/testshare1/testshare1.txt" @@ -256,7 +256,7 @@ Feature: move (rename) file | /testshare2/testshare1.txt | - Scenario: Checking file id after a move between received shares + Scenario: checking file id after a move between received shares Given user "Alice" has created the following folders | path | | /folderA | @@ -280,7 +280,7 @@ Feature: move (rename) file And user "Brian" folder "/folderB/ONE" of the space "Shares" should have the previously stored id - Scenario: Moving a file out of a shared folder as a sharer + Scenario: moving a file out of a shared folder as a sharer Given user "Brian" has created folder "/testshare" And user "Brian" has uploaded file with content "test data" to "/testshare/testfile.txt" And user "Brian" has created a share with settings @@ -298,7 +298,7 @@ Feature: move (rename) file | /testshare/testfile.txt | - Scenario: Moving a folder out of a shared folder as a sharer + Scenario: moving a folder out of a shared folder as a sharer Given user "Brian" has created the following folders | path | | /testshare | @@ -319,7 +319,7 @@ Feature: move (rename) file | /testshare/testsubfolder | @issue-4797 - Scenario: Overwriting a file while moving + Scenario: overwriting a file while moving Given user "Brian" has created folder "/folder" And user "Brian" has uploaded file with content "old content version 1" to "/folder/testfile.txt" And user "Brian" has uploaded file with content "old content version 2" to "/folder/testfile.txt" diff --git a/tests/acceptance/features/apiSpacesShares/shareOperations.feature b/tests/acceptance/features/apiSpacesShares/shareOperations.feature index 583f96935..5aeae6aa9 100644 --- a/tests/acceptance/features/apiSpacesShares/shareOperations.feature +++ b/tests/acceptance/features/apiSpacesShares/shareOperations.feature @@ -1,5 +1,8 @@ @api @skipOnOcV10 Feature: sharing + As a user + I want to share resources with different permissions + So that I can manage the access to the resource Background: Given using OCS API version "1" @@ -10,7 +13,7 @@ Feature: sharing And using spaces DAV path - Scenario: Correct webdav share-permissions for received file with edit and reshare permissions + Scenario: correct webdav share-permissions for received file with edit and reshare permissions Given user "Alice" has uploaded file with content "foo" to "/tmp.txt" And user "Alice" has shared file "/tmp.txt" with user "Brian" And user "Brian" has accepted share "/tmp.txt" offered by user "Alice" @@ -21,7 +24,7 @@ Feature: sharing And the single response should contain a property "ocs:share-permissions" with value "19" - Scenario: Correct webdav share-permissions for received group shared file with edit and reshare permissions + Scenario: correct webdav share-permissions for received group shared file with edit and reshare permissions Given group "grp1" has been created And user "Brian" has been added to group "grp1" And user "Alice" has uploaded file with content "foo" to "/tmp.txt" @@ -38,7 +41,7 @@ Feature: sharing And the single response should contain a property "ocs:share-permissions" with value "19" - Scenario: Correct webdav share-permissions for received file with edit permissions but no reshare permissions + Scenario: correct webdav share-permissions for received file with edit permissions but no reshare permissions Given user "Alice" has uploaded file with content "foo" to "/tmp.txt" And user "Alice" has shared file "tmp.txt" with user "Brian" And user "Brian" has accepted share "/tmp.txt" offered by user "Alice" @@ -48,7 +51,7 @@ Feature: sharing And as user "Brian" file "/tmp.txt" inside space "Shares" should contain a property "ocs:share-permissions" with value "3" - Scenario: Correct webdav share-permissions for received group shared file with edit permissions but no reshare permissions + Scenario: correct webdav share-permissions for received group shared file with edit permissions but no reshare permissions Given group "grp1" has been created And user "Brian" has been added to group "grp1" And user "Alice" has uploaded file with content "foo" to "/tmp.txt" @@ -65,7 +68,7 @@ Feature: sharing And the single response should contain a property "ocs:share-permissions" with value "3" - Scenario: Correct webdav share-permissions for received file with reshare permissions but no edit permissions + Scenario: correct webdav share-permissions for received file with reshare permissions but no edit permissions Given user "Alice" has uploaded file with content "foo" to "/tmp.txt" And user "Alice" has shared file "tmp.txt" with user "Brian" And user "Brian" has accepted share "/tmp.txt" offered by user "Alice" @@ -75,7 +78,7 @@ Feature: sharing And as user "Brian" file "/tmp.txt" inside space "Shares" should contain a property "ocs:share-permissions" with value "17" - Scenario: Correct webdav share-permissions for received group shared file with reshare permissions but no edit permissions + Scenario: correct webdav share-permissions for received group shared file with reshare permissions but no edit permissions Given group "grp1" has been created And user "Brian" has been added to group "grp1" And user "Alice" has uploaded file with content "foo" to "/tmp.txt" @@ -92,7 +95,7 @@ Feature: sharing And the single response should contain a property "ocs:share-permissions" with value "17" - Scenario: Correct webdav share-permissions for received folder with all permissions + Scenario: correct webdav share-permissions for received folder with all permissions Given user "Alice" has created folder "/tmp" And user "Alice" has shared file "/tmp" with user "Brian" And user "Brian" has accepted share "/tmp" offered by user "Alice" @@ -103,7 +106,7 @@ Feature: sharing And the single response should contain a property "ocs:share-permissions" with value "31" - Scenario: Correct webdav share-permissions for received group shared folder with all permissions + Scenario: correct webdav share-permissions for received group shared folder with all permissions Given group "grp1" has been created And user "Brian" has been added to group "grp1" And user "Alice" has created folder "/tmp" @@ -119,7 +122,7 @@ Feature: sharing And the single response should contain a property "ocs:share-permissions" with value "31" - Scenario: Correct webdav share-permissions for received folder with all permissions but edit + Scenario: correct webdav share-permissions for received folder with all permissions but edit Given user "Alice" has created folder "/tmp" And user "Alice" has shared file "/tmp" with user "Brian" And user "Brian" has accepted share "/tmp" offered by user "Alice" @@ -129,7 +132,7 @@ Feature: sharing And as user "Brian" folder "/tmp" inside space "Shares" should contain a property "ocs:share-permissions" with value "29" - Scenario: Correct webdav share-permissions for received group shared folder with all permissions but edit + Scenario: correct webdav share-permissions for received group shared folder with all permissions but edit Given group "grp1" has been created And user "Brian" has been added to group "grp1" And user "Alice" has created folder "/tmp" @@ -139,24 +142,24 @@ Feature: sharing | shareWith | grp1 | | permissions | share,delete,create,read | And user "Brian" has accepted share "/tmp" offered by user "Alice" - When user "Brian" gets the following properties of folder "/tmp" inside space "Shares" using the WebDAV API + When user "Brian" gets the following properties of folder "/tmp" inside space "Shares" using the WebDAV API | propertyName | | ocs:share-permissions | Then the HTTP status code should be "200" And the single response should contain a property "ocs:share-permissions" with value "29" - Scenario: Correct webdav share-permissions for received folder with all permissions but create + Scenario: correct webdav share-permissions for received folder with all permissions but create Given user "Alice" has created folder "/tmp" And user "Alice" has shared file "/tmp" with user "Brian" And user "Brian" has accepted share "/tmp" offered by user "Alice" When user "Alice" updates the last share using the sharing API with | permissions | share,delete,update,read | Then the HTTP status code should be "200" - And as user "Brian" folder "/tmp" inside space "Shares" should contain a property "ocs:share-permissions" with value "27" + And as user "Brian" folder "/tmp" inside space "Shares" should contain a property "ocs:share-permissions" with value "27" - Scenario: Correct webdav share-permissions for received group shared folder with all permissions but create + Scenario: correct webdav share-permissions for received group shared folder with all permissions but create Given group "grp1" has been created And user "Brian" has been added to group "grp1" And user "Alice" has created folder "/tmp" @@ -173,7 +176,7 @@ Feature: sharing And the single response should contain a property "ocs:share-permissions" with value "27" - Scenario: Correct webdav share-permissions for received folder with all permissions but delete + Scenario: correct webdav share-permissions for received folder with all permissions but delete Given user "Alice" has created folder "/tmp" And user "Alice" has shared file "/tmp" with user "Brian" And user "Brian" has accepted share "/tmp" offered by user "Alice" @@ -183,7 +186,7 @@ Feature: sharing And as user "Brian" folder "/tmp" inside space "Shares" should contain a property "ocs:share-permissions" with value "23" - Scenario: Correct webdav share-permissions for received group shared folder with all permissions but delete + Scenario: correct webdav share-permissions for received group shared folder with all permissions but delete Given group "grp1" has been created And user "Brian" has been added to group "grp1" And user "Alice" has created folder "/tmp" @@ -200,7 +203,7 @@ Feature: sharing And the single response should contain a property "ocs:share-permissions" with value "23" - Scenario: Correct webdav share-permissions for received folder with all permissions but share + Scenario: correct webdav share-permissions for received folder with all permissions but share Given user "Alice" has created folder "/tmp" And user "Alice" has shared file "/tmp" with user "Brian" And user "Brian" has accepted share "/tmp" offered by user "Alice" @@ -210,7 +213,7 @@ Feature: sharing And as user "Brian" folder "/tmp" inside space "Shares" should contain a property "ocs:share-permissions" with value "15" - Scenario: Correct webdav share-permissions for received group shared folder with all permissions but share + Scenario: correct webdav share-permissions for received group shared folder with all permissions but share Given group "grp1" has been created And user "Brian" has been added to group "grp1" And user "Alice" has created folder "/tmp" @@ -227,7 +230,7 @@ Feature: sharing And the single response should contain a property "ocs:share-permissions" with value "15" - Scenario: Uploading a file to a folder received as a read-only group share + Scenario: uploading a file to a folder received as a read-only group share Given group "grp1" has been created And user "Brian" has been added to group "grp1" And user "Alice" has created folder "FOLDER" @@ -242,7 +245,7 @@ Feature: sharing And as "Alice" file "/FOLDER/textfile.txt" should not exist - Scenario: Uploading a file to a folder received as a upload-only user share + Scenario: uploading a file to a folder received as a upload-only user share Given user "Alice" has created folder "FOLDER" And user "Alice" has created a share with settings | path | FOLDER | @@ -255,12 +258,12 @@ Feature: sharing And the following headers should match these regular expressions for user "Brian" | ETag | /^"[a-f0-9:\.]{1,32}"$/ | And the content of file "/FOLDER/textfile.txt" for user "Alice" should be: - """ - new description - """ + """ + new description + """ - Scenario: Uploading a file to a folder received as a upload-only group share + Scenario: uploading a file to a folder received as a upload-only group share Given group "grp1" has been created And user "Brian" has been added to group "grp1" And user "Alice" has created folder "FOLDER" @@ -275,12 +278,12 @@ Feature: sharing And the following headers should match these regular expressions for user "Brian" | ETag | /^"[a-f0-9:\.]{1,32}"$/ | And the content of file "/FOLDER/textfile.txt" for user "Alice" should be: - """ - new description - """ + """ + new description + """ - Scenario: Uploading a file to a folder received as a read/write user share + Scenario: uploading a file to a folder received as a read/write user share Given user "Alice" has created folder "FOLDER" And user "Alice" has created a share with settings | path | FOLDER | @@ -291,12 +294,12 @@ Feature: sharing When user "Brian" uploads a file inside space "Shares" with content "new description" to "/FOLDER/textfile.txt" using the WebDAV API Then the HTTP status code should be "201" And the content of file "/FOLDER/textfile.txt" for user "Alice" should be: - """ - new description - """ + """ + new description + """ - Scenario: Uploading a file to a folder received as a read/write group share + Scenario: uploading a file to a folder received as a read/write group share Given group "grp1" has been created And user "Brian" has been added to group "grp1" And user "Alice" has created folder "FOLDER" @@ -309,12 +312,12 @@ Feature: sharing When user "Brian" uploads a file inside space "Shares" with content "new description" to "/FOLDER/textfile.txt" using the WebDAV API Then the HTTP status code should be "201" And the content of file "/FOLDER/textfile.txt" for user "Alice" should be: - """ - new description - """ + """ + new description + """ - Scenario: Uploading to a user shared folder with read/write permission when the sharer has insufficient quota + Scenario: uploading to a user shared folder with read/write permission when the sharer has insufficient quota Given user "Alice" has created folder "FOLDER" And user "Alice" has created a share with settings | path | FOLDER | @@ -328,7 +331,7 @@ Feature: sharing And as "Alice" file "/FOLDER/textfile.txt" should not exist - Scenario: Uploading to a user shared folder with upload-only permission when the sharer has insufficient quota + Scenario: uploading to a user shared folder with upload-only permission when the sharer has insufficient quota Given user "Alice" has created folder "FOLDER" And user "Alice" has created a share with settings | path | FOLDER | @@ -342,7 +345,7 @@ Feature: sharing And as "Alice" file "/FOLDER/textfile.txt" should not exist - Scenario: Uploading a file to a group shared folder with upload-only permission when the sharer has insufficient quota + Scenario: uploading a file to a group shared folder with upload-only permission when the sharer has insufficient quota Given group "grp1" has been created And user "Brian" has been added to group "grp1" And user "Alice" has created folder "FOLDER" @@ -358,7 +361,7 @@ Feature: sharing And as "Alice" file "/FOLDER/textfile.txt" should not exist - Scenario Outline: Sharer can download file uploaded with different permission by sharee to a shared folder + Scenario Outline: sharer can download file uploaded with different permission by sharee to a shared folder Given user "Alice" has created folder "FOLDER" And user "Alice" has created a share with settings | path | FOLDER | @@ -370,7 +373,7 @@ Feature: sharing And user "Alice" downloads file "/FOLDER/textfile.txt" using the WebDAV API Then the HTTP status code should be "200" And the downloaded content should be "some content" - Examples: + Examples: | permissions | | change | | create | diff --git a/tests/acceptance/features/apiSpacesShares/shareSpaces.feature b/tests/acceptance/features/apiSpacesShares/shareSpaces.feature index 6ec32d273..627c79608 100644 --- a/tests/acceptance/features/apiSpacesShares/shareSpaces.feature +++ b/tests/acceptance/features/apiSpacesShares/shareSpaces.feature @@ -2,6 +2,7 @@ Feature: Share spaces As the owner of a space I want to be able to add members to a space, and to remove access for them + So that I can manage the access to the space Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839 @@ -17,7 +18,7 @@ Feature: Share spaces And using spaces DAV path - Scenario Outline: A Space Admin can share a space to another user + Scenario Outline: space admin can share a space to another user When user "Alice" shares a space "share space" with settings: | shareWith | Brian | | role | | @@ -26,7 +27,7 @@ Feature: Share spaces And the OCS status message should be "OK" And for user "Brian" the JSON response should contain space called "share space" and match """ - { + { "type": "object", "required": [ "name", @@ -56,14 +57,14 @@ Feature: Share spaces | viewer | - Scenario: A user can see who has been granted access + Scenario: user can see who has been granted access When user "Alice" shares a space "share space" with settings: | shareWith | Brian | | role | viewer | Then the user "Alice" should have a space called "share space" granted to user "Brian" with role "viewer" @skipOnStable2.0 - Scenario: A user can see that the group has been granted access + Scenario: user can see that the group has been granted access Given group "sales" has been created When user "Alice" shares a space "share space" with settings: | shareWith | sales | @@ -74,7 +75,7 @@ Feature: Share spaces And the user "Alice" should have a space called "share space" granted to group "sales" with role "viewer" - Scenario: A user can see a file in a received shared space + Scenario: user can see a file in a received shared space Given user "Alice" has uploaded a file inside space "share space" with content "Test" to "test.txt" And user "Alice" has created a folder "Folder Main" in space "share space" When user "Alice" shares a space "share space" with settings: @@ -85,7 +86,7 @@ Feature: Share spaces | Folder Main | - Scenario: When a user unshares a space, the space becomes unavailable to the receiver + Scenario: user unshares a space Given user "Alice" has shared a space "share space" with settings: | shareWith | Brian | | role | viewer | @@ -119,7 +120,7 @@ Feature: Share spaces But the user "Brian" should not have a space called "share space" - Scenario Outline: Owner of a space cannot see the space after removing his access to the space + Scenario Outline: owner of a space cannot see the space after removing his access to the space Given user "Alice" has shared a space "share space" with settings: | shareWith | Brian | | role | manager | @@ -127,7 +128,7 @@ Feature: Share spaces Then the HTTP status code should be "200" And for user "Brian" the JSON response should contain space called "share space" owned by "Alice" and match """ - { + { "type": "object", "required": [ "name", @@ -157,7 +158,7 @@ Feature: Share spaces | Brian | - Scenario: A user can add another user to the space managers to enable him + Scenario: user can add another user to the space managers to enable him Given user "Alice" has uploaded a file inside space "share space" with content "Test" to "test.txt" When user "Alice" shares a space "share space" with settings: | shareWith | Brian | @@ -171,7 +172,7 @@ Feature: Share spaces | test.txt | - Scenario Outline: A user cannot share a disabled space to another user + Scenario Outline: user cannot share a disabled space to another user Given user "Alice" has disabled a space "share space" When user "Alice" shares a space "share space" with settings: | shareWith | Brian | @@ -187,7 +188,7 @@ Feature: Share spaces | viewer | - Scenario Outline: A user with manager role can share a space to another user + Scenario Outline: user with manager role can share a space to another user Given user "Alice" has shared a space "share space" with settings: | shareWith | Brian | | role | manager | @@ -199,7 +200,7 @@ Feature: Share spaces And the OCS status message should be "OK" And for user "Brian" the JSON response should contain space called "share space" and match """ - { + { "type": "object", "required": [ "name", @@ -229,7 +230,7 @@ Feature: Share spaces | viewer | - Scenario Outline: A user with editor or viewer role cannot share a space to another user + Scenario Outline: user with editor or viewer role cannot share a space to another user Given user "Alice" has shared a space "share space" with settings: | shareWith | Brian | | role | | @@ -291,7 +292,7 @@ Feature: Share spaces | viewer | editor | @skipOnStable2.0 - Scenario Outline: A user shares a space with a group + Scenario Outline: user shares a space with a group Given group "group2" has been created And the administrator has added a user "Brian" to the group "group2" using GraphApi And the administrator has added a user "Bob" to the group "group2" using GraphApi @@ -302,7 +303,7 @@ Feature: Share spaces Then the HTTP status code should be "200" And for user "Brian" the JSON response should contain space called "share space" and match """ - { + { "type": "object", "required": [ "name", @@ -327,7 +328,7 @@ Feature: Share spaces """ And for user "Bob" the JSON response should contain space called "share space" and match """ - { + { "type": "object", "required": [ "name", @@ -357,7 +358,7 @@ Feature: Share spaces | viewer | @skipOnStable2.0 - Scenario Outline: The user has no access to the space if access for the group has been removed + Scenario Outline: user has no access to the space if access for the group has been removed Given group "group2" has been created And the administrator has added a user "Brian" to the group "group2" using GraphApi And user "Alice" has shared a space "share space" with settings: @@ -374,7 +375,7 @@ Feature: Share spaces | viewer | @skipOnStable2.0 - Scenario: The user has no access to the space if he has been removed from the group + Scenario: user has no access to the space if he has been removed from the group Given group "group2" has been created And the administrator has added a user "Brian" to the group "group2" using GraphApi And the administrator has added a user "Bob" to the group "group2" using GraphApi @@ -389,7 +390,7 @@ Feature: Share spaces And the user "Brian" should not have a space called "share space" But for user "Bob" the JSON response should contain space called "share space" and match """ - { + { "type": "object", "required": [ "name", @@ -414,7 +415,7 @@ Feature: Share spaces """ @skipOnStable2.0 - Scenario: Users don't have access to the space if the group has been deleted + Scenario: users don't have access to the space if the group has been deleted Given group "group2" has been created And the administrator has added a user "Brian" to the group "group2" using GraphApi And the administrator has added a user "Bob" to the group "group2" using GraphApi @@ -428,7 +429,7 @@ Feature: Share spaces And the user "Brian" should not have a space called "share space" @skipOnStable2.0 - Scenario: User increases permissions for one member of the group or for the entire group + Scenario: user increases permissions for one member of the group or for the entire group Given group "sales" has been created And the administrator has added a user "Brian" to the group "sales" using GraphApi And user "Alice" has shared a space "share space" with settings: @@ -445,7 +446,7 @@ Feature: Share spaces Then the HTTP status code should be "201" @skipOnStable2.0 - Scenario: User increases permissions for the group, so the user's permissions are increased + Scenario: user increases permissions for the group, so the user's permissions are increased Given group "sales" has been created And the administrator has added a user "Brian" to the group "sales" using GraphApi And user "Alice" has shared a space "share space" with settings: @@ -462,7 +463,7 @@ Feature: Share spaces Then the HTTP status code should be "201" @skipOnStable2.0 - Scenario Outline: A Space Admin can share a space to the user with an expiration date + Scenario Outline: space Admin can share a space to the user with an expiration date When user "Alice" shares a space "share space" with settings: | shareWith | Brian | | role | | @@ -476,7 +477,7 @@ Feature: Share spaces | viewer | - Scenario Outline: A Space Admin can share a space to the group with an expiration date + Scenario Outline: space Admin can share a space to the group with an expiration date Given group "sales" has been created And the administrator has added a user "Brian" to the group "sales" using GraphApi When user "Alice" shares a space "share space" with settings: diff --git a/tests/acceptance/features/apiSpacesShares/shareSpacesViaLink.feature b/tests/acceptance/features/apiSpacesShares/shareSpacesViaLink.feature index 68f187921..3c4cf68c5 100644 --- a/tests/acceptance/features/apiSpacesShares/shareSpacesViaLink.feature +++ b/tests/acceptance/features/apiSpacesShares/shareSpacesViaLink.feature @@ -2,6 +2,7 @@ Feature: Share spaces via link As the manager of a space I want to be able to share a space via public link + So that anonymous user can have access to certain resources Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839 @@ -17,7 +18,7 @@ Feature: Share spaces via link And user "Alice" has uploaded a file inside space "share space" with content "some content" to "test.txt" - Scenario Outline: A manager can share a space to public via link with different permissions + Scenario Outline: manager can share a space to public via link with different permissions When user "Alice" creates a public link share of the space "share space" with settings: | permissions | | | password | | @@ -46,7 +47,7 @@ Feature: Share spaces via link | 15 | read,update,create,delete | d*V^o*Y03R9n8Z | link | | - Scenario: An uploader should be able to upload a file + Scenario: uploader should be able to upload a file When user "Alice" creates a public link share of the space "share space" with settings: | permissions | 4 | | password | 123 | @@ -70,7 +71,7 @@ Feature: Share spaces via link | lorem.txt | - Scenario Outline: An user without manager role cannot share a space to public via link + Scenario Outline: user without manager role cannot share a space to public via link Given user "Alice" has shared a space "share space" with settings: | shareWith | Brian | | role | | @@ -86,7 +87,7 @@ Feature: Share spaces via link | editor | - Scenario: An user with manager role can share a space to public via link + Scenario: user with manager role can share a space to public via link Given user "Alice" has shared a space "share space" with settings: | shareWith | Brian | | role | manager | @@ -97,7 +98,7 @@ Feature: Share spaces via link And for user "Alice" the space "share space" should contain the last created public link - Scenario: A user cannot share a disabled space to public via link + Scenario: user cannot share a disabled space to public via link Given user "Alice" has disabled a space "share space" When user "Alice" creates a public link share of the space "share space" with settings: | permissions | 1 | diff --git a/tests/acceptance/features/apiSpacesShares/shareSubItemOfSpace.feature b/tests/acceptance/features/apiSpacesShares/shareSubItemOfSpace.feature index 792b38f99..b3a201d2d 100644 --- a/tests/acceptance/features/apiSpacesShares/shareSubItemOfSpace.feature +++ b/tests/acceptance/features/apiSpacesShares/shareSubItemOfSpace.feature @@ -2,7 +2,7 @@ Feature: Share a file or folder that is inside a space As an user with manager space role I want to be able to share the data inside the space - + So that other users can have access to teh Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839 @@ -21,7 +21,7 @@ Feature: Share a file or folder that is inside a space And using new DAV path - Scenario Outline: A manager of the space can share an entity inside project space to another user with role + Scenario Outline: manager of the space can share an entity inside project space to another user with role And user "Alice" creates a share inside of space "share sub-item" with settings: | path | | | shareWith | Brian | @@ -42,7 +42,7 @@ Feature: Share a file or folder that is inside a space | file.txt | file | editor | 2042-03-25T23:59:59+0100 | 2042-03-25 | - Scenario Outline: A user participant of the project space with manager role can share an entity to another user + Scenario Outline: user participant of the project space with manager role can share an entity to another user Given user "Alice" has shared a space "share sub-item" with settings: | shareWith | Brian | | role | manager | @@ -66,7 +66,7 @@ Feature: Share a file or folder that is inside a space | file.txt | file | editor | | | - Scenario Outline: A user participant of the project space without space manager role cannot share an entity to another user + Scenario Outline: user participant of the project space without space manager role cannot share an entity to another user Given user "Alice" has shared a space "share sub-item" with settings: | shareWith | Brian | | role | | @@ -85,7 +85,7 @@ Feature: Share a file or folder that is inside a space | folder | viewer | 404 | No share permission | - Scenario Outline: A user participant of the project space can see the created resources share + Scenario Outline: user participant of the project space can see the created resources share Given user "Alice" has shared a space "share sub-item" with settings: | shareWith | Brian | | role | | @@ -102,7 +102,7 @@ Feature: Share a file or folder that is inside a space | manager | - Scenario: A user shares the folder to the group + Scenario: user shares the folder to the group Given group "sales" has been created And the administrator has added a user "Brian" to the group "sales" using GraphApi When user "Alice" creates a share inside of space "share sub-item" with settings: @@ -120,7 +120,7 @@ Feature: Share a file or folder that is inside a space | expiration | 2042-01-01 | @skipOnStable2.0 - Scenario: A user changes the expiration date + Scenario: user changes the expiration date Given user "Alice" has created a share inside of space "share sub-item" with settings: | path | folder | | shareWith | Brian | @@ -134,7 +134,7 @@ Feature: Share a file or folder that is inside a space | expiration | 2044-01-01 | - Scenario: A user deletes the expiration date + Scenario: user deletes the expiration date Given user "Alice" has created a share inside of space "share sub-item" with settings: | path | folder | | shareWith | Brian | diff --git a/tests/acceptance/features/apiSpacesShares/shareSubItemOfSpaceViaPublicLink.feature b/tests/acceptance/features/apiSpacesShares/shareSubItemOfSpaceViaPublicLink.feature index e33519d86..2c3dbca2f 100644 --- a/tests/acceptance/features/apiSpacesShares/shareSubItemOfSpaceViaPublicLink.feature +++ b/tests/acceptance/features/apiSpacesShares/shareSubItemOfSpaceViaPublicLink.feature @@ -1,21 +1,22 @@ @api @skipOnOcV10 Feature: Share a file or folder that is inside a space via public link - As an user with manager space role - I want to be able to share the data inside the space via public link + As an user with manager space role + I want to be able to share the data inside the space via public link + So that anonymous user can have access to certain resources - folder permissions: - | role | permissions | - | internal | 0 | - | viewer | 1 | - | uploader | 4 | - | contributor | 5 | - | editor | 15 | + folder permissions: + | role | permissions | + | internal | 0 | + | viewer | 1 | + | uploader | 4 | + | contributor | 5 | + | editor | 15 | - file permissions: - | role | permissions | - | internal | 0 | - | viewer | 1 | - | editor | 3 | + file permissions: + | role | permissions | + | internal | 0 | + | viewer | 1 | + | editor | 3 | Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839 @@ -32,7 +33,7 @@ Feature: Share a file or folder that is inside a space via public link And user "Alice" has uploaded a file inside space "share sub-item" with content "some content" to "folder/file.txt" @issue-5139 - Scenario Outline: A manager of the space can share an entity inside project space via public link + Scenario Outline: manager of the space can share an entity inside project space via public link When user "Alice" creates a public link share inside of space "share sub-item" with settings: | path | | | shareType | 3 | @@ -64,7 +65,7 @@ Feature: Share a file or folder that is inside a space via public link | folder/file.txt | /file.txt | 3 | 123 | link | 2042-03-25T23:59:59+0100 | file | text/plain | @issue-5139 - Scenario Outline: An user participant of the project space with space manager role can share an entity inside project space via public link + Scenario Outline: user participant of the project space with space manager role can share an entity inside project space via public link Given user "Alice" has shared a space "share sub-item" with settings: | shareWith | Brian | | role | manager | @@ -92,7 +93,7 @@ Feature: Share a file or folder that is inside a space via public link | folder/file.txt | /file.txt | file | text/plain | - Scenario Outline: An user participant of the project space without space manager role cannot share an entity inside project space via public link + Scenario Outline: user participant of the project space without space manager role cannot share an entity inside project space via public link Given user "Alice" has shared a space "share sub-item" with settings: | shareWith | Brian | | role | | @@ -114,7 +115,7 @@ Feature: Share a file or folder that is inside a space via public link | folder/file.txt | viewer | - Scenario Outline: User creates a new public link share of a file with edit permissions + Scenario Outline: user creates a new public link share of a file with edit permissions Given using OCS API version "" And user "Alice" has uploaded file with content "Random data" to "/file.txt" When user "Alice" creates a public link share using the sharing API with settings @@ -141,7 +142,7 @@ Feature: Share a file or folder that is inside a space via public link | 2 | 200 | @issue-5139 - Scenario Outline: An user participant of the project space can see the created public resources link + Scenario Outline: user participant of the project space can see the created public resources link Given user "Alice" has shared a space "share sub-item" with settings: | shareWith | Brian | | role | | diff --git a/tests/acceptance/features/apiSpacesShares/shareUploadTUS.feature b/tests/acceptance/features/apiSpacesShares/shareUploadTUS.feature index 3dbd91b3c..1f7b1e4b0 100644 --- a/tests/acceptance/features/apiSpacesShares/shareUploadTUS.feature +++ b/tests/acceptance/features/apiSpacesShares/shareUploadTUS.feature @@ -78,7 +78,7 @@ Feature: upload resources on share using TUS protocol | nonExistentFolder/file.txt | - Scenario: Uploading a file to a received share folder + Scenario: uploading a file to a received share folder Given user "Alice" has created folder "/toShare" And user "Alice" has shared folder "/toShare" with user "Brian" And user "Brian" has accepted share "/toShare" offered by user "Alice" @@ -88,7 +88,7 @@ Feature: upload resources on share using TUS protocol And for user "Alice" the content of the file "toShare/file.txt" of the space "Personal" should be "uploaded content" - Scenario: Uploading a file to a user read/write share folder + Scenario: uploading a file to a user read/write share folder Given user "Alice" has created folder "/toShare" And user "Alice" has shared folder "/toShare" with user "Brian" with permissions "change" And user "Brian" has accepted share "/toShare" offered by user "Alice" @@ -98,7 +98,7 @@ Feature: upload resources on share using TUS protocol And for user "Alice" the content of the file "toShare/file.txt" of the space "Personal" should be "uploaded content" - Scenario: Uploading a file into a group share as a share receiver + Scenario: uploading a file into a group share as a share receiver Given group "grp1" has been created And user "Brian" has been added to group "grp1" And user "Alice" has created folder "/toShare" @@ -110,7 +110,7 @@ Feature: upload resources on share using TUS protocol And for user "Alice" the content of the file "toShare/file.txt" of the space "Personal" should be "uploaded content" - Scenario: Overwrite file to a received share folder + Scenario: overwrite file to a received share folder Given user "Alice" has created folder "/toShare" And user "Alice" has uploaded file with content "original content" to "/toShare/file.txt" And user "Alice" has shared folder "/toShare" with user "Brian" @@ -130,7 +130,7 @@ Feature: upload resources on share using TUS protocol | file.txt | - Scenario: Upload a file to shared folder with checksum should return the checksum in the propfind for sharee + Scenario: upload a file to shared folder with checksum should return the checksum in the propfind for sharee Given user "Alice" has created folder "/FOLDER" And user "Alice" has shared folder "/FOLDER" with user "Brian" And user "Brian" has accepted share "/FOLDER" offered by user "Alice" @@ -145,7 +145,7 @@ Feature: upload resources on share using TUS protocol And the webdav checksum should match "SHA1:8cb2237d0679ca88db6464eac60da96345513964 MD5:827ccb0eea8a706c4c34a16891f84e7b ADLER32:02f80100" - Scenario: Upload a file to shared folder with checksum should return the checksum in the download header for sharee + Scenario: upload a file to shared folder with checksum should return the checksum in the download header for sharee Given user "Alice" has created folder "/FOLDER" And user "Alice" has shared folder "/FOLDER" with user "Brian" And user "Brian" has accepted share "/FOLDER" offered by user "Alice" @@ -159,7 +159,7 @@ Feature: upload resources on share using TUS protocol Then the header checksum should match "SHA1:8cb2237d0679ca88db6464eac60da96345513964" - Scenario: Sharer shares a file with correct checksum should return the checksum in the propfind for sharee + Scenario: sharer shares a file with correct checksum should return the checksum in the propfind for sharee Given user "Alice" has created a new TUS resource for the space "Personal" with content "" using the WebDAV API with these headers: | Upload-Length | 5 | # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt @@ -173,7 +173,7 @@ Feature: upload resources on share using TUS protocol And the webdav checksum should match "SHA1:8cb2237d0679ca88db6464eac60da96345513964 MD5:827ccb0eea8a706c4c34a16891f84e7b ADLER32:02f80100" - Scenario: Sharer shares a file with correct checksum should return the checksum in the download header for sharee + Scenario: sharer shares a file with correct checksum should return the checksum in the download header for sharee Given user "Alice" has created a new TUS resource for the space "Personal" with content "" using the WebDAV API with these headers: | Upload-Length | 5 | # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt @@ -186,7 +186,7 @@ Feature: upload resources on share using TUS protocol Then the header checksum should match "SHA1:8cb2237d0679ca88db6464eac60da96345513964" - Scenario: Sharee uploads a file to a received share folder with correct checksum + Scenario: sharee uploads a file to a received share folder with correct checksum Given user "Alice" has created folder "/FOLDER" And user "Alice" has shared folder "/FOLDER" with user "Brian" And user "Brian" has accepted share "/FOLDER" offered by user "Alice" @@ -201,7 +201,7 @@ Feature: upload resources on share using TUS protocol And for user "Alice" the content of the file "FOLDER/textFile.txt" of the space "Personal" should be "uploaded content" @issue-1755 - Scenario: Sharee uploads a file to a received share folder with wrong checksum should not work + Scenario: sharee uploads a file to a received share folder with wrong checksum should not work Given user "Alice" has created folder "/FOLDER" And user "Alice" has shared folder "/FOLDER" with user "Brian" And user "Brian" has accepted share "/FOLDER" offered by user "Alice" @@ -216,7 +216,7 @@ Feature: upload resources on share using TUS protocol | textFile.txt | @issue-1755 - Scenario: Sharer uploads a file to shared folder with wrong checksum should not work + Scenario: sharer uploads a file to shared folder with wrong checksum should not work Given user "Alice" has created folder "/FOLDER" And user "Alice" has shared folder "/FOLDER" with user "Brian" And user "Brian" has accepted share "/FOLDER" offered by user "Alice" @@ -233,7 +233,7 @@ Feature: upload resources on share using TUS protocol | textFile.txt | - Scenario: Sharer uploads a chunked file with correct checksum and share it with sharee should work + Scenario: sharer uploads a chunked file with correct checksum and share it with sharee should work Given user "Alice" has created a new TUS resource for the space "Personal" with content "" using the WebDAV API with these headers: | Upload-Length | 10 | # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt @@ -246,7 +246,7 @@ Feature: upload resources on share using TUS protocol Then for user "Brian" the content of the file "/textFile.txt" of the space "Shares" should be "0123456789" - Scenario: Sharee uploads a chunked file with correct checksum to a received share folder should work + Scenario: sharee uploads a chunked file with correct checksum to a received share folder should work Given user "Alice" has created folder "/FOLDER" And user "Alice" has shared folder "/FOLDER" with user "Brian" And user "Brian" has accepted share "/FOLDER" offered by user "Alice" @@ -263,7 +263,7 @@ Feature: upload resources on share using TUS protocol And for user "Alice" the content of the file "/FOLDER/textFile.txt" of the space "Personal" should be "0123456789" - Scenario: Sharer uploads a file with checksum and as a sharee overwrites the shared file with new data and correct checksum + Scenario: sharer uploads a file with checksum and as a sharee overwrites the shared file with new data and correct checksum Given user "Alice" has created a new TUS resource for the space "Personal" with content "" using the WebDAV API with these headers: | Upload-Length | 16 | # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt @@ -281,7 +281,7 @@ Feature: upload resources on share using TUS protocol And for user "Alice" the content of the file "/textFile.txt" of the space "Personal" should be "overwritten content" @issue-1755 - Scenario: Sharer uploads a file with checksum and as a sharee overwrites the shared file with new data and invalid checksum + Scenario: sharer uploads a file with checksum and as a sharee overwrites the shared file with new data and invalid checksum Given user "Alice" has created a new TUS resource for the space "Personal" with content "" using the WebDAV API with these headers: | Upload-Length | 16 | # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt diff --git a/tests/acceptance/features/bootstrap/GraphContext.php b/tests/acceptance/features/bootstrap/GraphContext.php index 562f93862..2c45b85a3 100644 --- a/tests/acceptance/features/bootstrap/GraphContext.php +++ b/tests/acceptance/features/bootstrap/GraphContext.php @@ -1794,7 +1794,7 @@ class GraphContext implements Context { } /** - * @When the user :user gets all users from that are members in the group :firstGroup or the group :secondGroup using the Graph API + * @When the user :user gets all users that are members in the group :firstGroup or the group :secondGroup using the Graph API * * @param string $user * @param string $firstGroup