sevenhill/QSfera
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Used kebab case for example table header name

Browse Source
This commit is contained in:
Prarup Gurung
2024-03-21 10:04:25 +05:45
parent 84a14c5953
commit fcba2d34a4
26 changed files with 918 additions and 918 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tests/acceptance/features/apiSpaces/changeSpaces.feature
+44 -44
View File
@@ -106,7 +106,7 @@ Feature: Change data of space
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 "<quota-value>"
Then the HTTP status code should be "200"
And the JSON data of the response should match
"""
@@ -142,9 +142,9 @@ Feature: Change data of space
}
"""
Examples:
| quotaValue |
| 0 |
| -1 |
| quota-value |
| 0 |
| -1 |
Scenario: user space admin set readme file as description of the space via the Graph API
@@ -234,20 +234,20 @@ Feature: Change data of space
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
When user "<user>" uploads a file inside space "Project Jupiter" with content "new description" to ".space/readme.md" using the WebDAV API
Then the HTTP status code should be "<code>"
Then the HTTP status code should be "<http-status-code>"
And for user "<user>" the content of the file ".space/readme.md" of the space "Project Jupiter" should be "<content>"
Examples:
| user | code | content |
| Brian | 204 | new description |
| Bob | 403 | space description |
| user | http-status-code | content |
| Brian | 204 | new description |
| Bob | 403 | space description |
Scenario Outline: user space admin and editor set image file as space image of the space via the Graph API
Given user "Alice" has created a folder ".space" in space "Project Jupiter"
And user "<user>" has uploaded a file inside space "Project Jupiter" with content "" to ".space/<fileName>"
When user "<user>" sets the file ".space/<fileName>" as a space image in a special section of the "Project Jupiter" space
And user "<user>" has uploaded a file inside space "Project Jupiter" with content "" to ".space/<file-name>"
When user "<user>" sets the file ".space/<file-name>" as a space image in a special section of the "Project Jupiter" space
Then the HTTP status code should be "200"
And the JSON response should contain space called "Project Jupiter" owned by "Alice" with description file ".space/<fileName>" and match
And the JSON response should contain space called "Project Jupiter" owned by "Alice" with description file ".space/<file-name>" and match
"""
{
"type": "object",
@@ -281,7 +281,7 @@ Feature: Change data of space
},
"name": {
"type": "string",
"enum": ["<nameInResponse>"]
"enum": ["<file-name>"]
},
"specialFolder": {
"type": "object",
@@ -303,7 +303,7 @@ Feature: Change data of space
"properties": {
"mimeType": {
"type": "string",
"enum": ["<mimeType>"]
"enum": ["<mime-type>"]
}
}
},
@@ -322,12 +322,12 @@ Feature: Change data of space
}
"""
And for user "<user>" folder ".space/" of the space "Project Jupiter" should contain these entries:
| <fileName> |
| <file-name> |
Examples:
| user | fileName | nameInResponse | mimeType |
| Alice | spaceImage.jpeg | spaceImage.jpeg | image/jpeg |
| Brian | spaceImage.png | spaceImage.png | image/png |
| Alice | spaceImage.gif | spaceImage.gif | image/gif |
| user | file-name | mime-type |
| Alice | spaceImage.jpeg | image/jpeg |
| Brian | spaceImage.png | image/png |
| Alice | spaceImage.gif | image/gif |
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"
@@ -341,8 +341,8 @@ Feature: Change data of space
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
When user "<user>" uploads a file inside space "Project Jupiter" owned by the user "Alice" with content "new content" to ".space/readme.md" using the WebDAV API
Then the HTTP status code should be "<code>"
And for user "<user>" the content of the file ".space/readme.md" of the space "Project Jupiter" should be "<expectedContent>"
Then the HTTP status code should be "<http-status-code>"
And for user "<user>" the content of the file ".space/readme.md" of the space "Project Jupiter" should be "<expected-content>"
When user "<user>" lists all available spaces via the Graph API
And the JSON response should contain space called "Project Jupiter" owned by "Alice" with description file ".space/readme.md" and match
"""
@@ -374,7 +374,7 @@ Feature: Change data of space
"properties": {
"size": {
"type": "number",
"enum": [<expectedSize>]
"enum": [<expected-size>]
},
"name": {
"type": "string",
@@ -419,10 +419,10 @@ Feature: Change data of space
}
"""
Examples:
| user | code | expectedSize | expectedContent |
| Alice | 204 | 11 | new content |
| Brian | 204 | 11 | new content |
| Bob | 403 | 17 | space description |
| user | http-status-code | expected-size | expected-content |
| Alice | 204 | 11 | new content |
| Brian | 204 | 11 | new content |
| Bob | 403 | 17 | space description |
Scenario Outline: user set new image file as space image of the space via the Graph API
@@ -513,46 +513,46 @@ Feature: Change data of space
Scenario Outline: user can't upload resource greater than set quota
Given the administrator has assigned the role "<userRole>" to user "Alice" using the Graph API
Given the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
And user "Admin" has changed the quota of the personal space of "Alice Hansen" space to "15"
When user "Alice" uploads a file inside space "Alice Hansen" with content "file is more than 15 bytes" to "file.txt" using the WebDAV API
Then the HTTP status code should be "507"
And for user "Alice" the space "Personal" should not contain these entries:
| file.txt |
Examples:
| userRole |
| Admin |
| Space Admin |
| User |
| User Light |
Examples:
| user-role |
| Admin |
| Space Admin |
| User |
| User Light |
Scenario Outline: admin user set own quota of a personal space via the Graph API and upload resource
When user "Admin" changes the quota of the "Admin" space to "<quotaValue>"
When user "Admin" changes the quota of the "Admin" space to "<quota-value>"
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
Then the HTTP status code should be <code>
Then the HTTP status code should be <http-status-code>
And for user "Admin" the space "Personal" should contain these entries:
| file.txt |
Examples:
| quotaValue | code |
| 10000 | between "201" and "204" |
| 0 | between "201" and "204" |
| -1 | between "201" and "204" |
| quota-value | http-status-code |
| 10000 | between "201" and "204" |
| 0 | between "201" and "204" |
| -1 | between "201" and "204" |
Scenario Outline: admin user set an user personal space quota of via the Graph API and upload resource
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 "<quota-value>"
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
Then the HTTP status code should be <code>
Then the HTTP status code should be <http-status-code>
And for user "Brian" the space "Personal" should contain these entries:
| file.txt |
Examples:
| quotaValue | code |
| 10000 | between "201" and "204" |
| 0 | between "201" and "204" |
| -1 | between "201" and "204" |
| quota-value | http-status-code |
| 10000 | between "201" and "204" |
| 0 | between "201" and "204" |
| -1 | between "201" and "204" |
Scenario: user sends invalid space uuid via the graph API
tests/acceptance/features/apiSpaces/createSpace.feature
+6 -6
View File
@@ -8,18 +8,18 @@ Feature: create space
@issue-5938
Scenario Outline: user with role user and user light can't create space via Graph API
Given the administrator has assigned the role "<role>" to user "Alice" using the Graph API
Given the administrator has assigned the role "<user-role>" to user "Alice" 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"
And the user "Alice" should not have a space called "share space"
Examples:
| role |
| user-role |
| User |
| User Light |
Scenario Outline: admin or space admin user can create a space via the Graph API with a default quota
Given the administrator has assigned the role "<role>" to user "Alice" using the Graph API
Given the administrator has assigned the role "<user-role>" to user "Alice" 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"
And the JSON response should contain space called "Project Mars" and match
@@ -84,13 +84,13 @@ Feature: create space
}
"""
Examples:
| role |
| user-role |
| Admin |
| Space Admin |
Scenario Outline: admin or space admin user can create a space via the Graph API with certain quota
Given the administrator has assigned the role "<role>" to user "Alice" using the Graph API
Given the administrator has assigned the role "<user-role>" to user "Alice" 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"
And the JSON response should contain space called "Project Venus" and match
@@ -150,6 +150,6 @@ Feature: create space
}
"""
Examples:
| role |
| user-role |
| Admin |
| Space Admin |
tests/acceptance/features/apiSpaces/disableAndDeleteSpaces.feature
+14 -14
View File
@@ -24,13 +24,13 @@ Feature: Disabling and deleting space
Scenario Outline: user can disable their own space via the Graph API
Given the administrator has assigned the role "<role>" to user "Alice" using the Graph API
Given the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
When user "Alice" disables a space "Project Moon"
Then the HTTP status code should be "204"
And the user "Brian" should not have a space called "Project Moon"
And the user "Bob" should not have a space called "Project Moon"
Examples:
| role |
| user-role |
| Admin |
| Space Admin |
| User |
@@ -38,13 +38,13 @@ Feature: Disabling and deleting space
Scenario Outline: user with role user and user light cannot disable other space via the Graph API
Given the administrator has assigned the role "<role>" to user "Carol" using the Graph API
Given the administrator has assigned the role "<user-role>" to user "Carol" using the Graph API
When user "Carol" tries to disable a space "Project Moon" owned by user "Alice"
Then the HTTP status code should be "404"
And the user "Brian" should have a space called "Project Moon"
And the user "Bob" should have a space called "Project Moon"
Examples:
| role |
| user-role |
| User |
| User Light |
@@ -60,12 +60,12 @@ Feature: Disabling and deleting space
Scenario Outline: user cannot delete their own space without first disabling it
Given the administrator has assigned the role "<role>" to user "Alice" using the Graph API
Given the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
When user "Alice" deletes a space "Project Moon"
Then the HTTP status code should be "400"
And the user "Alice" should have a space called "Project Moon"
Examples:
| role |
| user-role |
| Admin |
| Space Admin |
| User |
@@ -73,13 +73,13 @@ Feature: Disabling and deleting space
Scenario Outline: user can delete their own disabled space via the Graph API
Given the administrator has assigned the role "<role>" to user "Alice" using the Graph API
Given the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
And user "Alice" has disabled a space "Project Moon"
When user "Alice" deletes a space "Project Moon"
Then the HTTP status code should be "204"
And the user "Alice" should not have a space called "Project Moon"
Examples:
| role |
| user-role |
| Admin |
| Space Admin |
| User |
@@ -87,35 +87,35 @@ Feature: Disabling and deleting space
Scenario Outline: an admin and space manager can disable other space via the Graph API
Given the administrator has assigned the role "<role>" to user "Carol" using the Graph API
Given the administrator has assigned the role "<user-role>" to user "Carol" using the Graph API
When user "Carol" disables a space "Project Moon" owned by user "Alice"
Then the HTTP status code should be "204"
And the user "Carol" should not have a space called "Project Moon"
Examples:
| role |
| user-role |
| Admin |
| Space Admin |
Scenario Outline: an admin and space manager can delete other disabled Space
Given the administrator has assigned the role "<role>" to user "Carol" using the Graph API
Given the administrator has assigned the role "<user-role>" to user "Carol" using the Graph API
And user "Alice" has disabled a space "Project Moon"
When user "Carol" deletes a space "Project Moon" owned by user "Alice"
Then the HTTP status code should be "204"
And the user "Alice" should not have a space called "Project Moon"
And the user "Carol" should not have a space called "Project Moon"
Examples:
| role |
| user-role |
| Admin |
| Space Admin |
Scenario Outline: user with role user and user light cannot delete others disabled space via the Graph API
Given the administrator has assigned the role "<role>" to user "Carol" using the Graph API
Given the administrator has assigned the role "<user-role>" to user "Carol" using the Graph API
And user "Alice" has disabled a space "Project Moon"
When user "Carol" tries to delete a space "Project Moon" owned by user "Alice"
Then the HTTP status code should be "404"
Examples:
| role |
| user-role |
| User |
| User Light |
tests/acceptance/features/apiSpaces/editPublicLinkOfSpace.feature
+26 -26
View File
@@ -29,55 +29,55 @@ Feature: A manager of the space can edit public link
When user "Alice" updates the last public link share using the sharing API with
| permissions | <permissions> |
| password | <password> |
| name | <linkName> |
| name | <link-name> |
Then the HTTP status code should be "200"
And the OCS status code should be "200"
And the OCS status message should be "OK"
And the fields of the last response to user "Alice" should include
| item_type | folder |
| mimetype | httpd/unix-directory |
| file_target | / |
| path | / |
| permissions | <expectedPermissions> |
| share_type | public_link |
| displayname_owner | %displayname% |
| name | <linkName> |
| item_type | folder |
| mimetype | httpd/unix-directory |
| file_target | / |
| path | / |
| permissions | <expected-permissions> |
| share_type | public_link |
| displayname_owner | %displayname% |
| name | <link-name> |
When the public downloads file "/test.txt" from inside the last public link shared folder with password "<password>" using the new public WebDAV API
Then the HTTP status code should be "200"
And the downloaded content should be "some content"
Examples:
| permissions | expectedPermissions | password | linkName |
| 5 | read,create | newPass:12 | |
| 15 | read,update,create,delete | newPass:12 | newName |
| permissions | expected-permissions | password | link-name |
| 5 | read,create | newPass:12 | |
| 15 | read,update,create,delete | newPass:12 | newName |
Scenario Outline: members can see a created public link
Given using OCS API version "2"
When user "Alice" shares a space "edit space" with settings:
| shareWith | Brian |
| role | <role> |
| shareWith | Brian |
| role | <space-role> |
Then the HTTP status code should be "200"
And the OCS status code should be "200"
And for user "Alice" the space "edit space" should contain the last created public link
And for user "Brian" the space "edit space" should contain the last created public link
Examples:
| role |
| manager |
| editor |
| viewer |
| space-role |
| manager |
| editor |
| viewer |
Scenario Outline: members of the space try to edit a public link
Given using OCS API version "2"
And user "Alice" has shared a space "edit space" with settings:
| shareWith | Brian |
| role | <role> |
| shareWith | Brian |
| role | <space-role> |
When user "Brian" updates the last public link share using the sharing API with
| permissions | 15 |
Then the HTTP status code should be "<code>"
And the OCS status code should be "<codeOCS>"
Then the HTTP status code should be "<http-status-code>"
And the OCS status code should be "<ocs-status-code>"
Examples:
| role | code | codeOCS |
| manager | 200 | 200 |
| editor | 401 | 997 |
| viewer | 401 | 997 |
| space-role | http-status-code | ocs-status-code |
| manager | 200 | 200 |
| editor | 401 | 997 |
| viewer | 401 | 997 |
tests/acceptance/features/apiSpaces/filePreviews.feature
+3 -3
View File
@@ -16,11 +16,11 @@ Feature: Preview file in project space
Scenario Outline: user can preview created txt files in the project space
Given user "Alice" has uploaded a file inside space "previews of the files" with content "test" to "<entity>"
When user "Alice" downloads the preview of "<entity>" of the space "previews of the files" with width "<width>" and height "<height>" using the WebDAV API
Given user "Alice" has uploaded a file inside space "previews of the files" with content "test" to "<file-name>"
When user "Alice" downloads the preview of "<file-name>" 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"
Examples:
| entity | width | height |
| file-name | width | height |
| /file.txt | 36 | 36 |
| /name with spaces.txt | 1200 | 1200 |
tests/acceptance/features/apiSpaces/listSpaces.feature
+6 -6
View File
@@ -291,7 +291,7 @@ Feature: List and create spaces
Scenario Outline: user can list his created spaces via multiple endpoints
Given the administrator has assigned the role "<role>" to user "Alice" using the Graph API
Given the administrator has assigned the role "<user-role>" to user "Alice" 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"
And the JSON response should contain space called "Project Venus" and match
@@ -419,19 +419,19 @@ Feature: List and create spaces
}
"""
Examples:
| role |
| user-role |
| Admin |
| Space Admin |
Scenario Outline: user cannot list space by id if he is not member of the space
Given the administrator has assigned the role "<role>" to user "Alice" using the Graph API
Given the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
And user "Admin" has created a space "Project Venus" with the default quota using the Graph API
When user "Alice" tries to look up the single space "Project Venus" owned by the user "Admin" by using its id
Then the HTTP status code should be "404"
And the json responded should not contain a space with name "Project Venus"
Examples:
| role |
| user-role |
| User |
| User Light |
@@ -440,7 +440,7 @@ Feature: List and create spaces
Given user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has disabled auto-accepting
And user "Brian" has uploaded file with content "this is a test file." to "test.txt"
And the administrator has assigned the role "<userRole>" to user "Alice" using the Graph API
And the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
And user "Brian" has shared file "/test.txt" with user "Alice"
When user "Alice" lists all available spaces via the Graph API
Then the HTTP status code should be "200"
@@ -510,7 +510,7 @@ Feature: List and create spaces
}
"""
Examples:
| userRole |
| user-role |
| Admin |
| Space Admin |
| User |
tests/acceptance/features/apiSpaces/quota.feature
+21 -21
View File
@@ -20,10 +20,10 @@ Feature: State of the quota
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 "100"
When user "Alice" uploads a file inside space "<spaceName>" with content "<fileContent>" to "test.txt" using the WebDAV API
Given user "Alice" has created a space "<space-name>" of type "project" with quota "100"
When user "Alice" uploads a file inside space "<space-name>" with content "<file-content>" to "test.txt" using the WebDAV API
And user "Alice" lists all available spaces via the Graph API
Then the JSON response should contain space called "<spaceName>" and match
Then the JSON response should contain space called "<space-name>" and match
"""
{
"type": "object",
@@ -34,7 +34,7 @@ Feature: State of the quota
"properties": {
"name": {
"type": "string",
"enum": ["<spaceName>"]
"enum": ["<space-name>"]
},
"quota": {
"type": "object",
@@ -67,14 +67,14 @@ Feature: State of the quota
}
"""
Examples:
| spaceName | fileContent | state | remaining | used |
| Quota1% | 1 | normal | 99 | 1 |
| Quota75% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12345 | normal | 25 | 75 |
| Quota76% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456 | nearing | 24 | 76 |
| Quota90% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1234567890 | nearing | 10 | 90 |
| Quota91% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1 | critical | 9 | 91 |
| Quota99% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 | critical | 1 | 99 |
| Quota100% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1234567890 | exceeded | 0 | 100 |
| space-name | file-content | state | remaining | used |
| Quota1% | 1 | normal | 99 | 1 |
| Quota75% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12345 | normal | 25 | 75 |
| Quota76% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456 | nearing | 24 | 76 |
| Quota90% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1234567890 | nearing | 10 | 90 |
| Quota91% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1 | critical | 9 | 91 |
| Quota99% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 | critical | 1 | 99 |
| Quota100% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1234567890 | exceeded | 0 | 100 |
Scenario: file cannot be uploaded if there is insufficient quota
@@ -108,19 +108,19 @@ Feature: State of the quota
Scenario Outline: check the relative amount of quota of personal space
Given user "Admin" has changed the quota of the personal space of "Alice Hansen" space to "10000"
And user "Alice" has uploaded file "<file_upload>" to "/demo.txt"
And user "Alice" has uploaded file "<file-upload>" to "/demo.txt"
When the user "Alice" requests these endpoints with "GET" with basic auth
| endpoint |
| <end_point> |
| <end-point> |
Then the HTTP status code should be "200"
And the OCS status code should be "<ocs_code>"
And the relative quota amount should be "<quota_relative>"
And the OCS status code should be "<ocs-status-code>"
And the relative quota amount should be "<quota-relative>"
Examples:
| file_upload | end_point | ocs_code | quota_relative |
| /filesForUpload/lorem.txt | /ocs/v1.php/cloud/users/%username% | 100 | 6.99 |
| /filesForUpload/lorem-big.txt | /ocs/v1.php/cloud/users/%username% | 100 | 91.17 |
| /filesForUpload/lorem.txt | /ocs/v2.php/cloud/users/%username% | 200 | 6.99 |
| /filesForUpload/lorem-big.txt | /ocs/v2.php/cloud/users/%username% | 200 | 91.17 |
| file-upload | end-point | ocs-status-code | quota-relative |
| /filesForUpload/lorem.txt | /ocs/v1.php/cloud/users/%username% | 100 | 6.99 |
| /filesForUpload/lorem-big.txt | /ocs/v1.php/cloud/users/%username% | 100 | 91.17 |
| /filesForUpload/lorem.txt | /ocs/v2.php/cloud/users/%username% | 200 | 6.99 |
| /filesForUpload/lorem-big.txt | /ocs/v2.php/cloud/users/%username% | 200 | 91.17 |
@env-config
tests/acceptance/features/apiSpaces/removeSpaceObjects.feature
+30 -30
View File
@@ -20,55 +20,55 @@ Feature: Remove files, folder
Scenario Outline: user deletes a folder with some subfolders in a space via the webDav API
Given user "Alice" has shared a space "delete objects" with settings:
| shareWith | Brian |
| role | <role> |
| shareWith | Brian |
| role | <space-role> |
When user "<user>" removes the folder "folderForDeleting" from space "delete objects"
Then the HTTP status code should be "<code>"
And for user "<user>" the space "delete objects" <shouldOrNotBeInSpace> contain these entries:
Then the HTTP status code should be "<http-status-code>"
And for user "<user>" the space "delete objects" <should-or-not-be-in-space> contain these entries:
| folderForDeleting |
And as "<user>" folder "folderForDeleting" <shouldOrNotBeInTrash> exist in the trashbin of the space "delete objects"
And as "<user>" folder "folderForDeleting" <should-or-not-be-in-trash> exist in the trashbin of the space "delete objects"
Examples:
| user | role | code | shouldOrNotBeInSpace | shouldOrNotBeInTrash |
| Alice | manager | 204 | should not | should |
| Brian | manager | 204 | should not | should |
| Brian | editor | 204 | should not | should |
| Brian | viewer | 403 | should | should not |
| user | space-role | http-status-code | should-or-not-be-in-space | should-or-not-be-in-trash |
| Alice | manager | 204 | should not | should |
| Brian | manager | 204 | should not | should |
| Brian | editor | 204 | should not | should |
| Brian | viewer | 403 | should | should not |
Scenario Outline: user deletes a subfolder in a space via the webDav API
Given user "Alice" has shared a space "delete objects" with settings:
| shareWith | Brian |
| role | <role> |
| shareWith | Brian |
| role | <space-role> |
When user "<user>" removes the folder "folderForDeleting/sub1" from space "delete objects"
Then the HTTP status code should be "<code>"
Then the HTTP status code should be "<http-status-code>"
And for user "<user>" the space "delete objects" should contain these entries:
| folderForDeleting |
And for user "<user>" folder "folderForDeleting/" of the space "delete objects" <shouldOrNotBeInSpace> contain these entries:
And for user "<user>" folder "folderForDeleting/" of the space "delete objects" <should-or-not-be-in-space> contain these entries:
| sub1 |
And as "<user>" folder "sub1" <shouldOrNotBeInTrash> exist in the trashbin of the space "delete objects"
And as "<user>" folder "sub1" <should-or-not-be-in-trash> exist in the trashbin of the space "delete objects"
Examples:
| user | role | code | shouldOrNotBeInSpace | shouldOrNotBeInTrash |
| Alice | manager | 204 | should not | should |
| Brian | manager | 204 | should not | should |
| Brian | editor | 204 | should not | should |
| Brian | viewer | 403 | should | should not |
| user | space-role | http-status-code | should-or-not-be-in-space | should-or-not-be-in-trash |
| Alice | manager | 204 | should not | should |
| Brian | manager | 204 | should not | should |
| Brian | editor | 204 | should not | should |
| Brian | viewer | 403 | should | should not |
Scenario Outline: user deletes a file in a space via the webDav API
Given user "Alice" has shared a space "delete objects" with settings:
| shareWith | Brian |
| role | <role> |
| shareWith | Brian |
| role | <space-role> |
When user "<user>" removes the file "text.txt" from space "delete objects"
Then the HTTP status code should be "<code>"
And for user "<user>" the space "delete objects" <shouldOrNotBeInSpace> contain these entries:
Then the HTTP status code should be "<http-status-code>"
And for user "<user>" the space "delete objects" <should-or-not-be-in-space> contain these entries:
| text.txt |
And as "<user>" file "text.txt" <shouldOrNotBeInTrash> exist in the trashbin of the space "delete objects"
And as "<user>" file "text.txt" <should-or-not-be-in-trash> exist in the trashbin of the space "delete objects"
Examples:
| user | role | code | shouldOrNotBeInSpace | shouldOrNotBeInTrash |
| Alice | manager | 204 | should not | should |
| Brian | manager | 204 | should not | should |
| Brian | editor | 204 | should not | should |
| Brian | viewer | 403 | should | should not |
| user | space-role | http-status-code | should-or-not-be-in-space | should-or-not-be-in-trash |
| Alice | manager | 204 | should not | should |
| Brian | manager | 204 | should not | should |
| Brian | editor | 204 | should not | should |
| Brian | viewer | 403 | should | should not |
Scenario: try to delete an empty string folder from a space
tests/acceptance/features/apiSpaces/restoreSpaces.feature
+9 -9
View File
@@ -60,34 +60,34 @@ Feature: Restoring space
Scenario Outline: user without space manager role cannot restore space
Given user "Alice" has shared a space "restore a space" with settings:
| shareWith | Brian |
| role | <role> |
| shareWith | Brian |
| role | <space-role> |
And user "Alice" has disabled a space "restore a space"
When user "Brian" tries to restore a disabled space "restore a space" owned by user "Alice"
Then the HTTP status code should be "404"
Examples:
| role |
| viewer |
| editor |
| space-role |
| viewer |
| editor |
Scenario Outline: user with role user and user light cannot restore space
Given the administrator has assigned the role "<role>" to user "Brian" using the Graph API
Given the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
And user "Alice" has disabled a space "restore a space"
When user "Brian" tries to restore a disabled space "restore a space" owned by user "Alice"
Then the HTTP status code should be "404"
Examples:
| role |
| user-role |
| User |
| User Light |
@issue-5872
Scenario Outline: admin and space admin can restore other space
Given the administrator has assigned the role "<role>" to user "Brian" using the Graph API
Given the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
And user "Alice" has disabled a space "restore a space"
When user "Brian" restores a disabled space "restore a space" owned by user "Alice"
Then the HTTP status code should be "200"
Examples:
| role |
| user-role |
| Admin |
| Space Admin |
tests/acceptance/features/apiSpaces/setQuota.feature
+19 -19
View File
@@ -12,7 +12,7 @@ Feature: Set quota
Scenario Outline: admin sets personal space quota of user with different role
Given the administrator has assigned the role "Admin" to user "Alice" using the Graph API
And the administrator has assigned the role "<userRole>" to user "Brian" using the Graph API
And the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
When user "Alice" changes the quota of the "Brian Murphy" space to "100" owned by user "Brian"
Then the HTTP status code should be "200"
And the JSON data of the response should match
@@ -39,7 +39,7 @@ Feature: Set quota
}
"""
Examples:
| userRole |
| user-role |
| Admin |
| Space Admin |
| User |
@@ -47,12 +47,12 @@ Feature: Set quota
Scenario Outline: non-admin user tries to set the personal space quota of other users
Given the administrator has assigned the role "<role>" to user "Alice" using the Graph API
And the administrator has assigned the role "<userRole>" to user "Brian" using the Graph API
Given the administrator has assigned the role "<user-role-2>" to user "Alice" using the Graph API
And the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
When user "Alice" changes the quota of the "Brian Murphy" space to "100" owned by user "Brian"
Then the HTTP status code should be "403"
Examples:
| role | userRole |
| user-role-2 | user-role |
| Space Admin | Admin |
| Space Admin | Space Admin |
| Space Admin | User |
@@ -69,7 +69,7 @@ Feature: Set quota
Scenario Outline: admin or space admin user sets a quota of a project space
Given the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
And the administrator has assigned the role "<userRole>" to user "Brian" using the Graph API
And the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
And user "Alice" has created a space "Project Jupiter" of type "project" with quota "20"
When user "Brian" changes the quota of the "Project Jupiter" space to "100" owned by user "Alice"
Then the HTTP status code should be "200"
@@ -102,28 +102,28 @@ Feature: Set quota
}
"""
Examples:
| userRole |
| user-role |
| Admin |
| Space Admin |
Scenario Outline: normal or user light user tries to set quota of a space
Given the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
And the administrator has assigned the role "<userRole>" to user "Brian" using the Graph API
And the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
And user "Alice" has created a space "Project Jupiter" of type "project" with quota "20"
And user "Alice" has shared a space "Project Jupiter" with settings:
| shareWith | Brian |
| role | <spaceRole> |
| shareWith | Brian |
| role | <space-role> |
When user "Brian" changes the quota of the "Project Jupiter" space to "100"
Then the HTTP status code should be "403"
Examples:
| userRole | spaceRole |
| User | viewer |
| User | editor |
| User | manager |
| User Light | viewer |
| User Light | editor |
| User Light | manager |
| user-role | space-role |
| User | viewer |
| User | editor |
| User | manager |
| User Light | viewer |
| User Light | editor |
| User Light | manager |
Scenario: admin user can set their own personal space quota
@@ -156,11 +156,11 @@ Feature: Set quota
Scenario Outline: non-admin user tries to set their own personal space quota
Given the administrator has assigned the role "<userRole>" to user "Alice" using the Graph API
Given the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
When user "Alice" changes the quota of the "Alice Hansen" space to "100" owned by user "Alice"
Then the HTTP status code should be "403"
Examples:
| userRole |
| user-role |
| Space Admin |
| User |
| User Light |
tests/acceptance/features/apiSpaces/spaceManagement.feature
+3 -3
View File
@@ -2,9 +2,9 @@ Feature: Space management
As a user with space admin permission
I want to be able to manage all existing project spaces
So that
- I can get all project space where I am not member using "graph/v1.0/drives" endpoint
- I can edit space: change quota, name, description
- I can enable, disable, delete space
- I can get all project space where I am not member using "graph/v1.0/drives" endpoint
- I can edit space: change quota, name, description
- I can enable, disable, delete space
Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production
See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839
tests/acceptance/features/apiSpaces/tag.feature
+35 -35
View File
@@ -85,22 +85,22 @@ Feature: Tag
Scenario Outline: member of the space tries to create tag
Given user "Alice" has shared a space "use-tag" with settings:
| shareWith | Brian |
| role | <role> |
| shareWith | Brian |
| role | <space-role> |
When user "Brian" creates the following tags for folder "folderMain/insideTheFolder.txt" of space "use-tag":
| tag level#1 |
| tag with symbols @^$#^%$@%!_+) |
Then the HTTP status code should be "<code>"
Then the HTTP status code should be "<http-status-code>"
When user "Alice" lists all available tags via the Graph API
Then the HTTP status code should be "200"
And the response <shouldOrNot> contain following tags:
And the response <should-or-not> contain following tags:
| tag level#1 |
| tag with symbols @^$#^%$@%!_+) |
Examples:
| role | code | shouldOrNot |
| viewer | 403 | should not |
| editor | 200 | should |
| manager | 200 | should |
| space-role | http-status-code | should-or-not |
| viewer | 403 | should not |
| editor | 200 | should |
| manager | 200 | should |
Scenario: recipient has a created tags if share is accepted
@@ -120,53 +120,53 @@ Feature: Tag
Scenario Outline: recipient of the shared resource tries to create a tag
Given user "Alice" has created a share inside of space "use-tag" with settings:
| path | folderMain |
| shareWith | Brian |
| role | <role> |
When user "Brian" creates the following tags for <resource> "<resourceName>" of space "Shares":
| path | folderMain |
| shareWith | Brian |
| role | <space-role> |
When user "Brian" creates the following tags for <resource-type> "<resource>" of space "Shares":
| tag in a shared resource |
| second tag |
Then the HTTP status code should be "<code>"
Then the HTTP status code should be "<http-status-code>"
When user "Alice" lists all available tags via the Graph API
Then the HTTP status code should be "200"
And the response <shouldOrNot> contain following tags:
And the response <should-or-not> contain following tags:
| tag in a shared resource |
| second tag |
Examples:
| role | resource | resourceName | code | shouldOrNot |
| viewer | file | folderMain/insideTheFolder.txt | 403 | should not |
| editor | file | folderMain/insideTheFolder.txt | 200 | should |
| manager | file | folderMain/insideTheFolder.txt | 200 | should |
| viewer | folder | folderMain | 403 | should not |
| editor | folder | folderMain | 200 | should |
| manager | folder | folderMain | 200 | should |
| space-role | resource-type | resource | http-status-code | should-or-not |
| viewer | file | folderMain/insideTheFolder.txt | 403 | should not |
| editor | file | folderMain/insideTheFolder.txt | 200 | should |
| manager | file | folderMain/insideTheFolder.txt | 200 | should |
| viewer | folder | folderMain | 403 | should not |
| editor | folder | folderMain | 200 | should |
| manager | folder | folderMain | 200 | should |
Scenario Outline: recipient of the shared resource tries to remove a tag
Given user "Alice" has created a share inside of space "use-tag" with settings:
| path | folderMain |
| shareWith | Brian |
| role | <role> |
And user "Alice" has created the following tags for <resource> "<resourceName>" of the space "use-tag":
| path | folderMain |
| shareWith | Brian |
| role | <space-role> |
And user "Alice" has created the following tags for <resource-type> "<resource>" of the space "use-tag":
| tag in a shared resource |
| second tag |
When user "Brian" removes the following tags for <resource> "<resourceName>" of space "Shares":
When user "Brian" removes the following tags for <resource-type> "<resource>" of space "Shares":
| tag in a shared resource |
| second tag |
Then the HTTP status code should be "<code>"
Then the HTTP status code should be "<http-status-code>"
When user "Alice" lists all available tags via the Graph API
Then the HTTP status code should be "200"
And the response <shouldOrNot> contain following tags:
And the response <should-or-not> contain following tags:
| tag in a shared resource |
| second tag |
Examples:
| role | resource | resourceName | code | shouldOrNot |
| viewer | file | folderMain/insideTheFolder.txt | 403 | should |
| editor | file | folderMain/insideTheFolder.txt | 200 | should not |
| manager | file | folderMain/insideTheFolder.txt | 200 | should not |
| viewer | folder | folderMain | 403 | should |
| editor | folder | folderMain | 200 | should not |
| manager | folder | folderMain | 200 | should not |
| space-role | resource-type | resource | http-status-code | should-or-not |
| viewer | file | folderMain/insideTheFolder.txt | 403 | should |
| editor | file | folderMain/insideTheFolder.txt | 200 | should not |
| manager | file | folderMain/insideTheFolder.txt | 200 | should not |
| viewer | folder | folderMain | 403 | should |
| editor | folder | folderMain | 200 | should not |
| manager | folder | folderMain | 200 | should not |
Scenario: user removes folder tags
tests/acceptance/features/apiSpaces/trashBin.feature
+38 -38
View File
@@ -20,8 +20,8 @@ Feature: Restore files, folder
Scenario Outline: user with different role can see deleted objects in trash bin of the space via the webDav API
Given user "Alice" has shared a space "restore objects" with settings:
| shareWith | Brian |
| role | <role> |
| shareWith | Brian |
| role | <space-role> |
And user "Alice" has removed the file "newFolder/file.txt" from space "restore objects"
And user "Alice" has removed the folder "newFolder" from space "restore objects"
When user "Brian" lists all deleted files in the trash bin of the space "restore objects"
@@ -29,71 +29,71 @@ Feature: Restore files, folder
And as "Brian" folder "newFolder" should exist in the trashbin of the space "restore objects"
And as "Brian" file "file.txt" should exist in the trashbin of the space "restore objects"
Examples:
| role |
| manager |
| editor |
| viewer |
| space-role |
| manager |
| editor |
| viewer |
Scenario Outline: user can restore a folder with some objects from the trash via the webDav API
Given user "Alice" has shared a space "restore objects" with settings:
| shareWith | Brian |
| role | <role> |
| shareWith | Brian |
| role | <space-role> |
And user "Alice" has removed the folder "newFolder" from space "restore objects"
When user "<user>" restores the folder "newFolder" from the trash of the space "restore objects" to "/newFolder"
Then the HTTP status code should be "<code>"
And for user "<user>" the space "restore objects" <shouldOrNotBeInSpace> contain these entries:
Then the HTTP status code should be "<http-status-code>"
And for user "<user>" the space "restore objects" <should-or-not-be-in-space> contain these entries:
| newFolder |
And as "<user>" folder "newFolder" <shouldOrNotBeInTrash> exist in the trashbin of the space "restore objects"
And as "<user>" folder "newFolder" <should-or-not-be-in-trash> exist in the trashbin of the space "restore objects"
Examples:
| user | role | code | shouldOrNotBeInSpace | shouldOrNotBeInTrash |
| Alice | manager | 201 | should | should not |
| Brian | manager | 201 | should | should not |
| Brian | editor | 201 | should | should not |
| Brian | viewer | 403 | should not | should |
| user | space-role | http-status-code | should-or-not-be-in-space | should-or-not-be-in-trash |
| Alice | manager | 201 | should | should not |
| Brian | manager | 201 | should | should not |
| Brian | editor | 201 | should | should not |
| Brian | viewer | 403 | should not | should |
Scenario Outline: user can restore a file from the trash via the webDav API
Given user "Alice" has shared a space "restore objects" with settings:
| shareWith | Brian |
| role | <role> |
| shareWith | Brian |
| role | <space-role> |
And user "Alice" has removed the file "newFolder/file.txt" from space "restore objects"
When user "<user>" restores the file "file.txt" from the trash of the space "restore objects" to "newFolder/file.txt"
Then the HTTP status code should be "<code>"
And for user "<user>" folder "newFolder" of the space "restore objects" <shouldOrNotBeInSpace> contain these files:
Then the HTTP status code should be "<http-status-code>"
And for user "<user>" folder "newFolder" of the space "restore objects" <should-or-not-be-in-space> contain these files:
| file.txt |
And as "<user>" file "file.txt" <shouldOrNotBeInTrash> exist in the trashbin of the space "restore objects"
And as "<user>" file "file.txt" <should-or-not-be-in-trash> exist in the trashbin of the space "restore objects"
Examples:
| user | role | code | shouldOrNotBeInSpace | shouldOrNotBeInTrash |
| Alice | manager | 201 | should | should not |
| Brian | manager | 201 | should | should not |
| Brian | editor | 201 | should | should not |
| Brian | viewer | 403 | should not | should |
| user | space-role | http-status-code | should-or-not-be-in-space | should-or-not-be-in-trash |
| Alice | manager | 201 | should | should not |
| Brian | manager | 201 | should | should not |
| Brian | editor | 201 | should | should not |
| Brian | viewer | 403 | should not | should |
Scenario Outline: only space manager can purge the trash via the webDav API
Given user "Alice" has shared a space "restore objects" with settings:
| shareWith | Brian |
| role | <role> |
| shareWith | Brian |
| role | <space-role> |
And the administrator has assigned the role "Space Admin" to user "Brian" using the Graph API
And user "Alice" has removed the file "newFolder/file.txt" from space "restore objects"
When user "Brian" deletes the file "file.txt" from the trash of the space "restore objects"
Then the HTTP status code should be "<code>"
And as "Brian" file "file.txt" <shouldOrNotBeInTrash> exist in the trashbin of the space "restore objects"
Then the HTTP status code should be "<http-status-code>"
And as "Brian" file "file.txt" <should-or-not-be-in-trash> exist in the trashbin of the space "restore objects"
Examples:
| role | code | shouldOrNotBeInTrash |
| manager | 204 | should not |
| editor | 403 | should |
| viewer | 403 | should |
| space-role | http-status-code | should-or-not-be-in-trash |
| manager | 204 | should not |
| editor | 403 | should |
| viewer | 403 | should |
Scenario Outline: admin user who is not a member of space cannot see its trash bin
Given user "Alice" has removed the file "newFolder/file.txt" from space "restore objects"
And the administrator has assigned the role "<role>" to user "Brian" using the Graph API
And the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
When user "Brian" with admin permission lists all deleted files in the trash bin of the space "restore objects"
Then the HTTP status code should be "404"
Examples:
| role |
| user-role |
| Space Admin |
| Admin |
@@ -102,13 +102,13 @@ Feature: Restore files, folder
Given user "Alice" has shared a space "restore objects" with settings:
| shareWith | Brian |
| role | editor |
And the administrator has assigned the role "<role>" to user "Brian" using the Graph API
And the administrator has assigned the role "<user-role>" to user "Brian" using the Graph API
And user "Alice" has removed the file "newFolder/file.txt" from space "restore objects"
When user "Brian" tries to delete the file "file.txt" from the trash of the space "restore objects"
Then the HTTP status code should be "403"
And as "Alice" file "file.txt" should exist in the trashbin of the space "restore objects"
Examples:
| role |
| user-role |
| Space Admin |
| Admin |
tests/acceptance/features/apiSpaces/uploadSpaces.feature
+18 -18
View File
@@ -19,32 +19,32 @@ Feature: Upload files into a space
Scenario Outline: user creates a folder in the space via the Graph API
Given user "Alice" has shared a space "Project Ceres" with settings:
| shareWith | Brian |
| role | <role> |
| shareWith | Brian |
| role | <space-role> |
When user "Brian" creates a folder "mainFolder" in space "Project Ceres" using the WebDav Api
Then the HTTP status code should be "<code>"
And for user "Brian" the space "Project Ceres" <shouldOrNot> contain these entries:
Then the HTTP status code should be "<http-status-code>"
And for user "Brian" the space "Project Ceres" <should-or-not> contain these entries:
| mainFolder |
Examples:
| role | code | shouldOrNot |
| manager | 201 | should |
| editor | 201 | should |
| viewer | 403 | should not |
| space-role | http-status-code | should-or-not |
| manager | 201 | should |
| editor | 201 | should |
| viewer | 403 | should not |
Scenario Outline: user uploads a file in shared space via the Graph API
Given user "Alice" has shared a space "Project Ceres" with settings:
| shareWith | Brian |
| role | <role> |
| shareWith | Brian |
| role | <space-role> |
When user "Brian" uploads a file inside space "Project Ceres" with content "Test" to "test.txt" using the WebDAV API
Then the HTTP status code should be "<code>"
And for user "Brian" the space "Project Ceres" <shouldOrNot> contain these entries:
Then the HTTP status code should be "<http-status-code>"
And for user "Brian" the space "Project Ceres" <should-or-not> contain these entries:
| test.txt |
Examples:
| role | code | shouldOrNot |
| manager | 201 | should |
| editor | 201 | should |
| viewer | 403 | should not |
| space-role | http-status-code | should-or-not |
| manager | 201 | should |
| editor | 201 | should |
| viewer | 403 | should not |
Scenario: user can create subfolders in a space via the Graph API
@@ -83,9 +83,9 @@ Feature: Upload files into a space
Scenario Outline: user cannot create subfolder in a nonexistent folder
When user "Alice" tries to create subfolder "<path>" in a nonexistent folder of the space "Project Ceres" using the WebDav Api
When user "Alice" tries to create subfolder "<folder-name>" in a nonexistent folder of the space "Project Ceres" using the WebDav Api
Then the HTTP status code should be "409"
Examples:
| path |
| folder-name |
| foo/bar |
| foo/bar/baz |