mirror/opencloud
1
0
Fork 0
mirror of https://github.com/opencloud-eu/opencloud.git synced 2026-05-18 13:35:37 -04:00
Code Issues Packages Projects Releases Wiki Activity

Refactor the syntax of the scenarios in local API tests

Browse Source
This commit is contained in:
Swikriti Tripathi
2023-04-17 17:05:12 +05:45
parent 53419c9f2b
commit 7db5b86bd4
49 changed files with 528 additions and 463 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
tests/acceptance/features/apiAccountsHashDifficulty/assignRole.feature
View File

@@ -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 "<userRole>" using the settings api

2
tests/acceptance/features/apiAccountsHashDifficulty/createShareToSharesFolder.feature
View File

@@ -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 "<ocs_api_version>"
And user "Alice" has been created with default attributes and without skeleton files

2
tests/acceptance/features/apiAccountsHashDifficulty/webDavPUTAuthInvalid.feature
View File

@@ -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

3
tests/acceptance/features/apiAsyncUpload/delayPostprocessing.feature
View File

@@ -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

5
tests/acceptance/features/apiContract/copy.feature
View File

@@ -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:

4
tests/acceptance/features/apiContract/propfind.feature
View File

@@ -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:

8
tests/acceptance/features/apiContract/sharesReport.feature
View File

@@ -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_version> 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_version> 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"

4
tests/acceptance/features/apiContract/spacesSharesReport.feature
View File

@@ -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

7
tests/acceptance/features/apiCors/cors.feature
View File

@@ -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 "<ocs_api_version>"
When user "Alice" sends HTTP method "GET" to OCS API endpoint "<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 "<ocs_api_version>"
When user "Alice" sends HTTP method "GET" to OCS API endpoint "<endpoint>" with headers
| header | value |

4
tests/acceptance/features/apiGraph/addUserToGroup.feature
View File

@@ -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 "<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
"""

4
tests/acceptance/features/apiGraph/changeOwnPassword.feature
View File

@@ -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

4
tests/acceptance/features/apiGraph/createGroup.feature
View File

@@ -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

3
tests/acceptance/features/apiGraph/createGroupCaseSensitive.feature
View File

@@ -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

14
tests/acceptance/features/apiGraph/createUser.feature
View File

@@ -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 | <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 "<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

22
tests/acceptance/features/apiGraph/deleteUser.feature
View File

@@ -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 | <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 "<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 "<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 "<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 "<role>" using the settings api
And the administrator has given "Alice" the role "<userRole>" 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

33
tests/acceptance/features/apiGraph/editUser.feature
View File

@@ -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 "<newEmail>" using the Graph API
Then the HTTP status code should be "<code>"
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 "<userName>" using the Graph API
Then the HTTP status code should be "<code>"
@@ -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 "<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 "<userRole>" 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 "<newDisplayName>" 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 "<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 "<userRole>" 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 "<userRole>" 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 "<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 "<role>" using the settings api

1
tests/acceptance/features/apiGraph/getApplications.feature
View File

@@ -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

4
tests/acceptance/features/apiGraph/getGroup.feature
View File

@@ -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 "<group>" has been created
When user "Alice" gets details of the group "<group>" using the Graph API
Then the HTTP status code should be "200"

4
tests/acceptance/features/apiGraph/getUser.feature
View File

@@ -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
"""

29
tests/acceptance/features/apiSpaces/changeSpaces.feature
View File

@@ -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 "<user>" changes the name of the "Project Jupiter" space to "<expectedName>"
Then the HTTP status code should be "<code>"
And for user "<user>" the JSON response should contain space called "<expectedName>" 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 "<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 "<code>"
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 "<user>" changes the quota of the "Project Jupiter" space to "100"
Then the HTTP status code should be "<code>"
And for user "<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 "<quotaValue>"
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 "<user>" has uploaded a file inside space "Project Jupiter" with content "" to ".space/<fileName>"
When user "<user>" sets the file ".space/<fileName>" 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 "<quotaValue>"
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 "<quotaValue>"
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"

6
tests/acceptance/features/apiSpaces/createSpace.feature
View File

@@ -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 "<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 "<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 "<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"

2
tests/acceptance/features/apiSpaces/disableAndDeleteSpaces.feature
View File

@@ -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 "<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"

8
tests/acceptance/features/apiSpaces/download.feature
View File

@@ -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 "<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"

6
tests/acceptance/features/apiSpaces/editPublicLinkOfSpace.feature
View File

@@ -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 | <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 |

8
tests/acceptance/features/apiSpaces/filePreviews.feature
View File

@@ -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 "<entity>"
When user "Alice" downloads the preview of "<entity>" of the space "previews of the files" with width "<width>" and height "<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 "<source>" to "<destination>" via TUS inside of the space "previews of the files" using the WebDAV API
When user "Alice" downloads the preview of "<destination>" of the space "previews of the files" with width "<width>" and height "<height>" using the WebDAV API

17
tests/acceptance/features/apiSpaces/listSpaces.feature
View File

@@ -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 "<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 "<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

1
tests/acceptance/features/apiSpaces/notification.feature
View File

@@ -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:

17
tests/acceptance/features/apiSpaces/quota.feature
View File

@@ -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 "<spaceName>" of type "project" with quota "<total>"
When user "Alice" uploads a file inside space "<spaceName>" with content "<fileContent>" to "test.txt" using the WebDAV API
Then for user "Alice" the JSON response should contain space called "<spaceName>" 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 "<file_upload>" to "/demo.txt"
When the user "Alice" requests these endpoints with "GET" with basic auth

11
tests/acceptance/features/apiSpaces/removeSpaceObjects.feature
View File

@@ -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 | <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 | <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 | <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

20
tests/acceptance/features/apiSpaces/resharing.feature
View File

@@ -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 "<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 "<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 "<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 "<user>" shares folder "Shares/folder" with user "Ember" with permissions "<permissions>" using the sharing API
Then the OCS status code should be "<code>"
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 "<shareepermissions>"
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

10
tests/acceptance/features/apiSpaces/restoreSpaceObjects.feature
View File

@@ -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 | <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 | <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 | <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"

9
tests/acceptance/features/apiSpaces/restoreSpaces.feature
View File

@@ -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:

20
tests/acceptance/features/apiSpaces/search.feature
View File

@@ -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

35
tests/acceptance/features/apiSpaces/spaceManagement.feature
View File

@@ -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 "<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"

26
tests/acceptance/features/apiSpaces/tag.feature
View File

@@ -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 | <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 |

11
tests/acceptance/features/apiSpaces/uploadSpaces.feature
View File

@@ -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 | <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 | <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

7
tests/acceptance/features/apiSpacesShares/changingFilesShare.feature
View File

@@ -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"

7
tests/acceptance/features/apiSpacesShares/checksum.feature
View File

@@ -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"

62
tests/acceptance/features/apiSpacesShares/copySpaces.feature
View File

@@ -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 "<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"

279
tests/acceptance/features/apiSpacesShares/etagPropagation.feature
View File

@@ -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 |

3
tests/acceptance/features/apiSpacesShares/favorite.feature
View File

@@ -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:

32
tests/acceptance/features/apiSpacesShares/moveSpaces.feature
View File

@@ -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 "<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 "<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"

83
tests/acceptance/features/apiSpacesShares/shareOperations.feature
View File

@@ -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 |

49
tests/acceptance/features/apiSpacesShares/shareSpaces.feature
View File

@@ -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 | <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 | <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 | <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:

11
tests/acceptance/features/apiSpacesShares/shareSpacesViaLink.feature
View File

@@ -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 | <permissions> |
| password | <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 | <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 |

16
tests/acceptance/features/apiSpacesShares/shareSubItemOfSpace.feature
View File

@@ -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 | <entity> |
| 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 | <spaceRole> |
@@ -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 | <spaceRole> |
@@ -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 |

39
tests/acceptance/features/apiSpacesShares/shareSubItemOfSpaceViaPublicLink.feature
View File

@@ -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 | <entity> |
| 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 | <spaceRole> |
@@ -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 "<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 | <spaceRole> |

30
tests/acceptance/features/apiSpacesShares/shareUploadTUS.feature
View File

@@ -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

2
tests/acceptance/features/bootstrap/GraphContext.php
View File

@@ -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