Files
opencloud/tests/acceptance/features/apiSpaces/deleteSpaces.feature
Sagar Gurung 67296caf14 Forward port json drill apispaces (#5818)
* Added json schema for response check in apiSpaces suite

Signed-off-by: sagargurung1001@gmail.com <sagargurung1001@gmail.com>

* Review Address

* Added schema for space management feature

* Added new schema asper change in master

* fix feature file

---------

Signed-off-by: sagargurung1001@gmail.com <sagargurung1001@gmail.com>
2023-03-15 10:06:58 +05:45

131 lines
4.0 KiB
Gherkin

@api @skipOnOcV10
Feature: Disabling and deleting space
As a manager of space
I want to be able to disable the space first, then delete it.
I want to make sure that a disabled spaces isn't accessible by shared users.
Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production
See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839
Background:
Given these users have been created with default attributes and without skeleton files:
| username |
| Alice |
| Brian |
| Bob |
And the administrator has given "Alice" the role "Space Admin" using the settings api
And user "Alice" has created a space "Project Moon" with the default quota using the GraphApi
And user "Alice" has shared a space "Project Moon" with settings:
| shareWith | Brian |
| role | editor |
And user "Alice" has shared a space "Project Moon" with settings:
| shareWith | Bob |
| role | viewer |
Scenario Outline: A space admin user can disable a Space via the Graph API
When user "Alice" disables a space "Project Moon"
Then the HTTP status code should be "204"
And for user "Alice" the JSON response should contain space called "Project Moon" and match
"""
{
"type": "object",
"required": [
"name",
"root"
],
"properties": {
"name": {
"type": "string",
"enum": ["Project Moon"]
},
"root": {
"type": "object",
"required": [
"deleted"
],
"properties": {
"deleted": {
"type": "object",
"required": [
"state"
],
"properties": {
"state": {
"type": "string",
"enum": ["trashed"]
}
}
}
}
}
}
}
"""
And the user "<user>" should not have a space called "Project Moon"
Examples:
| user |
| Brian |
| Bob |
Scenario Outline: An user without space admin role cannot disable a Space via the Graph API
When user "<user>" disables a space "Project Moon"
Then the HTTP status code should be "403"
And for user "<user>" the JSON response should contain space called "Project Moon" and match
"""
{
"type": "object",
"required": [
"name"
],
"properties": {
"name": {
"type": "string",
"enum": ["Project Moon"]
}
}
}
"""
Examples:
| user |
| Brian |
| Bob |
Scenario: A space manager can delete a disabled Space via the webDav API
Given 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"
Scenario: An space manager can disable and delete Space in which files and folders exist via the webDav API
Given user "Alice" has uploaded a file inside space "Project Moon" with content "test" to "test.txt"
And user "Alice" has created a folder "MainFolder" in space "Project Moon"
When user "Alice" disables a space "Project Moon"
Then the HTTP status code should be "204"
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"
Scenario: An space manager cannot delete a space via the webDav API without first disabling it
When user "Alice" deletes a space "Project Moon"
Then the HTTP status code should be "400"
And for user "Alice" the JSON response should contain space called "Project Moon" and match
"""
{
"type": "object",
"required": [
"name"
],
"properties": {
"name": {
"type": "string",
"enum": ["Project Moon"]
}
}
}
"""