sevenhill/QSfera
1
0
Fork 0
Code Issues Pull Requests Actions 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-20 15:32:15 +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
tests/acceptance/features/apiAccountsHashDifficulty/assignRole.feature
+4 -3
View File
@@ -1,9 +1,10 @@
@api @api
Feature: assign role Feature: assign role
As an admin, I want to assign roles to users. As an admin,
I cannot change my own role. I want to assign roles to users
Users without an admin role cannot get the list of roles, assignments list and assign roles to users So that I can provide them different authority
Scenario Outline: only admin user can see all existing roles Scenario Outline: only admin user can see all existing roles
Given user "Alice" has been created with default attributes and without skeleton files 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 And the administrator has given "Alice" the role "<userRole>" using the settings api
tests/acceptance/features/apiAccountsHashDifficulty/createShareToSharesFolder.feature
+1 -1
View File
@@ -8,7 +8,7 @@ Feature: sharing
See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839 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 Given auto-accept shares has been disabled
And using OCS API version "<ocs_api_version>" And using OCS API version "<ocs_api_version>"
And user "Alice" has been created with default attributes and without skeleton files And user "Alice" has been created with default attributes and without skeleton files
tests/acceptance/features/apiAccountsHashDifficulty/webDavPUTAuthInvalid.feature
+1 -1
View File
@@ -1,7 +1,7 @@
@api @skipOnReva @api @skipOnReva
Feature: attempt to PUT files with invalid password Feature: attempt to PUT files with invalid password
As an admin 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 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 Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production
tests/acceptance/features/apiAsyncUpload/delayPostprocessing.feature
+3
View File
@@ -1,5 +1,8 @@
@api @api
Feature: delay post-processing of uploaded files 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: Background:
Given user "Alice" has been created with default attributes and without skeleton files Given user "Alice" has been created with default attributes and without skeleton files
tests/acceptance/features/apiContract/copy.feature
+4 -1
View File
@@ -1,6 +1,9 @@
@api @skipOnOcV10 @api @skipOnOcV10
Feature: Copy test 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: Background:
Given these users have been created with default attributes and without skeleton files: Given these users have been created with default attributes and without skeleton files:
tests/acceptance/features/apiContract/propfind.feature
+3 -1
View File
@@ -1,6 +1,8 @@
@api @skipOnOcV10 @api @skipOnOcV10
Feature: Propfind test 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: Background:
Given these users have been created with default attributes and without skeleton files: Given these users have been created with default attributes and without skeleton files:
tests/acceptance/features/apiContract/sharesReport.feature
+5 -3
View File
@@ -1,6 +1,8 @@
@api @api
Feature: REPORT request to Shares space 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: Background:
Given these users have been created with default attributes and without skeleton files: 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" 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 Given using <dav_version> DAV path
And user "Brian" has accepted share "/folderMain" offered by user "Alice" And user "Brian" has accepted share "/folderMain" offered by user "Alice"
When user "Brian" searches for "SubFolder1" using the WebDAV API When user "Brian" searches for "SubFolder1" using the WebDAV API
@@ -32,7 +34,7 @@ Feature: REPORT request to Shares space
| new | | 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 Given using <dav_version> DAV path
And user "Brian" has accepted share "/folderMain" offered by user "Alice" 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" And user "Alice" has uploaded file with content "Not all those who wander are lost." to "/folderMain/SubFolder1/subFOLDER2/frodo.txt"
tests/acceptance/features/apiContract/spacesSharesReport.feature
+3 -1
View File
@@ -1,6 +1,8 @@
@api @skipOnOcV10 @api @skipOnOcV10
Feature: Report test 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 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 See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839
tests/acceptance/features/apiCors/cors.feature
+5 -2
View File
@@ -2,12 +2,15 @@
# CORS_ALLOWED_ORIGINS=https://aphno.badal # CORS_ALLOWED_ORIGINS=https://aphno.badal
@api @skipOnOcV10 @api @skipOnOcV10
Feature: CORS headers 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: Background:
Given user "Alice" has been created with default attributes and without skeleton files Given user "Alice" has been created with default attributes and without skeleton files
@issue-5195 @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>" Given using OCS API version "<ocs_api_version>"
When user "Alice" sends HTTP method "GET" to OCS API endpoint "<endpoint>" with headers When user "Alice" sends HTTP method "GET" to OCS API endpoint "<endpoint>" with headers
| header | value | | header | value |
@@ -28,7 +31,7 @@ Feature: CORS headers
| 2 | /apps/files_sharing/api/v1/shares | 200 | 200 | | 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>" Given using OCS API version "<ocs_api_version>"
When user "Alice" sends HTTP method "GET" to OCS API endpoint "<endpoint>" with headers When user "Alice" sends HTTP method "GET" to OCS API endpoint "<endpoint>" with headers
| header | value | | header | value |
tests/acceptance/features/apiGraph/addUserToGroup.feature
+2 -2
View File
@@ -120,10 +120,10 @@ Feature: add users to group
| Alice | var/../etc | | Alice | var/../etc |
@issue-5938 @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 Given the administrator has given "Alice" the role "<role>" using the settings api
And group "groupA" has been created 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" Then the HTTP status code should be "403"
And the JSON data of the response should match And the JSON data of the response should match
""" """
tests/acceptance/features/apiGraph/changeOwnPassword.feature
+3 -1
View File
@@ -1,6 +1,8 @@
@api @api
Feature: an user changes its own password 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 Scenario Outline: change own password
Given user "Alice" has been created with default attributes and without skeleton files Given user "Alice" has been created with default attributes and without skeleton files
tests/acceptance/features/apiGraph/createGroup.feature
+3 -1
View File
@@ -1,6 +1,8 @@
@api @skipOnOcV10 @api @skipOnOcV10
Feature: create group 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: Background:
Given user "Alice" has been created with default attributes and without skeleton files Given user "Alice" has been created with default attributes and without skeleton files
tests/acceptance/features/apiGraph/createGroupCaseSensitive.feature
+3
View File
@@ -1,5 +1,8 @@
@api @api
Feature: create groups, group names are case insensitive 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 @issue-3516
Scenario Outline: group names are case insensitive, creating groups with different upper and lower case names Scenario Outline: group names are case insensitive, creating groups with different upper and lower case names
tests/acceptance/features/apiGraph/createUser.feature
+8 -6
View File
@@ -1,6 +1,8 @@
@api @skipOnOcV10 @api @skipOnOcV10
Feature: create user 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 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 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 Given user "Alice" has been created with default attributes and without skeleton files
@issue-3516 @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 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: When the user "Alice" creates a new user using GraphAPI with the following settings:
| userName | <userName> | | userName | <userName> |
@@ -35,7 +37,7 @@ Feature: create user
| Alice | same userName | new@example.org | 123 | 400 | true | should | | 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 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: When the user "Alice" creates a new user using GraphAPI with the following settings:
| userName | | | userName | |
@@ -46,7 +48,7 @@ Feature: create user
Then the HTTP status code should be "400" 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 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: When the user "Alice" creates a new user using GraphAPI with the following settings:
| userName | user | | userName | user |
@@ -63,7 +65,7 @@ Feature: create user
| Guest | | Guest |
@issue-3516 @skipOnStable2.0 @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 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 "Alice" the role "Admin" using the settings api
And the user "Alice" has disabled user "Brian" using the Graph 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" Then the HTTP status code should be "400"
@skipOnStable2.0 @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 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 "Alice" the role "Admin" using the settings api
And the user "Alice" has deleted a user "Brian" using the Graph API And the user "Alice" has deleted a user "Brian" using the Graph API
tests/acceptance/features/apiGraph/deleteUser.feature
+12 -10
View File
@@ -1,6 +1,8 @@
@api @skipOnOcV10 @api @skipOnOcV10
Feature: delete user 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 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 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 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 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: And the user "Alice" has created a new user using the Graph API with the following settings:
| userName | <userName> | | userName | <userName> |
@@ -26,7 +28,7 @@ Feature: delete user
| name | pass with space | example@example.org | my pass | | 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 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 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 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 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 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 "Alice" the role "Admin" using the settings api
And the administrator has given "Brian" the role "<role>" 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 | | 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 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 When the user "Alice" deletes a user "Alice" using the Graph API
Then the HTTP status code should be "403" Then the HTTP status code should be "403"
And user "Alice" should exist 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 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 When the user "Alice" deletes a user "Alice" using the Graph API
Then the HTTP status code should be "401" Then the HTTP status code should be "401"
@@ -68,13 +70,13 @@ Feature: delete user
| Guest | | 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 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 When the user "Alice" tries to delete a nonexistent user using the Graph API
Then the HTTP status code should be "404" 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 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 When the user "Alice" tries to delete a nonexistent user using the Graph API
Then the HTTP status code should be "401" Then the HTTP status code should be "401"
@@ -85,7 +87,7 @@ Feature: delete user
| Guest | | 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 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 "Brian" the role "<role>" using the settings api
And the administrator has given "Alice" the role "<userRole>" 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 | | 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 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 user "Brian" has been created with default attributes and without skeleton files
And the user "Alice" has disabled user "Brian" using the Graph API And the user "Alice" has disabled user "Brian" using the Graph API
tests/acceptance/features/apiGraph/editUser.feature
+18 -15
View File
@@ -1,5 +1,8 @@
@api @skipOnOcV10 @api @skipOnOcV10
Feature: edit user 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 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 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 | | 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 When the user "Alice" changes the email of user "Brian" to "<newEmail>" using the Graph API
Then the HTTP status code should be "<code>" Then the HTTP status code should be "<code>"
And the user information of "Brian" should match this JSON schema 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 | | change to a invalid email | invalidEmail | 400 | brian@example.com |
@skipOnStable2.0 @issue-5763 @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 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 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>" Then the HTTP status code should be "<code>"
@@ -68,7 +71,7 @@ Feature: edit user
| empty user name | | 200 | Brian | | empty user name | | 200 | Brian |
@skipOnStable2.0 @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: Given the user "Alice" has created a new user using the Graph API with the following settings:
| userName | sam | | userName | sam |
| displayName | sam | | displayName | sam |
@@ -94,7 +97,7 @@ Feature: edit user
""" """
@skipOnStable2.0 @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: Given the user "Alice" has created a new user using the Graph API with the following settings:
| userName | sam | | userName | sam |
| displayName | 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 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 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" Then the HTTP status code should be "401"
@@ -146,7 +149,7 @@ Feature: edit user
| Guest | | 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 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: And the user "Alice" has created a new user using the Graph API with the following settings:
| userName | Carol | | userName | Carol |
@@ -187,7 +190,7 @@ Feature: edit user
| Guest | Admin | | 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 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" Then the HTTP status code should be "200"
And the user information of "Brian" should match this JSON schema And the user information of "Brian" should match this JSON schema
@@ -213,7 +216,7 @@ Feature: edit user
| displayName with characters | *:!;_+-&#(?) | 200 | *:!;_+-&#(?) | | 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 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 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" Then the HTTP status code should be "401"
@@ -239,7 +242,7 @@ Feature: edit user
| Guest | | 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 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: And the user "Alice" has created a new user using the Graph API with the following settings:
| userName | Carol | | userName | Carol |
@@ -280,14 +283,14 @@ Feature: edit user
| Guest | Admin | | 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" 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 When the user "Alice" resets the password of user "Brian" to "newpassword" using the Graph API
Then the HTTP status code should be "200" 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" 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 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: And the user "Alice" has created a new user using the Graph API with the following settings:
| userName | Carol | | userName | Carol |
@@ -316,7 +319,7 @@ Feature: edit user
| Guest | Admin | | Guest | Admin |
@skipOnStable2.0 @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 When the user "Alice" disables user "Brian" using the Graph API
Then the HTTP status code should be "200" Then the HTTP status code should be "200"
When user "Alice" gets information of user "Brian" using Graph API When user "Alice" gets information of user "Brian" using Graph API
@@ -358,7 +361,7 @@ Feature: edit user
""" """
@skipOnStable2.0 @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 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 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 When the user "Brian" tries to disable user "Carol" using the Graph API
@@ -407,7 +410,7 @@ Feature: edit user
| Guest | | Guest |
@skipOnStable2.0 @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 Given the user "Alice" has disabled user "Brian" using the Graph API
When the user "Alice" enables 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" Then the HTTP status code should be "200"
@@ -450,7 +453,7 @@ Feature: edit user
""" """
@skipOnStable2.0 @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 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 user "Alice" has disabled user "Carol" using the Graph API
And the administrator has given "Brian" the role "<role>" using the settings api And the administrator has given "Brian" the role "<role>" using the settings api
tests/acceptance/features/apiGraph/getApplications.feature
+1
View File
@@ -2,6 +2,7 @@
Feature: get applications Feature: get applications
As an user As an user
I want to be able to get applications information with existings roles I want to be able to get applications information with existings roles
So that I can see which role blongs to what user
Background: Background:
Given user "Alice" has been created with default attributes and without skeleton files Given user "Alice" has been created with default attributes and without skeleton files
tests/acceptance/features/apiGraph/getGroup.feature
+2 -2
View File
@@ -384,7 +384,7 @@ Feature: get groups and their members
| Guest | | Guest |
Scenario: Get details of a group Scenario: get details of a group
Given group "tea-lover" has been created Given group "tea-lover" has been created
When user "Alice" gets details of the group "tea-lover" using the Graph API When user "Alice" gets details of the group "tea-lover" using the Graph API
Then the HTTP status code should be "200" 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 Given group "<group>" has been created
When user "Alice" gets details of the group "<group>" using the Graph API When user "Alice" gets details of the group "<group>" using the Graph API
Then the HTTP status code should be "200" Then the HTTP status code should be "200"
tests/acceptance/features/apiGraph/getUser.feature
+2 -2
View File
@@ -752,7 +752,7 @@ Feature: get users
@skipOnStable2.0 @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 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 user "Carol" has been created with default attributes and without skeleton files
And group "tea-lover" has been created 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 "Alice" has been added to group "tea-lover"
And user "Brian" has been added to group "coffee-lover" And user "Brian" has been added to group "coffee-lover"
And user "Carol" has been added to group "wine-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" 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 And the JSON data of the response should contain the user "Alice Hansen" in the item 'value', the user-details should match
""" """
tests/acceptance/features/apiSpaces/changeSpaces.feature
+15 -14
View File
@@ -2,6 +2,7 @@
Feature: Change data of space Feature: Change data of space
As a user with space admin rights 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.) 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 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 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 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>" When user "<user>" changes the name of the "Project Jupiter" space to "<expectedName>"
Then the HTTP status code should be "<code>" Then the HTTP status code should be "<code>"
And for user "<user>" the JSON response should contain space called "<expectedName>" and match 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 | | 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" 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" Then the HTTP status code should be "200"
And for user "Alice" the JSON response should contain space called "Project Jupiter" and match 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" 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>" Then the HTTP status code should be "<code>"
Examples: Examples:
@@ -92,7 +93,7 @@ Feature: Change data of space
| Bob | 403 | | 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" When user "<user>" changes the quota of the "Project Jupiter" space to "100"
Then the HTTP status code should be "<code>" Then the HTTP status code should be "<code>"
And for user "<user>" the JSON response should contain space called "Project Jupiter" and match 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 | | 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>" When user "Alice" changes the quota of the "Project Jupiter" space to "<quotaValue>"
Then the HTTP status code should be "200" 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 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 | | -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" 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 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 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" 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" 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 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 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 | | 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" 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>" 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 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 | | Brian | spaceImage.png | spaceImage.png | image/png |
| Alice | spaceImage.gif | spaceImage.gif | image/gif | | 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" 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" 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 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" 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" 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 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 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 | | 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" 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 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 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 | | 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>" When user "Admin" changes the quota of the "Admin" space to "<quotaValue>"
Then the HTTP status code should be "200" 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 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" | | -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>" When user "Admin" changes the quota of the "Brian Murphy" space to "<quotaValue>"
Then the HTTP status code should be "200" 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 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 | | -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" When user "Admin" tries to change the name of the "non-existing" space to "new name"
Then the HTTP status code should be "404" Then the HTTP status code should be "404"
When user "Admin" tries to change the quota of the "non-existing" space to "10" When user "Admin" tries to change the quota of the "non-existing" space to "10"
tests/acceptance/features/apiSpaces/createSpace.feature
+3 -3
View File
@@ -8,7 +8,7 @@ Feature: create space
Given user "Alice" has been created with default attributes and without skeleton files Given user "Alice" has been created with default attributes and without skeleton files
@issue-5938 @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 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 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" Then the HTTP status code should be "403"
@@ -19,7 +19,7 @@ Feature: create space
| Guest | | 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 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 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" Then the HTTP status code should be "201"
@@ -90,7 +90,7 @@ Feature: create space
| Space Admin | | 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 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 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" Then the HTTP status code should be "201"
tests/acceptance/features/apiSpaces/disableAndDeleteSpaces.feature
+1 -1
View File
@@ -223,7 +223,7 @@ Feature: Disabling and deleting space
| Space Admin | | 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 Given the administrator has given "Carol" the role "<role>" using the settings api
And user "Alice" has disabled a space "Project Moon" And user "Alice" has disabled a space "Project Moon"
When user "Carol" tries to delete a space "Project Moon" owned by user "Alice" When user "Carol" tries to delete a space "Project Moon" owned by user "Alice"
tests/acceptance/features/apiSpaces/download.feature
+5 -3
View File
@@ -1,6 +1,8 @@
@api @skipOnOcV10 @api @skipOnOcV10
Feature: Download file in project space 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 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 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 | | 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 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" Then the HTTP status code should be "200"
And the following headers should be set And the following headers should be set
@@ -55,7 +57,7 @@ Feature: Download file in project space
| Brian | | 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" 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 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" Then the HTTP status code should be "403"
tests/acceptance/features/apiSpaces/editPublicLinkOfSpace.feature
+3 -3
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" 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" Given using OCS API version "2"
When user "Alice" updates the last public link share using the sharing API with When user "Alice" updates the last public link share using the sharing API with
| permissions | <permissions> | | permissions | <permissions> |
@@ -51,7 +51,7 @@ Feature: A manager of the space can edit public link
| 15 | read,update,create,delete | | newName | | 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" Given using OCS API version "2"
When user "Alice" shares a space "edit space" with settings: When user "Alice" shares a space "edit space" with settings:
| shareWith | Brian | | shareWith | Brian |
@@ -67,7 +67,7 @@ Feature: A manager of the space can edit public link
| viewer | | 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" Given using OCS API version "2"
And user "Alice" has shared a space "edit space" with settings: And user "Alice" has shared a space "edit space" with settings:
| shareWith | Brian | | shareWith | Brian |
tests/acceptance/features/apiSpaces/filePreviews.feature
+5 -3
View File
@@ -1,6 +1,8 @@
@api @skipOnOcV10 @api @skipOnOcV10
Feature: Preview file in project space 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 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 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 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>" 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 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" Then the HTTP status code should be "200"
@@ -24,7 +26,7 @@ Feature: Preview file in project space
| /name with spaces.txt | 1200 | 1200 | | /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 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 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 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
tests/acceptance/features/apiSpaces/listSpaces.feature
+9 -8
View File
@@ -1,7 +1,8 @@
@api @skipOnOcV10 @api @skipOnOcV10
Feature: List and create spaces Feature: List and create spaces
As a user 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 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 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 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 When user "Alice" lists all available spaces via the GraphApi
Then the HTTP status code should be "200" Then the HTTP status code should be "200"
And the JSON response should contain space called "Alice Hansen" and match 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 Given user "Brian" has been created with default attributes and without skeleton files
And user "Brian" has created folder "folder" And user "Brian" has created folder "folder"
And user "Brian" has shared folder "folder" with user "Alice" with permissions "31" 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" 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 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" 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'" 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" 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 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 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" 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'" When user "Alice" lists all available spaces via the GraphApi with query "$filter=driveType eq 'personal'"
Then the HTTP status code should be "200" Then the HTTP status code should be "200"
And the JSON response should contain space called "Alice Hansen" owned by "Alice" and match 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 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 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" Then the HTTP status code should be "201"
@@ -442,7 +443,7 @@ Feature: List and create spaces
| Space Admin | | 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 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 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 When user "Alice" tries to look up the single space "Project Venus" owned by the user "Admin" by using its id
tests/acceptance/features/apiSpaces/notification.feature
+1
View File
@@ -2,6 +2,7 @@
Feature: Notification Feature: Notification
As a user As a user
I want to be notified of actions related to me I want to be notified of actions related to me
So that I can stay updated about the information
Background: Background:
Given these users have been created with default attributes and without skeleton files: Given these users have been created with default attributes and without skeleton files:
tests/acceptance/features/apiSpaces/quota.feature
+10 -7
View File
@@ -1,7 +1,10 @@
@api @skipOnOcV10 @api @skipOnOcV10
Feature: State of the quota Feature: State of the quota
As a user 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: quota state indication:
| 0 - 75% | normal | | 0 - 75% | normal |
| 76 - 90% | nearing | | 76 - 90% | nearing |
@@ -17,7 +20,7 @@ Feature: State of the quota
And using spaces DAV path 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>" 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 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 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 | | 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" 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 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" 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" 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" 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 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 | | 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" 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" 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 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" 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" 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" 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 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" 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" 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" And user "Alice" has uploaded file "<file_upload>" to "/demo.txt"
When the user "Alice" requests these endpoints with "GET" with basic auth When the user "Alice" requests these endpoints with "GET" with basic auth
tests/acceptance/features/apiSpaces/removeSpaceObjects.feature
+5 -6
View File
@@ -2,8 +2,7 @@
Feature: Remove files, folder Feature: Remove files, folder
As a user As a user
I want to be able to remove files, folders I want to be able to remove files, folders
Users with the editor role can also remove objects So that I can remove unnecessary objects
Users with the viewer role cannot remove objects
Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production 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 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" 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: Given user "Alice" has shared a space "delete objects" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | <role> | | role | <role> |
@@ -37,7 +36,7 @@ Feature: Remove files, folder
| Brian | viewer | 403 | should | should not | | 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: Given user "Alice" has shared a space "delete objects" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | <role> | | role | <role> |
@@ -56,7 +55,7 @@ Feature: Remove files, folder
| Brian | viewer | 403 | should | should not | | 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: Given user "Alice" has shared a space "delete objects" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | <role> | | role | <role> |
@@ -101,7 +100,7 @@ Feature: Remove files, folder
| Brian | viewer | 403 | should | should not | 12 | | 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" When user "Alice" removes the folder "" from space "delete objects"
Then the HTTP status code should be "405" Then the HTTP status code should be "405"
And for user "Alice" the JSON response should contain space called "delete objects" and match And for user "Alice" the JSON response should contain space called "delete objects" and match
tests/acceptance/features/apiSpaces/resharing.feature
+11 -9
View File
@@ -1,6 +1,8 @@
@api @skipOnOcV10 @api @skipOnOcV10
Feature: Resharing 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 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 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" 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" 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" 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 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 | | 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 When user "Alice" gets all the shares inside the folder "folder" using the sharing API
Then the OCS status code should be "100" Then the OCS status code should be "100"
And the HTTP status code should be "200" And the HTTP status code should be "200"
@@ -53,13 +55,13 @@ Feature: Resharing
And user "Damian" should be included in the response 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 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" Then the OCS status code should be "404"
And the OCS status message should be "Cannot set the requested share permissions" 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" 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" And user "Fred" has accepted share "/folder" offered by user "Carol"
When user "<user>" updates the last share using the sharing API with When user "<user>" updates the last share using the sharing API with
@@ -73,7 +75,7 @@ Feature: Resharing
| Carol | 100 | should be | | 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" 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" And user "Gina" has accepted share "/folder" offered by user "Carol"
When user "<user>" deletes the last share using the sharing API When user "<user>" deletes the last share using the sharing API
@@ -87,7 +89,7 @@ Feature: Resharing
| Carol | 100 | should not exist | | 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 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>" Then the OCS status code should be "<code>"
Examples: Examples:
@@ -99,7 +101,7 @@ Feature: Resharing
| Damian | 31 | 404 | | 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" 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 "Alice" has shared file "/file.txt" with user "Brian" with permissions "<shareepermissions>"
And user "Brian" has accepted share "/file.txt" offered by user "Alice" And user "Brian" has accepted share "/file.txt" offered by user "Alice"
@@ -112,7 +114,7 @@ Feature: Resharing
| 19 | 19 | 100 | | 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 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 "Ember" to the group "security department" using GraphApi
And the administrator has added a user "Fred" to the group "security department" using GraphApi And the administrator has added a user "Fred" to the group "security department" using GraphApi
tests/acceptance/features/apiSpaces/restoreSpaceObjects.feature
+5 -5
View File
@@ -2,7 +2,7 @@
Feature: Restore files, folder Feature: Restore files, folder
As a user with manager and editor role As a user with manager and editor role
I want to be able to restore files, folders 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 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 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" 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: Given user "Alice" has shared a space "restore objects" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | <role> | | role | <role> |
@@ -38,7 +38,7 @@ Feature: Restore files, folder
| Brian | viewer | | 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: Given user "Alice" has shared a space "restore objects" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | <role> | | role | <role> |
@@ -56,7 +56,7 @@ Feature: Restore files, folder
| Brian | viewer | 403 | should not | should | | 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: Given user "Alice" has shared a space "restore objects" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | <role> | | role | <role> |
@@ -74,7 +74,7 @@ Feature: Restore files, folder
| Brian | viewer | 403 | should not | should | | 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" 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 "file is less than 30 bytes" to "/file.txt"
And user "Brian" has uploaded file with content "reduceContent" to "/file.txt" And user "Brian" has uploaded file with content "reduceContent" to "/file.txt"
tests/acceptance/features/apiSpaces/restoreSpaces.feature
+4 -5
View File
@@ -1,9 +1,8 @@
@api @skipOnOcV10 @api @skipOnOcV10
Feature: Restoring space Feature: Restoring space
As a manager of space As a manager of space
I want to be able to restore a disabled space. I want to be able to restore a disabled space
Only manager can restore disabled space So that I can retrieve all the data belonging to the space
The restored space must be visible to the other participants without loss of data
Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production 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 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 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" Given user "Alice" has disabled a space "restore a space"
When user "Alice" restores a disabled space "restore a space" When user "Alice" restores a disabled space "restore a space"
Then the HTTP status code should be "200" 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" 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 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: And user "Alice" has shared a space "restore a space" with settings:
tests/acceptance/features/apiSpaces/search.feature
+11 -9
View File
@@ -1,6 +1,8 @@
@api @skipOnOcV10 @api @skipOnOcV10
Feature: Search 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 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 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 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 When user "Alice" searches for "fol" using the WebDAV API
Then the HTTP status code should be "207" Then the HTTP status code should be "207"
And the search result should contain "4" entries And the search result should contain "4" entries
@@ -29,7 +31,7 @@ Feature: Search
| /folderMain/SubFolder1/subFOLDER2/insideTheFolder.txt | | /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 When user "Alice" searches for "SUB" using the WebDAV API
Then the HTTP status code should be "207" Then the HTTP status code should be "207"
And the search result should contain "2" entries And the search result should contain "2" entries
@@ -41,7 +43,7 @@ Feature: Search
| /folderMain/SubFolder1/subFOLDER2/insideTheFolder.txt | | /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: Given user "Alice" has created a share inside of space "find data" with settings:
| path | folderMain | | path | folderMain |
| shareWith | Brian | | shareWith | Brian |
@@ -57,7 +59,7 @@ Feature: Search
And for user "Brian" the search result should contain space "mountpoint/folderMain" 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" Given user "Alice" has created a folder ".space" in space "find data"
When user "Alice" searches for ".sp" using the WebDAV API When user "Alice" searches for ".sp" using the WebDAV API
Then the HTTP status code should be "207" Then the HTTP status code should be "207"
@@ -66,7 +68,7 @@ Feature: Search
| /.space | | /.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: Given user "Alice" has created a share inside of space "find data" with settings:
| path | folderMain | | path | folderMain |
| shareWith | Brian | | shareWith | Brian |
@@ -80,7 +82,7 @@ Feature: Search
| /SubFolder1/subFOLDER2/insideTheFolder.txt | | /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: Given user "Alice" has created a share inside of space "find data" with settings:
| path | folderMain | | path | folderMain |
| shareWith | Brian | | shareWith | Brian |
@@ -95,14 +97,14 @@ Feature: Search
| /SubFolder1/subFOLDER2/insideTheFolder.txt | | /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" Given user "Alice" has removed the folder "folderMain" from space "find data"
When user "Alice" searches for "folderMain" using the WebDAV API When user "Alice" searches for "folderMain" using the WebDAV API
Then the HTTP status code should be "207" Then the HTTP status code should be "207"
And the search result should contain "0" entries 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 When user "Alice" searches for "find data" using the WebDAV API
Then the HTTP status code should be "207" Then the HTTP status code should be "207"
And the search result should contain "1" entries And the search result should contain "1" entries
tests/acceptance/features/apiSpaces/spaceManagement.feature
+18 -17
View File
@@ -2,9 +2,10 @@
Feature: Space management Feature: Space management
As a user with space admin permission As a user with space admin permission
I want to be able to manage all existing project space 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 So that
- I can edit space: change quota, name, description - I can get all project space where I am not member using "graph/v1.0/drives" endpoint
- I can enable, disable, delete space - 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 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 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" 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'" When user "Brian" lists all spaces via the GraphApi with query "$filter=driveType eq 'project'"
Then the HTTP status code should be "200" Then the HTTP status code should be "200"
And the JSON response should contain space called "Project" and match 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" 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'" When user "Brian" lists all spaces via the GraphApi with query "$filter=driveType eq 'personal'"
Then the HTTP status code should be "200" Then the HTTP status code should be "200"
And the JSON response should contain space called "Alice Hansen" and match 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" 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 When user "Carol" tries to list all spaces via the GraphApi
Then the HTTP status code should be "200" 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 "Project"
And the json responded should not contain a space with name "Alice Hansen" And the json responded should not contain a space with name "Alice Hansen"
@skipOnStable2.0 @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" 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" Then the HTTP status code should be "200"
And for user "Alice" the JSON response should contain space called "New Name" and match 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" 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" Then the HTTP status code should be "403"
And for user "Alice" the JSON response should contain space called "Project" and match And for user "Alice" the JSON response should contain space called "Project" and match
@@ -130,7 +131,7 @@ Feature: Space management
""" """
@skipOnStable2.0 @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" 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" Then the HTTP status code should be "200"
And for user "Alice" the JSON response should contain space called "Project" and match 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" 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" 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" Then the HTTP status code should be "403"
@@ -171,7 +172,7 @@ Feature: Space management
""" """
@skipOnStable2.0 @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" When user "Brian" disables a space "Project" owned by user "Alice"
Then the HTTP status code should be "204" Then the HTTP status code should be "204"
And for user "Alice" the JSON response should contain space called "Project" and match 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" When user "Carol" tries to disable a space "Project" owned by user "Alice"
Then the HTTP status code should be "403" 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" When user "<user>" disables a space "Alice Hansen" owned by user "Alice"
Then the HTTP status code should be "403" Then the HTTP status code should be "403"
Examples: Examples:
@@ -226,14 +227,14 @@ Feature: Space management
| Carol | | Carol |
@skipOnStable2.0 @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" Given user "Alice" has disabled a space "Project"
When user "Brian" deletes a space "Project" owned by user "Alice" When user "Brian" deletes a space "Project" owned by user "Alice"
Then the HTTP status code should be "204" Then the HTTP status code should be "204"
And the user "Alice" should not have a space called "Project" 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" Given user "Alice" has disabled a space "Project"
When user "Carol" tries to delete a space "Project" owned by user "Alice" When user "Carol" tries to delete a space "Project" owned by user "Alice"
Then the HTTP status code should be "403" Then the HTTP status code should be "403"
@@ -275,13 +276,13 @@ Feature: Space management
""" """
@skipOnStable2.0 @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" Given user "Alice" has disabled a space "Project"
When user "Brian" restores a disabled space "Project" owned by user "Alice" When user "Brian" restores a disabled space "Project" owned by user "Alice"
Then the HTTP status code should be "200" 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" Given user "Alice" has disabled a space "Project"
When user "Carol" tries to restore a disabled space "Project" owned by user "Alice" When user "Carol" tries to restore a disabled space "Project" owned by user "Alice"
Then the HTTP status code should be "404" Then the HTTP status code should be "404"
tests/acceptance/features/apiSpaces/tag.feature
+14 -12
View File
@@ -1,6 +1,8 @@
@api @skipOnOcV10 @skipOnStable2.0 @api @skipOnOcV10 @skipOnStable2.0
Feature: Tag 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 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 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" 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: Given user "Alice" has shared a space "use-tag" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | viewer | | role | viewer |
@@ -52,7 +54,7 @@ Feature: Tag
| fileTag | | 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" 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" 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": When user "Alice" creates the following tags for folder "folderMain" of space "Alice Hansen":
@@ -82,7 +84,7 @@ Feature: Tag
| tag with symbol @^$#^%$@%!_+) | | 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: Given user "Alice" has shared a space "use-tag" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | <role> | | role | <role> |
@@ -102,7 +104,7 @@ Feature: Tag
| manager | 200 | should | | 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": Given user "Alice" has created the following tags for folder "folderMain" of the space "use-tag":
| folderTag | | folderTag |
| marketing | | marketing |
@@ -123,7 +125,7 @@ Feature: Tag
| marketing | | 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: Given user "Alice" has created a share inside of space "use-tag" with settings:
| path | folderMain | | path | folderMain |
| shareWith | Brian | | shareWith | Brian |
@@ -148,7 +150,7 @@ Feature: Tag
| manager | folder | folderMain | 200 | should | | 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: Given user "Alice" has created a share inside of space "use-tag" with settings:
| path | folderMain | | path | folderMain |
| shareWith | Brian | | shareWith | Brian |
@@ -176,7 +178,7 @@ Feature: Tag
| manager | folder | folderMain | 200 | should not | | 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": Given user "Alice" has created the following tags for folder "folderMain" of the space "use-tag":
| folderTag | | folderTag |
| marketing | | marketing |
@@ -191,7 +193,7 @@ Feature: Tag
| oc:tags | development | | 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": Given user "Alice" has created the following tags for folder "folderMain" of the space "use-tag":
| folderTag | | folderTag |
| marketing | | marketing |
@@ -209,7 +211,7 @@ Feature: Tag
| marketing | | 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": Given user "Alice" has created the following tags for folder "folderMain" of the space "use-tag":
| folderTag | | folderTag |
| marketing | | marketing |
@@ -222,7 +224,7 @@ Feature: Tag
| marketing | | 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": Given user "Alice" has created the following tags for folder "folderMain" of the space "use-tag":
| folderTag | | folderTag |
| marketing | | marketing |
@@ -241,7 +243,7 @@ Feature: Tag
| marketing | | 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": Given user "Alice" has created the following tags for folder "folderMain" of the space "use-tag":
| folderTag | | folderTag |
| marketing | | marketing |
tests/acceptance/features/apiSpaces/uploadSpaces.feature
+6 -5
View File
@@ -2,6 +2,7 @@
Feature: Upload files into a space Feature: Upload files into a space
As an user As an user
I want to be able to create folders and files in the space 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 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 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 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: Given user "Alice" has shared a space "Project Ceres" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | <role> | | role | <role> |
@@ -32,7 +33,7 @@ Feature: Upload files into a space
| viewer | 403 | should not | | 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: Given user "Alice" has shared a space "Project Ceres" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | <role> | | role | <role> |
@@ -75,7 +76,7 @@ Feature: Upload files into a space
| viewer | 403 | should not | 0 | | 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 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" Then the HTTP status code should be "201"
And for user "Alice" the space "Project Ceres" should contain these entries: And for user "Alice" the space "Project Ceres" should contain these entries:
@@ -84,7 +85,7 @@ Feature: Upload files into a space
| subFolder2 | | 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 When user "Alice" creates a folder "NewFolder" in space "Project Ceres" using the WebDav Api
Then the HTTP status code should be "201" 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 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 | | 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 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" 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 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
tests/acceptance/features/apiSpacesShares/changingFilesShare.feature
+5 -2
View File
@@ -1,5 +1,8 @@
@api @skipOnOcV10 @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: Background:
Given using spaces DAV path Given using spaces DAV path
@@ -9,7 +12,7 @@ Feature:
| Brian | | Brian |
@issue-4421 @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 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 uploaded file with content "some data" to "/textfile0.txt"
And user "Alice" has created folder "/PARENT" And user "Alice" has created folder "/PARENT"
tests/acceptance/features/apiSpacesShares/checksum.feature
+5 -2
View File
@@ -1,5 +1,8 @@
@api @skipOnOcV10 @api @skipOnOcV10
Feature: checksums 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: Background:
Given user "Alice" has been created with default attributes and without skeleton files 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 And user "Brian" has been created with default attributes and without skeleton files
@files_sharing-app-required @issue-1291 @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" 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 "Alice" has shared file "/myChecksumFile.txt" with user "Brian"
And user "Brian" has accepted share "/myChecksumFile.txt" offered by user "Alice" 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" And the webdav checksum should match "SHA1:3ee962b839762adb0ad8ba6023a4690be478de6f MD5:d70b40f177b14b470d1756a3c12b963a ADLER32:8ae90960"
@files_sharing-app-required @issue-1291 @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" 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 "Alice" has shared file "/myChecksumFile.txt" with user "Brian"
And user "Brian" has accepted share "/myChecksumFile.txt" offered by user "Alice" And user "Brian" has accepted share "/myChecksumFile.txt" offered by user "Alice"
tests/acceptance/features/apiSpacesShares/copySpaces.feature
+31 -31
View File
@@ -12,7 +12,7 @@ Feature: copy file
And using spaces DAV path 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 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 space "Project" with the default quota using the GraphApi
And user "Alice" has created a folder "/newfolder" in space "Project" And user "Alice" has created a folder "/newfolder" in space "Project"
@@ -31,7 +31,7 @@ Feature: copy file
| editor | | 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 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 space "Project" with the default quota using the GraphApi
And user "Alice" has created a folder "/newfolder" in space "Project" And user "Alice" has created a folder "/newfolder" in space "Project"
@@ -45,7 +45,7 @@ Feature: copy file
| /newfolder/insideSpace.txt | | /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 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 "Project1" with the default quota using the GraphApi
And user "Brian" has created a space "Project2" 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 | | 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 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 "Project1" with the default quota using the GraphApi
And user "Brian" has created a space "Project2" 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 | | 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 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 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" 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 | | 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 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 space "Project" with the default quota using the GraphApi
And user "Brian" has created folder "/testshare" And user "Brian" has created folder "/testshare"
@@ -131,7 +131,7 @@ Feature: copy file
| viewer | | 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 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 space "Project" with the default quota using the GraphApi
And user "Brian" has created folder "/testshare" And user "Brian" has created folder "/testshare"
@@ -152,7 +152,7 @@ Feature: copy file
| viewer | | 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 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 space "Project" with the default quota using the GraphApi
And user "Brian" has shared a space "Project" with settings: And user "Brian" has shared a space "Project" with settings:
@@ -170,7 +170,7 @@ Feature: copy file
| editor | | 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 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 space "Project" with the default quota using the GraphApi
And user "Brian" has shared a space "Project" with settings: And user "Brian" has shared a space "Project" with settings:
@@ -183,7 +183,7 @@ Feature: copy file
| /personal.txt | | /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" Given user "Brian" has created folder "/testshare"
And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "31" And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "31"
And user "Alice" has accepted share "/testshare" offered by user "Brian" 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" 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" Given user "Brian" has created folder "/testshare"
And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "17" And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "17"
And user "Alice" has accepted share "/testshare" offered by user "Brian" And user "Alice" has accepted share "/testshare" offered by user "Brian"
@@ -206,7 +206,7 @@ Feature: copy file
| /testshare/personal.txt | | /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 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 created folder "/testshare"
And user "Brian" has uploaded file with content "testshare content" to "/testshare/testshare.txt" And user "Brian" has uploaded file with content "testshare content" to "/testshare/testshare.txt"
@@ -223,7 +223,7 @@ Feature: copy file
| 17 | | 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 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 space "Project" with the default quota using the GraphApi
And user "Brian" has shared a space "Project" with settings: And user "Brian" has shared a space "Project" with settings:
@@ -246,7 +246,7 @@ Feature: copy file
| editor | 17 | | 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 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 space "Project" with the default quota using the GraphApi
And user "Brian" has shared a space "Project" with settings: And user "Brian" has shared a space "Project" with settings:
@@ -266,7 +266,7 @@ Feature: copy file
| 17 | | 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" Given user "Brian" has created folder "/testshare1"
And user "Brian" has created folder "/testshare2" And user "Brian" has created folder "/testshare2"
And user "Brian" has uploaded file with content "testshare1 content" to "/testshare1/testshare1.txt" And user "Brian" has uploaded file with content "testshare1 content" to "/testshare1/testshare1.txt"
@@ -288,7 +288,7 @@ Feature: copy file
| 17 | | 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" Given user "Brian" has created folder "/testshare1"
And user "Brian" has created folder "/testshare2" And user "Brian" has created folder "/testshare2"
And user "Brian" has uploaded file with content "testshare1 content" to "/testshare1/testshare1.txt" And user "Brian" has uploaded file with content "testshare1 content" to "/testshare1/testshare1.txt"
@@ -308,7 +308,7 @@ Feature: copy file
| 17 | | 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 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 space "Project" with the default quota using the GraphApi
And user "Alice" has created a folder "/folder1" in space "Project" And user "Alice" has created a folder "/folder1" in space "Project"
@@ -328,7 +328,7 @@ Feature: copy file
| viewer | should not | 403 | | 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 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 "Project1" with the default quota using the GraphApi
And user "Brian" has created a space "Project2" 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 | | 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 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 space "Project" with the default quota using the GraphApi
And user "Brian" has created a folder "/folder1" in space "Project" And user "Brian" has created a folder "/folder1" in space "Project"
@@ -374,7 +374,7 @@ Feature: copy file
| viewer | | 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 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 space "Project" with the default quota using the GraphApi
And user "Brian" has created folder "/testshare" And user "Brian" has created folder "/testshare"
@@ -399,7 +399,7 @@ Feature: copy file
| viewer | should not | 17 | 403 | | 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 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 space "Project" with the default quota using the GraphApi
And user "Brian" has shared a space "Project" with settings: And user "Brian" has shared a space "Project" with settings:
@@ -418,7 +418,7 @@ Feature: copy file
| viewer | should not | 403 | | 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" Given user "Brian" has created folder "/testshare"
And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "<permissions>" And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "<permissions>"
And user "Alice" has accepted share "/testshare" offered by user "Brian" And user "Alice" has accepted share "/testshare" offered by user "Brian"
@@ -434,7 +434,7 @@ Feature: copy file
| 17 | should not | 403 | | 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 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 created folder "/testshare"
And user "Brian" has uploaded file with content "testshare content" to "/testshare/testshare.txt" And user "Brian" has uploaded file with content "testshare content" to "/testshare/testshare.txt"
@@ -451,7 +451,7 @@ Feature: copy file
| 17 | | 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 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 space "Project" with the default quota using the GraphApi
And user "Brian" has shared a space "Project" with settings: And user "Brian" has shared a space "Project" with settings:
@@ -474,7 +474,7 @@ Feature: copy file
| editor | 17 | | 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 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 space "Project" with the default quota using the GraphApi
And user "Brian" has shared a space "Project" with settings: And user "Brian" has shared a space "Project" with settings:
@@ -495,7 +495,7 @@ Feature: copy file
| 17 | | 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 Given using spaces DAV path
And user "Brian" has created folder "/testshare" And user "Brian" has created folder "/testshare"
And user "Brian" has created a share with settings 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" 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 Given using spaces DAV path
And user "Brian" has created folder "/testshare" And user "Brian" has created folder "/testshare"
And user "Brian" has uploaded file with content "ownCloud test text file 1" to "/testshare/overwritethis.txt" 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 | | 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 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 space "Project" with the default quota using the GraphApi
And user "Alice" has created a folder "/newfolder" in space "Project" 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" And for user "Alice" the content of the file "/newfolder/insideSpace (1).txt" of the space "Project" should be "new content"
@issue-4797 @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 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 space "Project" with the default quota using the GraphApi
And user "Alice" has created a folder "/newfolder" in space "Project" 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" 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 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 space "Project" with the default quota using the GraphApi
And user "Alice" has created a folder "/newfolder" in space "Project" And user "Alice" has created a folder "/newfolder" in space "Project"
@@ -790,7 +790,7 @@ Feature: copy file
| newfolder/personal (1).txt | | newfolder/personal (1).txt |
@issue-4797 @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 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 space "Project" with the default quota using the GraphApi
And user "Alice" has created a folder "/newfolder" in space "Project" And user "Alice" has created a folder "/newfolder" in space "Project"
tests/acceptance/features/apiSpacesShares/etagPropagation.feature
+141 -138
View File
@@ -1,5 +1,8 @@
@api @api
Feature: check etag propagation after different file alterations 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: Background:
Given these users have been created with default attributes and without skeleton files: 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 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" Then the HTTP status code should be "201"
And these etags should have changed And these etags should have changed
| user | path | space | | user | path | space |
| Alice | / | Personal | | Alice | / | Personal |
| Alice | /upload | Personal | | Alice | /upload | Personal |
| Alice | /upload/renamed.txt | Personal | | Alice | /upload/renamed.txt | Personal |
| Brian | / | Shares | | Brian | / | Shares |
| Brian | /upload | Shares | | Brian | /upload | Shares |
| Brian | /upload/renamed.txt | Shares | | Brian | /upload/renamed.txt | Shares |
And these etags should not have changed And these etags should not have changed
| user | path | space | | user | path | space |
| Alice | /upload/file.txt | Personal | | Alice | /upload/file.txt | Personal |
| Brian | /upload/file.txt | Shares | | Brian | /upload/file.txt | Shares |
Scenario: copying a file inside a folder as a sharer changes its etag for all collaborators 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 When user "Alice" copies file "/upload/file.txt" to "/upload/renamed.txt" using the WebDAV API
Then the HTTP status code should be "201" Then the HTTP status code should be "201"
And these etags should have changed And these etags should have changed
| user | path | space | | user | path | space |
| Alice | / | Personal | | Alice | / | Personal |
| Alice | /upload | Personal | | Alice | /upload | Personal |
| Alice | /upload/renamed.txt | Personal | | Alice | /upload/renamed.txt | Personal |
| Brian | / | Shares | | Brian | / | Shares |
| Brian | /upload | Shares | | Brian | /upload | Shares |
| Brian | /upload/renamed.txt | Shares | | Brian | /upload/renamed.txt | Shares |
And these etags should not have changed And these etags should not have changed
| user | path | space | | user | path | space |
| Alice | /upload/file.txt | Personal | | Alice | /upload/file.txt | Personal |
| Brian | /upload/file.txt | Shares | | 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" 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 "Alice" has shared folder "/upload" with user "Brian"
And user "Brian" has accepted share "/upload" offered by user "Alice" 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 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" Then the HTTP status code should be "201"
And these etags should have changed And these etags should have changed
| user | path | space | | user | path | space |
| Alice | / | Personal | | Alice | / | Personal |
| Alice | /upload | Personal | | Alice | /upload | Personal |
| Brian | / | Shares | | Brian | / | Shares |
| Brian | /upload | Shares | | Brian | /upload | Shares |
And these etags should not have changed And these etags should not have changed
| user | path | space | | user | path | space |
| Alice | /upload/renamed.txt | Personal | | Alice | /upload/renamed.txt | Personal |
| Brian | /upload/renamed.txt | Shares | | 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" 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 "Alice" has shared folder "/upload" with user "Brian"
And user "Brian" has accepted share "/upload" offered by user "Alice" 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 When user "Alice" moves file "/upload/file.txt" to "/upload/renamed.txt" using the WebDAV API
Then the HTTP status code should be "201" Then the HTTP status code should be "201"
And these etags should have changed And these etags should have changed
| user | path | space | | user | path | space |
| Alice | / | Personal | | Alice | / | Personal |
| Alice | /upload | Personal | | Alice | /upload | Personal |
| Brian | / | Shares | | Brian | / | Shares |
| Brian | /upload | Shares | | Brian | /upload | Shares |
And these etags should not have changed And these etags should not have changed
| user | path | space | | user | path | space |
| Alice | /upload/renamed.txt | Personal | | Alice | /upload/renamed.txt | Personal |
| Brian | /upload/renamed.txt | Shares | | 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" 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 uploaded file with content "uploaded content" to "/upload/file.txt"
And user "Alice" has shared folder "/upload" with user "Brian" 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 When user "Alice" moves file "/upload/file.txt" to "/dst/file.txt" using the WebDAV API
Then the HTTP status code should be "201" Then the HTTP status code should be "201"
And these etags should have changed And these etags should have changed
| user | path | space | | user | path | space |
| Alice | / | Personal | | Alice | / | Personal |
| Alice | /upload | Personal | | Alice | /upload | Personal |
| Alice | /dst | Personal | | Alice | /dst | Personal |
| Brian | / | Shares | | Brian | / | Shares |
| Brian | /upload | Shares | | Brian | /upload | Shares |
| Brian | /dst | 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" 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 uploaded file with content "uploaded content" to "/upload/file.txt"
And user "Alice" has shared folder "/upload" with user "Brian" 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 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" Then the HTTP status code should be "201"
And these etags should have changed And these etags should have changed
| user | path | space | | user | path | space |
| Alice | / | Personal | | Alice | / | Personal |
| Alice | /upload | Personal | | Alice | /upload | Personal |
| Alice | /dst | Personal | | Alice | /dst | Personal |
| Brian | / | Shares | | Brian | / | Shares |
| Brian | /upload | Shares | | Brian | /upload | Shares |
| Brian | /dst | 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" Given user "Alice" has created folder "/dst"
And user "Alice" has created folder "/upload/toMove" And user "Alice" has created folder "/upload/toMove"
And user "Alice" has shared folder "/upload" with user "Brian" 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 When user "Alice" moves file "/upload/toMove" to "/dst/toMove" using the WebDAV API
Then the HTTP status code should be "201" Then the HTTP status code should be "201"
And these etags should have changed And these etags should have changed
| user | path | space | | user | path | space |
| Alice | / | Personal | | Alice | / | Personal |
| Alice | /upload | Personal | | Alice | /upload | Personal |
| Alice | /dst | Personal | | Alice | /dst | Personal |
| Brian | / | Shares | | Brian | / | Shares |
| Brian | /upload | Shares | | Brian | /upload | Shares |
| Brian | /dst | 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" Given user "Alice" has created folder "/dst"
And user "Alice" has created folder "/upload/toMove" And user "Alice" has created folder "/upload/toMove"
And user "Alice" has shared folder "/upload" with user "Brian" 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 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" Then the HTTP status code should be "201"
And these etags should have changed And these etags should have changed
| user | path | space | | user | path | space |
| Alice | / | Personal | | Alice | / | Personal |
| Alice | /upload | Personal | | Alice | /upload | Personal |
| Alice | /dst | Personal | | Alice | /dst | Personal |
| Brian | / | Shares | | Brian | / | Shares |
| Brian | /upload | Shares | | Brian | /upload | Shares |
| Brian | /dst | 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" Given user "Alice" has shared folder "/upload" with user "Brian"
And user "Brian" has accepted share "/upload" offered by user "Alice" And user "Brian" has accepted share "/upload" offered by user "Alice"
And user "Alice" has stored etag of element "/" inside space "Personal" 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 When user "Brian" creates a subfolder "/upload/new" in space "Shares" using the WebDav Api
Then the HTTP status code should be "201" Then the HTTP status code should be "201"
And these etags should have changed And these etags should have changed
| user | path | space | | user | path | space |
| Alice | / | Personal | | Alice | / | Personal |
| Alice | /upload | Personal | | Alice | /upload | Personal |
| Brian | / | Shares | | Brian | / | Shares |
| Brian | /upload | 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" Given user "Alice" has shared folder "/upload" with user "Brian"
And user "Brian" has accepted share "/upload" offered by user "Alice" And user "Brian" has accepted share "/upload" offered by user "Alice"
And user "Alice" has stored etag of element "/" inside space "Personal" 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 When user "Alice" creates folder "/upload/new" using the WebDAV API
Then the HTTP status code should be "201" Then the HTTP status code should be "201"
And these etags should have changed And these etags should have changed
| user | path | space | | user | path | space |
| Alice | / | Personal | | Alice | / | Personal |
| Alice | /upload | Personal | | Alice | /upload | Personal |
| Brian | / | Shares | | Brian | / | Shares |
| Brian | /upload | 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" Given user "Alice" has shared folder "/upload" with user "Brian"
And user "Brian" has accepted share "/upload" offered by user "Alice" And user "Brian" has accepted share "/upload" offered by user "Alice"
And user "Alice" has stored etag of element "/" inside space "Personal" 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 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" Then the HTTP status code should be "201"
And these etags should have changed And these etags should have changed
| user | path | space | | user | path | space |
| Alice | / | Personal | | Alice | / | Personal |
| Alice | /upload | Personal | | Alice | /upload | Personal |
| Brian | / | Shares | | Brian | / | Shares |
| Brian | /upload | 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" Given user "Alice" has shared folder "/upload" with user "Brian"
And user "Brian" has accepted share "/upload" offered by user "Alice" And user "Brian" has accepted share "/upload" offered by user "Alice"
And user "Alice" has stored etag of element "/" inside space "Personal" 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 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" Then the HTTP status code should be "201"
And these etags should have changed And these etags should have changed
| user | path | space | | user | path | space |
| Alice | / | Personal | | Alice | / | Personal |
| Alice | /upload | Personal | | Alice | /upload | Personal |
| Brian | / | Shares | | Brian | / | Shares |
| Brian | /upload | 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" 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 "Alice" has shared folder "/upload" with user "Brian"
And user "Brian" has accepted share "/upload" offered by user "Alice" 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 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" Then the HTTP status code should be "204"
And these etags should have changed And these etags should have changed
| user | path | space | | user | path | space |
| Alice | / | Personal | | Alice | / | Personal |
| Alice | /upload | Personal | | Alice | /upload | Personal |
| Brian | / | Shares | | Brian | / | Shares |
| Brian | /upload | 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" 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 "Alice" has shared folder "/upload" with user "Brian"
And user "Brian" has accepted share "/upload" offered by user "Alice" 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 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" Then the HTTP status code should be "204"
And these etags should have changed And these etags should have changed
| user | path | space | | user | path | space |
| Alice | / | Personal | | Alice | / | Personal |
| Alice | /upload | Personal | | Alice | /upload | Personal |
| Brian | / | Shares | | Brian | / | Shares |
| Brian | /upload | 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" 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 uploaded file with content "uploaded content" to "/upload/sub/file.txt"
And user "Alice" has shared folder "/upload" with user "Brian" 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" When user "Brian" removes the file "upload/sub/file.txt" from space "Shares"
Then the HTTP status code should be "204" Then the HTTP status code should be "204"
And these etags should have changed And these etags should have changed
| user | path | space | | user | path | space |
| Alice | / | Personal | | Alice | / | Personal |
| Alice | /upload | Personal | | Alice | /upload | Personal |
| Alice | /upload/sub | Personal | | Alice | /upload/sub | Personal |
| Brian | / | Shares | | Brian | / | Shares |
| Brian | /upload | Shares | | Brian | /upload | Shares |
| Brian | /upload/sub | Shares | | Brian | /upload/sub | Shares |
And these etags should not have changed And these etags should not have changed
| user | path | space | | user | path | space |
| Brian | / | Personal | | 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" 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 uploaded file with content "uploaded content" to "/upload/sub/file.txt"
And user "Alice" has shared folder "/upload" with user "Brian" 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" When user "Alice" removes the file "upload/sub/file.txt" from space "Personal"
Then the HTTP status code should be "204" Then the HTTP status code should be "204"
And these etags should have changed And these etags should have changed
| user | path | space | | user | path | space |
| Alice | / | Personal | | Alice | / | Personal |
| Alice | /upload | Personal | | Alice | /upload | Personal |
| Alice | /upload/sub | Personal | | Alice | /upload/sub | Personal |
| Brian | / | Shares | | Brian | / | Shares |
| Brian | /upload | Shares | | Brian | /upload | Shares |
| Brian | /upload/sub | Shares | | Brian | /upload/sub | Shares |
And these etags should not have changed And these etags should not have changed
| user | path | space | | user | path | space |
| Brian | / | Personal | | 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" Given user "Alice" has created folder "/upload/sub"
And user "Alice" has created folder "/upload/sub/toDelete" And user "Alice" has created folder "/upload/sub/toDelete"
And user "Alice" has shared folder "/upload" with user "Brian" 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" When user "Brian" removes the file "upload/sub/toDelete" from space "Shares"
Then the HTTP status code should be "204" Then the HTTP status code should be "204"
And these etags should have changed And these etags should have changed
| user | path | space | | user | path | space |
| Alice | / | Personal | | Alice | / | Personal |
| Alice | /upload | Personal | | Alice | /upload | Personal |
| Alice | /upload/sub | Personal | | Alice | /upload/sub | Personal |
| Brian | / | Shares | | Brian | / | Shares |
| Brian | /upload | Shares | | Brian | /upload | Shares |
| Brian | /upload/sub | Shares | | Brian | /upload/sub | Shares |
And these etags should not have changed And these etags should not have changed
| user | path | space | | user | path | space |
| Brian | / | Personal | | 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" Given user "Alice" has created folder "/upload/sub"
And user "Alice" has created folder "/upload/sub/toDelete" And user "Alice" has created folder "/upload/sub/toDelete"
And user "Alice" has shared folder "/upload" with user "Brian" 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" When user "Alice" removes the file "upload/sub/toDelete" from space "Personal"
Then the HTTP status code should be "204" Then the HTTP status code should be "204"
And these etags should have changed And these etags should have changed
| user | path | space | | user | path | space |
| Alice | / | Personal | | Alice | / | Personal |
| Alice | /upload | Personal | | Alice | /upload | Personal |
| Alice | /upload/sub | Personal | | Alice | /upload/sub | Personal |
| Brian | / | Shares | | Brian | / | Shares |
| Brian | /upload | Shares | | Brian | /upload | Shares |
| Brian | /upload/sub | Shares | | Brian | /upload/sub | Shares |
And these etags should not have changed And these etags should not have changed
| user | path | space | | user | path | space |
| Brian | / | Personal | | Brian | / | Personal |
tests/acceptance/features/apiSpacesShares/favorite.feature
+3
View File
@@ -1,5 +1,8 @@
@api @skipOnOcV10 @api @skipOnOcV10
Feature: favorite Feature: favorite
As a user
I want to favouite resources
So that I can acesses them quickly
Background: Background:
Given these users have been created with default attributes and without skeleton files: Given these users have been created with default attributes and without skeleton files:
tests/acceptance/features/apiSpacesShares/moveSpaces.feature
+16 -16
View File
@@ -12,7 +12,7 @@ Feature: move (rename) file
And using spaces DAV path 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 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 space "Project" with the default quota using the GraphApi
And user "Brian" has created a folder "newfolder" in space "Project" And user "Brian" has created a folder "newfolder" in space "Project"
@@ -32,7 +32,7 @@ Feature: move (rename) file
| editor | | 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 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 space "Project" with the default quota using the GraphApi
And user "Brian" has created a folder "newfolder" in space "Project" And user "Brian" has created a folder "newfolder" in space "Project"
@@ -48,7 +48,7 @@ Feature: move (rename) file
| insideSpace.txt | | 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 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 "Project1" with the default quota using the GraphApi
And user "Brian" has created a space "Project2" 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 | | 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 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 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" 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 | | 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 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 space "Project" with the default quota using the GraphApi
And user "Brian" has created folder "/testshare" And user "Brian" has created folder "/testshare"
@@ -124,7 +124,7 @@ Feature: move (rename) file
| viewer | 17 | | 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 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 space "Project" with the default quota using the GraphApi
And user "Brian" has shared a space "Project" with settings: And user "Brian" has shared a space "Project" with settings:
@@ -144,7 +144,7 @@ Feature: move (rename) file
| viewer | 403 | | 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" Given user "Brian" has created folder "/testshare"
And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "<permissions>" And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "<permissions>"
And user "Alice" has accepted share "/testshare" offered by user "Brian" And user "Alice" has accepted share "/testshare" offered by user "Brian"
@@ -162,7 +162,7 @@ Feature: move (rename) file
| 1 | | 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" 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 uploaded file with content "testshare content" to "/testshare/testshare.txt"
And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "<permissions>" And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "<permissions>"
@@ -180,7 +180,7 @@ Feature: move (rename) file
| 1 | | 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 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 space "Project" with the default quota using the GraphApi
And user "Brian" has shared a space "Project" with settings: And user "Brian" has shared a space "Project" with settings:
@@ -206,7 +206,7 @@ Feature: move (rename) file
| viewer | 17 | | 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" Given user "Brian" has created folder "/testshare1"
And user "Brian" has created folder "/testshare2" And user "Brian" has created folder "/testshare2"
And user "Brian" has uploaded file with content "testshare1 content" to "/testshare1/testshare1.txt" 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 | | /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" Given user "Brian" has created folder "/testshare1"
And user "Brian" has created folder "/testshare2" And user "Brian" has created folder "/testshare2"
And user "Brian" has uploaded file with content "testshare1 content" to "/testshare1/testshare1.txt" 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 | | /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" Given user "Brian" has created folder "/testshare1"
And user "Brian" has created folder "/testshare2" And user "Brian" has created folder "/testshare2"
And user "Brian" has uploaded file with content "testshare1 content" to "/testshare1/testshare1.txt" 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 | | /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 Given user "Alice" has created the following folders
| path | | path |
| /folderA | | /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 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" 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 uploaded file with content "test data" to "/testshare/testfile.txt"
And user "Brian" has created a share with settings And user "Brian" has created a share with settings
@@ -298,7 +298,7 @@ Feature: move (rename) file
| /testshare/testfile.txt | | /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 Given user "Brian" has created the following folders
| path | | path |
| /testshare | | /testshare |
@@ -319,7 +319,7 @@ Feature: move (rename) file
| /testshare/testsubfolder | | /testshare/testsubfolder |
@issue-4797 @issue-4797
Scenario: Overwriting a file while moving Scenario: overwriting a file while moving
Given user "Brian" has created folder "/folder" 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 1" to "/folder/testfile.txt"
And user "Brian" has uploaded file with content "old content version 2" to "/folder/testfile.txt" And user "Brian" has uploaded file with content "old content version 2" to "/folder/testfile.txt"
tests/acceptance/features/apiSpacesShares/shareOperations.feature
+43 -40
View File
@@ -1,5 +1,8 @@
@api @skipOnOcV10 @api @skipOnOcV10
Feature: sharing Feature: sharing
As a user
I want to share resources with different permissions
So that I can manage the access to the resource
Background: Background:
Given using OCS API version "1" Given using OCS API version "1"
@@ -10,7 +13,7 @@ Feature: sharing
And using spaces DAV path 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" 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 "Alice" has shared file "/tmp.txt" with user "Brian"
And user "Brian" has accepted share "/tmp.txt" offered by user "Alice" 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" 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 Given group "grp1" has been created
And user "Brian" has been added to group "grp1" And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file with content "foo" to "/tmp.txt" 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" 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" 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 "Alice" has shared file "tmp.txt" with user "Brian"
And user "Brian" has accepted share "/tmp.txt" offered by user "Alice" 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" 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 Given group "grp1" has been created
And user "Brian" has been added to group "grp1" And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file with content "foo" to "/tmp.txt" 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" 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" 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 "Alice" has shared file "tmp.txt" with user "Brian"
And user "Brian" has accepted share "/tmp.txt" offered by user "Alice" 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" 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 Given group "grp1" has been created
And user "Brian" has been added to group "grp1" And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file with content "foo" to "/tmp.txt" 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" 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" Given user "Alice" has created folder "/tmp"
And user "Alice" has shared file "/tmp" with user "Brian" And user "Alice" has shared file "/tmp" with user "Brian"
And user "Brian" has accepted share "/tmp" offered by user "Alice" 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" 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 Given group "grp1" has been created
And user "Brian" has been added to group "grp1" And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "/tmp" 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" 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" Given user "Alice" has created folder "/tmp"
And user "Alice" has shared file "/tmp" with user "Brian" And user "Alice" has shared file "/tmp" with user "Brian"
And user "Brian" has accepted share "/tmp" offered by user "Alice" 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" 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 Given group "grp1" has been created
And user "Brian" has been added to group "grp1" And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "/tmp" And user "Alice" has created folder "/tmp"
@@ -139,24 +142,24 @@ Feature: sharing
| shareWith | grp1 | | shareWith | grp1 |
| permissions | share,delete,create,read | | permissions | share,delete,create,read |
And user "Brian" has accepted share "/tmp" offered by user "Alice" 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 | | propertyName |
| ocs:share-permissions | | ocs:share-permissions |
Then the HTTP status code should be "200" Then the HTTP status code should be "200"
And the single response should contain a property "ocs:share-permissions" with value "29" 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" Given user "Alice" has created folder "/tmp"
And user "Alice" has shared file "/tmp" with user "Brian" And user "Alice" has shared file "/tmp" with user "Brian"
And user "Brian" has accepted share "/tmp" offered by user "Alice" And user "Brian" has accepted share "/tmp" offered by user "Alice"
When user "Alice" updates the last share using the sharing API with When user "Alice" updates the last share using the sharing API with
| permissions | share,delete,update,read | | permissions | share,delete,update,read |
Then the HTTP status code should be "200" 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 Given group "grp1" has been created
And user "Brian" has been added to group "grp1" And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "/tmp" 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" 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" Given user "Alice" has created folder "/tmp"
And user "Alice" has shared file "/tmp" with user "Brian" And user "Alice" has shared file "/tmp" with user "Brian"
And user "Brian" has accepted share "/tmp" offered by user "Alice" 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" 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 Given group "grp1" has been created
And user "Brian" has been added to group "grp1" And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "/tmp" 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" 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" Given user "Alice" has created folder "/tmp"
And user "Alice" has shared file "/tmp" with user "Brian" And user "Alice" has shared file "/tmp" with user "Brian"
And user "Brian" has accepted share "/tmp" offered by user "Alice" 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" 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 Given group "grp1" has been created
And user "Brian" has been added to group "grp1" And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "/tmp" 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" 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 Given group "grp1" has been created
And user "Brian" has been added to group "grp1" And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "FOLDER" And user "Alice" has created folder "FOLDER"
@@ -242,7 +245,7 @@ Feature: sharing
And as "Alice" file "/FOLDER/textfile.txt" should not exist 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" Given user "Alice" has created folder "FOLDER"
And user "Alice" has created a share with settings And user "Alice" has created a share with settings
| path | FOLDER | | path | FOLDER |
@@ -255,12 +258,12 @@ Feature: sharing
And the following headers should match these regular expressions for user "Brian" And the following headers should match these regular expressions for user "Brian"
| ETag | /^"[a-f0-9:\.]{1,32}"$/ | | ETag | /^"[a-f0-9:\.]{1,32}"$/ |
And the content of file "/FOLDER/textfile.txt" for user "Alice" should be: 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 Given group "grp1" has been created
And user "Brian" has been added to group "grp1" And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "FOLDER" 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" And the following headers should match these regular expressions for user "Brian"
| ETag | /^"[a-f0-9:\.]{1,32}"$/ | | ETag | /^"[a-f0-9:\.]{1,32}"$/ |
And the content of file "/FOLDER/textfile.txt" for user "Alice" should be: 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" Given user "Alice" has created folder "FOLDER"
And user "Alice" has created a share with settings And user "Alice" has created a share with settings
| path | FOLDER | | 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 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" Then the HTTP status code should be "201"
And the content of file "/FOLDER/textfile.txt" for user "Alice" should be: 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 Given group "grp1" has been created
And user "Brian" has been added to group "grp1" And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "FOLDER" 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 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" Then the HTTP status code should be "201"
And the content of file "/FOLDER/textfile.txt" for user "Alice" should be: 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" Given user "Alice" has created folder "FOLDER"
And user "Alice" has created a share with settings And user "Alice" has created a share with settings
| path | FOLDER | | path | FOLDER |
@@ -328,7 +331,7 @@ Feature: sharing
And as "Alice" file "/FOLDER/textfile.txt" should not exist 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" Given user "Alice" has created folder "FOLDER"
And user "Alice" has created a share with settings And user "Alice" has created a share with settings
| path | FOLDER | | path | FOLDER |
@@ -342,7 +345,7 @@ Feature: sharing
And as "Alice" file "/FOLDER/textfile.txt" should not exist 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 Given group "grp1" has been created
And user "Brian" has been added to group "grp1" And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "FOLDER" And user "Alice" has created folder "FOLDER"
@@ -358,7 +361,7 @@ Feature: sharing
And as "Alice" file "/FOLDER/textfile.txt" should not exist 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" Given user "Alice" has created folder "FOLDER"
And user "Alice" has created a share with settings And user "Alice" has created a share with settings
| path | FOLDER | | path | FOLDER |
@@ -370,7 +373,7 @@ Feature: sharing
And user "Alice" downloads file "/FOLDER/textfile.txt" using the WebDAV API And user "Alice" downloads file "/FOLDER/textfile.txt" using the WebDAV API
Then the HTTP status code should be "200" Then the HTTP status code should be "200"
And the downloaded content should be "some content" And the downloaded content should be "some content"
Examples: Examples:
| permissions | | permissions |
| change | | change |
| create | | create |
tests/acceptance/features/apiSpacesShares/shareSpaces.feature
+25 -24
View File
@@ -2,6 +2,7 @@
Feature: Share spaces Feature: Share spaces
As the owner of a space As the owner of a space
I want to be able to add members to a space, and to remove access for them 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 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 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 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: When user "Alice" shares a space "share space" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | <role> | | role | <role> |
@@ -26,7 +27,7 @@ Feature: Share spaces
And the OCS status message should be "OK" And the OCS status message should be "OK"
And for user "Brian" the JSON response should contain space called "share space" and match And for user "Brian" the JSON response should contain space called "share space" and match
""" """
{ {
"type": "object", "type": "object",
"required": [ "required": [
"name", "name",
@@ -56,14 +57,14 @@ Feature: Share spaces
| viewer | | 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: When user "Alice" shares a space "share space" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | viewer | | role | viewer |
Then the user "Alice" should have a space called "share space" granted to user "Brian" with role "viewer" Then the user "Alice" should have a space called "share space" granted to user "Brian" with role "viewer"
@skipOnStable2.0 @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 Given group "sales" has been created
When user "Alice" shares a space "share space" with settings: When user "Alice" shares a space "share space" with settings:
| shareWith | sales | | 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" 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" 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" And user "Alice" has created a folder "Folder Main" in space "share space"
When user "Alice" shares a space "share space" with settings: When user "Alice" shares a space "share space" with settings:
@@ -85,7 +86,7 @@ Feature: Share spaces
| Folder Main | | 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: Given user "Alice" has shared a space "share space" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | viewer | | role | viewer |
@@ -119,7 +120,7 @@ Feature: Share spaces
But the user "Brian" should not have a space called "share space" 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: Given user "Alice" has shared a space "share space" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | manager | | role | manager |
@@ -127,7 +128,7 @@ Feature: Share spaces
Then the HTTP status code should be "200" 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 And for user "Brian" the JSON response should contain space called "share space" owned by "Alice" and match
""" """
{ {
"type": "object", "type": "object",
"required": [ "required": [
"name", "name",
@@ -157,7 +158,7 @@ Feature: Share spaces
| Brian | | 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" 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: When user "Alice" shares a space "share space" with settings:
| shareWith | Brian | | shareWith | Brian |
@@ -171,7 +172,7 @@ Feature: Share spaces
| test.txt | | 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" Given user "Alice" has disabled a space "share space"
When user "Alice" shares a space "share space" with settings: When user "Alice" shares a space "share space" with settings:
| shareWith | Brian | | shareWith | Brian |
@@ -187,7 +188,7 @@ Feature: Share spaces
| viewer | | 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: Given user "Alice" has shared a space "share space" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | manager | | role | manager |
@@ -199,7 +200,7 @@ Feature: Share spaces
And the OCS status message should be "OK" And the OCS status message should be "OK"
And for user "Brian" the JSON response should contain space called "share space" and match And for user "Brian" the JSON response should contain space called "share space" and match
""" """
{ {
"type": "object", "type": "object",
"required": [ "required": [
"name", "name",
@@ -229,7 +230,7 @@ Feature: Share spaces
| viewer | | 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: Given user "Alice" has shared a space "share space" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | <role> | | role | <role> |
@@ -291,7 +292,7 @@ Feature: Share spaces
| viewer | editor | | viewer | editor |
@skipOnStable2.0 @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 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 "Brian" to the group "group2" using GraphApi
And the administrator has added a user "Bob" 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" Then the HTTP status code should be "200"
And for user "Brian" the JSON response should contain space called "share space" and match And for user "Brian" the JSON response should contain space called "share space" and match
""" """
{ {
"type": "object", "type": "object",
"required": [ "required": [
"name", "name",
@@ -327,7 +328,7 @@ Feature: Share spaces
""" """
And for user "Bob" the JSON response should contain space called "share space" and match And for user "Bob" the JSON response should contain space called "share space" and match
""" """
{ {
"type": "object", "type": "object",
"required": [ "required": [
"name", "name",
@@ -357,7 +358,7 @@ Feature: Share spaces
| viewer | | viewer |
@skipOnStable2.0 @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 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 "Brian" to the group "group2" using GraphApi
And user "Alice" has shared a space "share space" with settings: And user "Alice" has shared a space "share space" with settings:
@@ -374,7 +375,7 @@ Feature: Share spaces
| viewer | | viewer |
@skipOnStable2.0 @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 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 "Brian" to the group "group2" using GraphApi
And the administrator has added a user "Bob" 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" 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 But for user "Bob" the JSON response should contain space called "share space" and match
""" """
{ {
"type": "object", "type": "object",
"required": [ "required": [
"name", "name",
@@ -414,7 +415,7 @@ Feature: Share spaces
""" """
@skipOnStable2.0 @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 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 "Brian" to the group "group2" using GraphApi
And the administrator has added a user "Bob" 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" And the user "Brian" should not have a space called "share space"
@skipOnStable2.0 @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 Given group "sales" has been created
And the administrator has added a user "Brian" to the group "sales" using GraphApi 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: 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" Then the HTTP status code should be "201"
@skipOnStable2.0 @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 Given group "sales" has been created
And the administrator has added a user "Brian" to the group "sales" using GraphApi 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: 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" Then the HTTP status code should be "201"
@skipOnStable2.0 @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: When user "Alice" shares a space "share space" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | <role> | | role | <role> |
@@ -476,7 +477,7 @@ Feature: Share spaces
| viewer | | 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 Given group "sales" has been created
And the administrator has added a user "Brian" to the group "sales" using GraphApi And the administrator has added a user "Brian" to the group "sales" using GraphApi
When user "Alice" shares a space "share space" with settings: When user "Alice" shares a space "share space" with settings:
tests/acceptance/features/apiSpacesShares/shareSpacesViaLink.feature
+6 -5
View File
@@ -2,6 +2,7 @@
Feature: Share spaces via link Feature: Share spaces via link
As the manager of a space As the manager of a space
I want to be able to share a space via public link 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 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 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" 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: When user "Alice" creates a public link share of the space "share space" with settings:
| permissions | <permissions> | | permissions | <permissions> |
| password | <password> | | password | <password> |
@@ -46,7 +47,7 @@ Feature: Share spaces via link
| 15 | read,update,create,delete | d*V^o*Y03R9n8Z | 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: When user "Alice" creates a public link share of the space "share space" with settings:
| permissions | 4 | | permissions | 4 |
| password | 123 | | password | 123 |
@@ -70,7 +71,7 @@ Feature: Share spaces via link
| lorem.txt | | 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: Given user "Alice" has shared a space "share space" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | <role> | | role | <role> |
@@ -86,7 +87,7 @@ Feature: Share spaces via link
| editor | | 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: Given user "Alice" has shared a space "share space" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | manager | | 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 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" Given user "Alice" has disabled a space "share space"
When user "Alice" creates a public link share of the space "share space" with settings: When user "Alice" creates a public link share of the space "share space" with settings:
| permissions | 1 | | permissions | 1 |
tests/acceptance/features/apiSpacesShares/shareSubItemOfSpace.feature
+8 -8
View File
@@ -2,7 +2,7 @@
Feature: Share a file or folder that is inside a space Feature: Share a file or folder that is inside a space
As an user with manager space role As an user with manager space role
I want to be able to share the data inside the space 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 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 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 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: And user "Alice" creates a share inside of space "share sub-item" with settings:
| path | <entity> | | path | <entity> |
| shareWith | Brian | | 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 | | 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: Given user "Alice" has shared a space "share sub-item" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | manager | | role | manager |
@@ -66,7 +66,7 @@ Feature: Share a file or folder that is inside a space
| file.txt | file | editor | | | | 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: Given user "Alice" has shared a space "share sub-item" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | <spaceRole> | | role | <spaceRole> |
@@ -85,7 +85,7 @@ Feature: Share a file or folder that is inside a space
| folder | viewer | 404 | No share permission | | 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: Given user "Alice" has shared a space "share sub-item" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | <spaceRole> | | role | <spaceRole> |
@@ -102,7 +102,7 @@ Feature: Share a file or folder that is inside a space
| manager | | manager |
Scenario: A user shares the folder to the group Scenario: user shares the folder to the group
Given group "sales" has been created Given group "sales" has been created
And the administrator has added a user "Brian" to the group "sales" using GraphApi 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: 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 | | expiration | 2042-01-01 |
@skipOnStable2.0 @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: Given user "Alice" has created a share inside of space "share sub-item" with settings:
| path | folder | | path | folder |
| shareWith | Brian | | shareWith | Brian |
@@ -134,7 +134,7 @@ Feature: Share a file or folder that is inside a space
| expiration | 2044-01-01 | | 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: Given user "Alice" has created a share inside of space "share sub-item" with settings:
| path | folder | | path | folder |
| shareWith | Brian | | shareWith | Brian |
tests/acceptance/features/apiSpacesShares/shareSubItemOfSpaceViaPublicLink.feature
+20 -19
View File
@@ -1,21 +1,22 @@
@api @skipOnOcV10 @api @skipOnOcV10
Feature: Share a file or folder that is inside a space via public link Feature: Share a file or folder that is inside a space via public link
As an user with manager space role As an user with manager space role
I want to be able to share the data inside the space via public link 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: folder permissions:
| role | permissions | | role | permissions |
| internal | 0 | | internal | 0 |
| viewer | 1 | | viewer | 1 |
| uploader | 4 | | uploader | 4 |
| contributor | 5 | | contributor | 5 |
| editor | 15 | | editor | 15 |
file permissions: file permissions:
| role | permissions | | role | permissions |
| internal | 0 | | internal | 0 |
| viewer | 1 | | viewer | 1 |
| editor | 3 | | editor | 3 |
Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production 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 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" And user "Alice" has uploaded a file inside space "share sub-item" with content "some content" to "folder/file.txt"
@issue-5139 @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: When user "Alice" creates a public link share inside of space "share sub-item" with settings:
| path | <entity> | | path | <entity> |
| shareType | 3 | | 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 | | folder/file.txt | /file.txt | 3 | 123 | link | 2042-03-25T23:59:59+0100 | file | text/plain |
@issue-5139 @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: Given user "Alice" has shared a space "share sub-item" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | manager | | 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 | | 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: Given user "Alice" has shared a space "share sub-item" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | <spaceRole> | | role | <spaceRole> |
@@ -114,7 +115,7 @@ Feature: Share a file or folder that is inside a space via public link
| folder/file.txt | viewer | | 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>" Given using OCS API version "<ocs_api_version>"
And user "Alice" has uploaded file with content "Random data" to "/file.txt" 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 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 | | 2 | 200 |
@issue-5139 @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: Given user "Alice" has shared a space "share sub-item" with settings:
| shareWith | Brian | | shareWith | Brian |
| role | <spaceRole> | | role | <spaceRole> |
tests/acceptance/features/apiSpacesShares/shareUploadTUS.feature
+15 -15
View File
@@ -78,7 +78,7 @@ Feature: upload resources on share using TUS protocol
| nonExistentFolder/file.txt | | 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" Given user "Alice" has created folder "/toShare"
And user "Alice" has shared folder "/toShare" with user "Brian" And user "Alice" has shared folder "/toShare" with user "Brian"
And user "Brian" has accepted share "/toShare" offered by user "Alice" 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" 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" Given user "Alice" has created folder "/toShare"
And user "Alice" has shared folder "/toShare" with user "Brian" with permissions "change" And user "Alice" has shared folder "/toShare" with user "Brian" with permissions "change"
And user "Brian" has accepted share "/toShare" offered by user "Alice" 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" 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 Given group "grp1" has been created
And user "Brian" has been added to group "grp1" And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "/toShare" 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" 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" 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 uploaded file with content "original content" to "/toShare/file.txt"
And user "Alice" has shared folder "/toShare" with user "Brian" And user "Alice" has shared folder "/toShare" with user "Brian"
@@ -130,7 +130,7 @@ Feature: upload resources on share using TUS protocol
| file.txt | | 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" Given user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian" And user "Alice" has shared folder "/FOLDER" with user "Brian"
And user "Brian" has accepted share "/FOLDER" offered by user "Alice" 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" 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" Given user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian" And user "Alice" has shared folder "/FOLDER" with user "Brian"
And user "Brian" has accepted share "/FOLDER" offered by user "Alice" 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" 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: 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 | | Upload-Length | 5 |
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt # 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" 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: 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 | | Upload-Length | 5 |
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt # 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" 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" Given user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian" And user "Alice" has shared folder "/FOLDER" with user "Brian"
And user "Brian" has accepted share "/FOLDER" offered by user "Alice" 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" And for user "Alice" the content of the file "FOLDER/textFile.txt" of the space "Personal" should be "uploaded content"
@issue-1755 @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" Given user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian" And user "Alice" has shared folder "/FOLDER" with user "Brian"
And user "Brian" has accepted share "/FOLDER" offered by user "Alice" 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 | | textFile.txt |
@issue-1755 @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" Given user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian" And user "Alice" has shared folder "/FOLDER" with user "Brian"
And user "Brian" has accepted share "/FOLDER" offered by user "Alice" 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 | | 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: 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 | | Upload-Length | 10 |
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt # 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" 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" Given user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian" And user "Alice" has shared folder "/FOLDER" with user "Brian"
And user "Brian" has accepted share "/FOLDER" offered by user "Alice" 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" 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: 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 | | Upload-Length | 16 |
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt # 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" And for user "Alice" the content of the file "/textFile.txt" of the space "Personal" should be "overwritten content"
@issue-1755 @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: 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 | | Upload-Length | 16 |
# dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt
tests/acceptance/features/bootstrap/GraphContext.php
+1 -1
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 $user
* @param string $firstGroup * @param string $firstGroup