Initial QSfera import
This commit is contained in:
Курнат Андрей
@@ -0,0 +1,674 @@
|
||||
Feature: Change data of space
|
||||
As a user with space admin rights
|
||||
I want to be able to change the meta-data of a created space (increase the quota, change name, etc.)
|
||||
So that I can manage the spaces
|
||||
|
||||
Background:
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
| Bob |
|
||||
And the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
|
||||
And user "Alice" has created a space "Project Jupiter" of type "project" with quota "20"
|
||||
And user "Alice" has sent the following space share invitation:
|
||||
| space | Project Jupiter |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Space Editor |
|
||||
And user "Alice" has sent the following space share invitation:
|
||||
| space | Project Jupiter |
|
||||
| sharee | Bob |
|
||||
| shareType | user |
|
||||
| permissionsRole | Space Viewer |
|
||||
And using spaces DAV path
|
||||
|
||||
|
||||
Scenario: user with space manager role can change the name of a space via the Graph API
|
||||
When user "Alice" changes the name of the "Project Jupiter" space to "Project Death Star"
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"name",
|
||||
"driveType"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["Project Death Star"]
|
||||
},
|
||||
"driveType": {
|
||||
"type": "string",
|
||||
"enum": ["project"]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
|
||||
|
||||
Scenario Outline: user other than space manager role can't change the name of a Space via the Graph API
|
||||
When user "<user>" changes the name of the "Project Jupiter" space to "Project Jupiter"
|
||||
Then the HTTP status code should be "404"
|
||||
Examples:
|
||||
| user |
|
||||
| Brian |
|
||||
| Bob |
|
||||
|
||||
|
||||
Scenario: user with space manager role can change the description(subtitle) of a space via the Graph API
|
||||
When user "Alice" changes the description of the "Project Jupiter" space to "The Death Star is a fictional mobile space station"
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"name",
|
||||
"driveType",
|
||||
"description"
|
||||
],
|
||||
"properties": {
|
||||
"driveType": {
|
||||
"type": "string",
|
||||
"enum": ["project"]
|
||||
},
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["Project Jupiter"]
|
||||
},
|
||||
"description": {
|
||||
"type": "string",
|
||||
"enum": ["The Death Star is a fictional mobile space station"]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
|
||||
|
||||
Scenario Outline: viewer and editor cannot change the description(subtitle) of a space via the Graph API
|
||||
When user "<user>" changes the description of the "Project Jupiter" space to "The Death Star is a fictional mobile space station"
|
||||
Then the HTTP status code should be "404"
|
||||
Examples:
|
||||
| user |
|
||||
| Brian |
|
||||
| Bob |
|
||||
|
||||
|
||||
Scenario Outline: user with normal space permission can't increase the quota of a Space via the Graph API
|
||||
When user "<user>" changes the quota of the "Project Jupiter" space to "100"
|
||||
Then the HTTP status code should be "403"
|
||||
Examples:
|
||||
| user |
|
||||
| Brian |
|
||||
| Bob |
|
||||
|
||||
|
||||
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 "<quota-value>"
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"name",
|
||||
"quota"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["Project Jupiter"]
|
||||
},
|
||||
"quota": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"used",
|
||||
"total"
|
||||
],
|
||||
"properties": {
|
||||
"used" : {
|
||||
"type": "number",
|
||||
"enum": [0]
|
||||
},
|
||||
"total" : {
|
||||
"type": "number",
|
||||
"enum": [0]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| quota-value |
|
||||
| 0 |
|
||||
| -1 |
|
||||
|
||||
|
||||
Scenario: user space admin set readme file as description of the space via the Graph API
|
||||
Given user "Alice" has created a folder ".space" in space "Project Jupiter"
|
||||
And user "Alice" has uploaded a file inside space "Project Jupiter" with content "space description" to ".space/readme.md"
|
||||
When user "Alice" sets the file ".space/readme.md" as a description in a special section of the "Project Jupiter" space
|
||||
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/readme.md" and match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"name",
|
||||
"special"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["Project Jupiter"]
|
||||
},
|
||||
"special": {
|
||||
"type": "array",
|
||||
"minItems": 1,
|
||||
"maxItems": 1,
|
||||
"items": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"size",
|
||||
"name",
|
||||
"specialFolder",
|
||||
"file",
|
||||
"id",
|
||||
"eTag"
|
||||
],
|
||||
"properties": {
|
||||
"size": {
|
||||
"type": "number",
|
||||
"enum": [17]
|
||||
},
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["readme.md"]
|
||||
},
|
||||
"specialFolder": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"name"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["readme"]
|
||||
}
|
||||
}
|
||||
},
|
||||
"file": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"mimeType"
|
||||
],
|
||||
"properties": {
|
||||
"mimeType": {
|
||||
"type": "string",
|
||||
"enum": ["text/markdown"]
|
||||
}
|
||||
}
|
||||
},
|
||||
"id": {
|
||||
"type": "string",
|
||||
"enum": ["%file_id%"]
|
||||
},
|
||||
"tag": {
|
||||
"type": "string",
|
||||
"enum": ["%eTag%"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
And for user "Alice" the content of the file ".space/readme.md" of the space "Project Jupiter" should be "space description"
|
||||
|
||||
|
||||
Scenario Outline: user member of the space changes readme file
|
||||
Given user "Alice" has created a folder ".space" in space "Project Jupiter"
|
||||
And user "Alice" has uploaded a file inside space "Project Jupiter" with content "space description" to ".space/readme.md"
|
||||
And user "Alice" has set the file ".space/readme.md" as a description in a special section of the "Project Jupiter" space
|
||||
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 "<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 | 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/<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/<file-name>" and match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"name",
|
||||
"special"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["Project Jupiter"]
|
||||
},
|
||||
"special": {
|
||||
"type": "array",
|
||||
"minItems": 1,
|
||||
"maxItems": 1,
|
||||
"items": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"size",
|
||||
"name",
|
||||
"specialFolder",
|
||||
"file",
|
||||
"id",
|
||||
"eTag"
|
||||
],
|
||||
"properties": {
|
||||
"size": {
|
||||
"type": "number",
|
||||
"enum": [0]
|
||||
},
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["<file-name>"]
|
||||
},
|
||||
"specialFolder": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"name"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["image"]
|
||||
}
|
||||
}
|
||||
},
|
||||
"file": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"mimeType"
|
||||
],
|
||||
"properties": {
|
||||
"mimeType": {
|
||||
"type": "string",
|
||||
"enum": ["<mime-type>"]
|
||||
}
|
||||
}
|
||||
},
|
||||
"id": {
|
||||
"type": "string",
|
||||
"enum": ["%file_id%"]
|
||||
},
|
||||
"tag": {
|
||||
"type": "string",
|
||||
"enum": ["%eTag%"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
And for user "<user>" folder ".space/" of the space "Project Jupiter" should contain these entries:
|
||||
| <file-name> |
|
||||
Examples:
|
||||
| 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"
|
||||
And user "Alice" has uploaded a file inside space "Project Jupiter" with content "" to ".space/someImageFile.jpg"
|
||||
When user "Bob" sets the file ".space/someImageFile.jpg" as a space image in a special section of the "Project Jupiter" space
|
||||
Then the HTTP status code should be "404"
|
||||
|
||||
|
||||
Scenario Outline: user set new readme file as description of the space via the graph API
|
||||
Given user "Alice" has created a folder ".space" in space "Project Jupiter"
|
||||
And user "Alice" has uploaded a file inside space "Project Jupiter" with content "space description" to ".space/readme.md"
|
||||
And user "Alice" has set the file ".space/readme.md" as a description in a special section of the "Project Jupiter" space
|
||||
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 "<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
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"name",
|
||||
"special"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["Project Jupiter"]
|
||||
},
|
||||
"special": {
|
||||
"type": "array",
|
||||
"minItems": 1,
|
||||
"maxItems": 1,
|
||||
"items": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"size",
|
||||
"name",
|
||||
"specialFolder",
|
||||
"file",
|
||||
"id",
|
||||
"eTag"
|
||||
],
|
||||
"properties": {
|
||||
"size": {
|
||||
"type": "number",
|
||||
"enum": [<expected-size>]
|
||||
},
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["readme.md"]
|
||||
},
|
||||
"specialFolder": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"name"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["readme"]
|
||||
}
|
||||
}
|
||||
},
|
||||
"file": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"mimeType"
|
||||
],
|
||||
"properties": {
|
||||
"mimeType": {
|
||||
"type": "string",
|
||||
"enum": ["text/markdown"]
|
||||
}
|
||||
}
|
||||
},
|
||||
"id": {
|
||||
"type": "string",
|
||||
"enum": ["%file_id%"]
|
||||
},
|
||||
"tag": {
|
||||
"type": "string",
|
||||
"enum": ["%eTag%"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| 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
|
||||
Given user "Alice" has created a folder ".space" in space "Project Jupiter"
|
||||
And user "Alice" has uploaded a file inside space "Project Jupiter" with content "" to ".space/spaceImage.jpeg"
|
||||
And user "Alice" has set the file ".space/spaceImage.jpeg" as a space image in a special section of the "Project Jupiter" space
|
||||
When user "<user>" uploads a file inside space "Project Jupiter" with content "" to ".space/newSpaceImage.png" using the WebDAV API
|
||||
And user "<user>" sets the file ".space/newSpaceImage.png" 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 space image ".space/newSpaceImage.png" and match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"name",
|
||||
"special"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["Project Jupiter"]
|
||||
},
|
||||
"special": {
|
||||
"type": "array",
|
||||
"minItems": 1,
|
||||
"maxItems": 1,
|
||||
"items": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"size",
|
||||
"name",
|
||||
"specialFolder",
|
||||
"file",
|
||||
"id",
|
||||
"eTag"
|
||||
],
|
||||
"properties": {
|
||||
"size": {
|
||||
"type": "number",
|
||||
"enum": [0]
|
||||
},
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["newSpaceImage.png"]
|
||||
},
|
||||
"specialFolder": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"name"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["image"]
|
||||
}
|
||||
}
|
||||
},
|
||||
"file": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"mimeType"
|
||||
],
|
||||
"properties": {
|
||||
"mimeType": {
|
||||
"type": "string",
|
||||
"enum": ["image/png"]
|
||||
}
|
||||
}
|
||||
},
|
||||
"id": {
|
||||
"type": "string",
|
||||
"enum": ["%file_id%"]
|
||||
},
|
||||
"tag": {
|
||||
"type": "string",
|
||||
"enum": ["%eTag%"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| user |
|
||||
| Alice |
|
||||
| Brian |
|
||||
|
||||
|
||||
Scenario Outline: user can't upload resource greater than set quota
|
||||
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 user "Alice" to "15"
|
||||
When user "Alice" uploads a file inside space "Personal" 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:
|
||||
| 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 personal space of user "Alice" to "<quota-value>" using the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
When user "Alice" uploads a file inside space "Personal" with content "file is more than 15 bytes" to "file.txt" using the WebDAV API
|
||||
Then the HTTP status code should be <http-status-code>
|
||||
And for user "Alice" the space "Personal" should contain these entries:
|
||||
| file.txt |
|
||||
Examples:
|
||||
| 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 personal space of user "Brian" to "<quota-value>" using the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
When user "Brian" uploads a file inside space "Personal" with content "file is more than 15 bytes" to "file.txt" using the WebDAV API
|
||||
Then the HTTP status code should be <http-status-code>
|
||||
And for user "Brian" the space "Personal" should contain these entries:
|
||||
| file.txt |
|
||||
Examples:
|
||||
| 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
|
||||
When user "Admin" tries to change the name of the "non-existing" space to "new name"
|
||||
Then the HTTP status code should be "404"
|
||||
When user "Admin" tries to change the quota of the "non-existing" space to "10"
|
||||
Then the HTTP status code should be "404"
|
||||
When user "Alice" tries to change the description of the "non-existing" space to "new description"
|
||||
Then the HTTP status code should be "404"
|
||||
|
||||
|
||||
Scenario: user sends PATCH request to other user's space that they don't have access to
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Carol |
|
||||
When user "Carol" sends PATCH request to the space "Personal" of user "Alice" with data "{}"
|
||||
Then the HTTP status code should be "404"
|
||||
When user "Carol" sends PATCH request to the space "Project Jupiter" of user "Alice" with data "{}"
|
||||
Then the HTTP status code should be "404"
|
||||
|
||||
@env-config
|
||||
Scenario Outline: space member with role 'Space Editor Without Versions' and Space Editor edits the space
|
||||
Given the administrator has enabled the permissions role "Space Editor Without Versions"
|
||||
And these users have been created with default attributes:
|
||||
| username |
|
||||
| Carol |
|
||||
And user "Alice" has sent the following space share invitation:
|
||||
| space | Project Jupiter |
|
||||
| sharee | Carol |
|
||||
| shareType | user |
|
||||
| permissionsRole | <role> |
|
||||
When user "Carol" creates a folder ".space" in space "Project Jupiter" using the WebDav Api
|
||||
Then the HTTP status code should be "201"
|
||||
When user "Carol" uploads a file inside space "Project Jupiter" with content "hello" to ".space/readme.md" using the WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
When user "Carol" sets the file ".space/readme.md" as a description in a special section of the "Project Jupiter" space
|
||||
Then the HTTP status code should be "200"
|
||||
When user "Carol" removes the folder ".space" from space "Project Jupiter"
|
||||
Then the HTTP status code should be "204"
|
||||
Examples:
|
||||
| role |
|
||||
| Space Editor Without Versions |
|
||||
| Space Editor |
|
||||
|
||||
@issue-462
|
||||
Scenario: user doesn't lose the space image when admin fetches the space
|
||||
Given the administrator has assigned the role "Space Admin" to user "Brian" using the Graph API
|
||||
And user "Alice" has created a folder ".space" in space "Project Jupiter"
|
||||
And user "Alice" has uploaded a file inside space "Project Jupiter" with content "" to ".space/spaceImage.jpeg"
|
||||
And user "Alice" has set the file ".space/spaceImage.jpeg" as a space image in a special section of the "Project Jupiter" space
|
||||
When user "Brian" lists all spaces via the Graph API
|
||||
And user "Alice" lists all available spaces via the Graph API with query "$filter=driveType eq 'project'"
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON response should contain space called "Project Jupiter" owned by "Alice" with space image ".space/spaceImage.png" and match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"name",
|
||||
"special"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["Project Jupiter"]
|
||||
},
|
||||
"special": {
|
||||
"type": "array",
|
||||
"minItems": 1,
|
||||
"maxItems": 1,
|
||||
"items": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"size",
|
||||
"name",
|
||||
"specialFolder",
|
||||
"file"
|
||||
],
|
||||
"properties": {
|
||||
"size": {
|
||||
"type": "number",
|
||||
"enum": [0]
|
||||
},
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["spaceImage.jpeg"]
|
||||
},
|
||||
"specialFolder": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"name"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["image"]
|
||||
}
|
||||
}
|
||||
},
|
||||
"file": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"mimeType"
|
||||
],
|
||||
"properties": {
|
||||
"mimeType": {
|
||||
"type": "string",
|
||||
"enum": ["image/jpeg"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
@@ -0,0 +1,155 @@
|
||||
Feature: create space
|
||||
As an admin and space admin
|
||||
I want to create new spaces
|
||||
So that I can organize a set of resources in a hierarchical tree
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes
|
||||
|
||||
@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 "<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:
|
||||
| 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 "<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
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"driveType",
|
||||
"driveAlias",
|
||||
"name",
|
||||
"id",
|
||||
"quota",
|
||||
"root",
|
||||
"webUrl"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["Project Mars"]
|
||||
},
|
||||
"driveType": {
|
||||
"type": "string",
|
||||
"enum": ["project"]
|
||||
},
|
||||
"driveAlias": {
|
||||
"type": "string",
|
||||
"enum": ["project/project-mars"]
|
||||
},
|
||||
"id": {
|
||||
"type": "string",
|
||||
"enum": ["%space_id%"]
|
||||
},
|
||||
"quota": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"total"
|
||||
],
|
||||
"properties": {
|
||||
"total": {
|
||||
"type": "number",
|
||||
"enum": [1000000000]
|
||||
}
|
||||
}
|
||||
},
|
||||
"root": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"webDavUrl"
|
||||
],
|
||||
"properties": {
|
||||
"webDavUrl": {
|
||||
"type": "string",
|
||||
"enum": ["%base_url%/dav/spaces/%space_id%"]
|
||||
}
|
||||
}
|
||||
},
|
||||
"webUrl": {
|
||||
"type": "string",
|
||||
"enum": ["%base_url%/f/%space_id%"]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| 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 "<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
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"driveType",
|
||||
"name",
|
||||
"id",
|
||||
"quota",
|
||||
"root",
|
||||
"webUrl"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["Project Venus"]
|
||||
},
|
||||
"driveType": {
|
||||
"type": "string",
|
||||
"enum": ["project"]
|
||||
},
|
||||
"id": {
|
||||
"type": "string",
|
||||
"enum": ["%space_id%"]
|
||||
},
|
||||
"quota": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"total"
|
||||
],
|
||||
"properties": {
|
||||
"total": {
|
||||
"type": "number",
|
||||
"enum": [2000]
|
||||
}
|
||||
}
|
||||
},
|
||||
"root": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"webDavUrl"
|
||||
],
|
||||
"properties": {
|
||||
"webDavUrl": {
|
||||
"type": "string",
|
||||
"enum": ["%base_url%/dav/spaces/%space_id%"]
|
||||
}
|
||||
}
|
||||
},
|
||||
"webUrl": {
|
||||
"type": "string",
|
||||
"enum": ["%base_url%/f/%space_id%"]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| user-role |
|
||||
| Admin |
|
||||
| Space Admin |
|
||||
@@ -0,0 +1,152 @@
|
||||
Feature: Disabling and deleting space
|
||||
As a manager of space
|
||||
I want to be able to disable the space first, then delete it.
|
||||
So that a disabled spaces isn't accessible by shared users.
|
||||
|
||||
Background:
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
| Bob |
|
||||
| Carol |
|
||||
And the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
|
||||
And user "Alice" has created a space "Project Moon" with the default quota using the Graph API
|
||||
And user "Alice" has sent the following space share invitation:
|
||||
| space | Project Moon |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Space Editor |
|
||||
And user "Alice" has sent the following space share invitation:
|
||||
| space | Project Moon |
|
||||
| sharee | Bob |
|
||||
| shareType | user |
|
||||
| permissionsRole | Space Viewer |
|
||||
|
||||
|
||||
Scenario Outline: user can disable their own space via 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:
|
||||
| user-role |
|
||||
| Admin |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario Outline: user with role user and user light cannot disable other space via 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:
|
||||
| user-role |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario: a 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 Outline: user cannot delete their own space without first disabling it
|
||||
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:
|
||||
| user-role |
|
||||
| Admin |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario Outline: user can delete their own disabled space via 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:
|
||||
| user-role |
|
||||
| Admin |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario Outline: an admin and space manager can disable other space via 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:
|
||||
| user-role |
|
||||
| Admin |
|
||||
| Space Admin |
|
||||
|
||||
|
||||
Scenario Outline: an admin and space manager can delete other disabled Space
|
||||
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:
|
||||
| user-role |
|
||||
| Admin |
|
||||
| Space Admin |
|
||||
|
||||
|
||||
Scenario Outline: user with role user and user light cannot disable space
|
||||
Given the administrator has assigned the role "<user-role>" to user "Carol" using the Graph API
|
||||
When user "Carol" tries to delete a space "Project Moon" owned by user "Alice"
|
||||
Then the HTTP status code should be "404"
|
||||
Examples:
|
||||
| user-role |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario Outline: user with role user and user light cannot delete others disabled space
|
||||
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:
|
||||
| user-role |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario Outline: viewer and space editor cannot disable space
|
||||
When user "<user>" tries to disable a space "Project Moon" owned by user "Alice"
|
||||
Then the HTTP status code should be "404"
|
||||
And the user "<user>" should have a space called "Project Moon"
|
||||
Examples:
|
||||
| user |
|
||||
| Brian |
|
||||
| Bob |
|
||||
|
||||
|
||||
Scenario Outline: viewer and space editor cannot delete disabled space
|
||||
Given user "Alice" has disabled a space "Project Moon"
|
||||
When user "<user>" tries to delete a space "Project Moon" owned by user "Alice"
|
||||
Then the HTTP status code should be "404"
|
||||
Examples:
|
||||
| user |
|
||||
| Brian |
|
||||
| Bob |
|
||||
@@ -0,0 +1,83 @@
|
||||
Feature: A manager of the space can edit public link
|
||||
As an user with manager space role
|
||||
I want to be able to edit a public link.
|
||||
So that I can remove or change permission, password, expireDate, and name attributes
|
||||
Users without the manager role cannot see or edit the public link
|
||||
|
||||
Background:
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
And using spaces DAV path
|
||||
And the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
|
||||
And user "Alice" has created a space "edit space" with the default quota using the Graph API
|
||||
And user "Alice" has created the following space link share:
|
||||
| space | edit space |
|
||||
| permissionsRole | view |
|
||||
| password | %public% |
|
||||
| expirationDateTime | 2040-01-01T23:59:59.000Z |
|
||||
| displayName | someName |
|
||||
And user "Alice" has uploaded a file inside space "edit space" with content "some content" to "test.txt"
|
||||
And using SharingNG
|
||||
|
||||
@issue-9724 @issue-10331
|
||||
Scenario Outline: manager of the space can edit public link.
|
||||
Given using OCS API version "2"
|
||||
When user "Alice" updates the last public link share using the sharing API with
|
||||
| permissions | <permissions> |
|
||||
| password | <password> |
|
||||
| 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 | <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 public WebDAV API
|
||||
Then the HTTP status code should be "200"
|
||||
And the downloaded content should be "some content"
|
||||
Examples:
|
||||
| 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 | <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:
|
||||
| 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 sent the following space share invitation:
|
||||
| space | edit space |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <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 "<http-status-code>"
|
||||
And the OCS status code should be "<ocs-status-code>"
|
||||
Examples:
|
||||
| space-role | http-status-code | ocs-status-code |
|
||||
| Manager | 200 | 200 |
|
||||
| Space Editor | 401 | 997 |
|
||||
| Space Viewer | 401 | 997 |
|
||||
@@ -0,0 +1,94 @@
|
||||
Feature: Preview file in project space
|
||||
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
|
||||
|
||||
Background:
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Alice |
|
||||
And the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
|
||||
And user "Alice" has created a space "previews of the files" with the default quota using the Graph API
|
||||
And using spaces DAV path
|
||||
|
||||
|
||||
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 "<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:
|
||||
| file-name | width | height |
|
||||
| /file.txt | 36 | 36 |
|
||||
| /name with spaces.txt | 1200 | 1200 |
|
||||
|
||||
|
||||
Scenario Outline: user can preview image files in the project space
|
||||
Given using spaces DAV path
|
||||
And user "Alice" has uploaded a file from "<source>" to "<destination>" via TUS inside of the space "previews of the files" using the WebDAV API
|
||||
When user "Alice" downloads the preview of "<destination>" of the space "previews of the files" with width "<width>" and height "<height>" using the WebDAV API
|
||||
Then the HTTP status code should be "200"
|
||||
Examples:
|
||||
| source | destination | width | height |
|
||||
| filesForUpload/testavatar.png | testavatar.png | 36 | 36 |
|
||||
| filesForUpload/testavatar.png | testavatar.png | 1200 | 1200 |
|
||||
| filesForUpload/testavatar.png | testavatar.png | 1920 | 1920 |
|
||||
| filesForUpload/testavatar.jpg | testavatar.jpg | 36 | 36 |
|
||||
| filesForUpload/testavatar.jpg | testavatar.jpg | 1200 | 1200 |
|
||||
| filesForUpload/testavatar.jpg | testavatar.jpg | 1920 | 1920 |
|
||||
| filesForUpload/example.gif | example.gif | 36 | 36 |
|
||||
| filesForUpload/example.gif | example.gif | 1200 | 1200 |
|
||||
| filesForUpload/example.gif | example.gif | 1280 | 1280 |
|
||||
|
||||
|
||||
Scenario Outline: download preview of shared file inside project space
|
||||
Given user "Brian" has been created with default attributes
|
||||
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 sent the following resource share invitation:
|
||||
| resource | <destination> |
|
||||
| space | previews of the files |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Viewer |
|
||||
And user "Brian" has a share "<destination>" synced
|
||||
When user "Brian" downloads the preview of shared resource "/Shares/<destination>" with width "32" and height "32" using the WebDAV API
|
||||
Then the HTTP status code should be "200"
|
||||
And the downloaded image should be "32" pixels wide and "32" pixels high
|
||||
Examples:
|
||||
| source | destination |
|
||||
| filesForUpload/testavatar.png | testavatar.png |
|
||||
| filesForUpload/lorem.txt | lorem.txt |
|
||||
|
||||
@env-config
|
||||
Scenario Outline: download preview of shared file shared via Secure viewer permission role
|
||||
Given user "Brian" has been created with default attributes
|
||||
And the administrator has enabled the permissions role "Secure Viewer"
|
||||
And user "Alice" has uploaded a file from "<source>" to "<destination>" via TUS inside of the space "Alice Hansen" using the WebDAV API
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | <destination> |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Secure Viewer |
|
||||
And user "Brian" has a share "<destination>" synced
|
||||
When user "Brian" downloads the preview of shared resource "/Shares/<destination>" with width "32" and height "32" using the WebDAV API
|
||||
Then the HTTP status code should be "403"
|
||||
Examples:
|
||||
| source | destination |
|
||||
| filesForUpload/testavatar.png | testavatar.png |
|
||||
| filesForUpload/lorem.txt | lorem.txt |
|
||||
|
||||
|
||||
Scenario: download preview of file inside shared folder in project space
|
||||
Given user "Brian" has been created with default attributes
|
||||
And user "Alice" has created a folder "folder" in space "previews of the files"
|
||||
And user "Alice" has uploaded a file inside space "previews of the files" with content "test" to "/folder/lorem.txt"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | /folder |
|
||||
| space | previews of the files |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Viewer |
|
||||
And user "Brian" has a share "folder" synced
|
||||
When user "Brian" downloads the preview of shared resource "Shares/folder/lorem.txt" with width "32" and height "32" using the WebDAV API
|
||||
Then the HTTP status code should be "200"
|
||||
And the downloaded image should be "32" pixels wide and "32" pixels high
|
||||
@@ -0,0 +1,525 @@
|
||||
Feature: List and create spaces
|
||||
As a user
|
||||
I want to be able to list project spaces
|
||||
So that I can retrieve the information about them
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes
|
||||
And using spaces DAV path
|
||||
|
||||
|
||||
Scenario: ordinary user can request information about their Space via the Graph API
|
||||
When user "Alice" lists all available spaces via the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON response should contain space called "Alice Hansen" and match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"driveType",
|
||||
"driveAlias",
|
||||
"name",
|
||||
"id",
|
||||
"quota",
|
||||
"root",
|
||||
"webUrl"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["Alice Hansen"]
|
||||
},
|
||||
"driveType": {
|
||||
"type": "string",
|
||||
"enum": ["personal"]
|
||||
},
|
||||
"driveAlias": {
|
||||
"type": "string",
|
||||
"enum": ["personal/alice"]
|
||||
},
|
||||
"id": {
|
||||
"type": "string",
|
||||
"enum": ["%space_id%"]
|
||||
},
|
||||
"quota": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"state"
|
||||
],
|
||||
"properties": {
|
||||
"state": {
|
||||
"type": "string",
|
||||
"enum": ["normal"]
|
||||
}
|
||||
}
|
||||
},
|
||||
"root": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"webDavUrl"
|
||||
],
|
||||
"properties": {
|
||||
"webDavUrl": {
|
||||
"type": "string",
|
||||
"enum": ["%base_url%/dav/spaces/%space_id%"]
|
||||
}
|
||||
}
|
||||
},
|
||||
"webUrl": {
|
||||
"type": "string",
|
||||
"enum": ["%base_url%/f/%space_id%"]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
|
||||
|
||||
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 user "Brian" has created folder "folder"
|
||||
And user "Brian" has sent the following resource share invitation:
|
||||
| resource | folder |
|
||||
| space | Personal |
|
||||
| sharee | Alice |
|
||||
| shareType | user |
|
||||
| permissionsRole | Viewer |
|
||||
And user "Alice" has a share "folder" synced
|
||||
When user "Alice" lists all available spaces via the Graph API with query "$filter=driveType eq 'personal'"
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON response should contain space called "Alice Hansen" and match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"driveType",
|
||||
"driveAlias",
|
||||
"name",
|
||||
"id",
|
||||
"quota",
|
||||
"root"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["Alice Hansen"]
|
||||
},
|
||||
"driveType": {
|
||||
"type": "string",
|
||||
"enum": ["personal"]
|
||||
},
|
||||
"driveAlias": {
|
||||
"type": "string",
|
||||
"enum": ["personal/alice"]
|
||||
},
|
||||
"id": {
|
||||
"type": "string",
|
||||
"enum": ["%space_id%"]
|
||||
},
|
||||
"quota": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"state"
|
||||
],
|
||||
"properties": {
|
||||
"state": {
|
||||
"type": "string",
|
||||
"enum": ["normal"]
|
||||
}
|
||||
}
|
||||
},
|
||||
"root": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"webDavUrl"
|
||||
],
|
||||
"properties": {
|
||||
"webDavUrl": {
|
||||
"type": "string",
|
||||
"enum": ["%base_url%/dav/spaces/%space_id%"]
|
||||
}
|
||||
}
|
||||
},
|
||||
"webUrl": {
|
||||
"type": "string",
|
||||
"enum": ["%base_url%/f/%space_id%"]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
And the json response should not contain a space with name "Shares"
|
||||
And the json response should only contain spaces of type "personal"
|
||||
|
||||
|
||||
Scenario: ordinary user will not see any space when using a filter for project
|
||||
Given the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
|
||||
And user "Alice" has created a space "my project" of type "project" with quota "20"
|
||||
When user "Alice" lists all available spaces via the Graph API with query "$filter=driveType eq 'project'"
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON response should contain space called "my project" and match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"driveType",
|
||||
"name",
|
||||
"id"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["my project"]
|
||||
},
|
||||
"driveType": {
|
||||
"type": "string",
|
||||
"enum": ["project"]
|
||||
},
|
||||
"id": {
|
||||
"type": "string",
|
||||
"enum": ["%space_id%"]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
And the json response should not contain a space with name "Alice Hansen"
|
||||
|
||||
|
||||
Scenario: ordinary user can access their space via the webDav API
|
||||
When user "Alice" lists all available spaces via the Graph 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"
|
||||
|
||||
|
||||
Scenario: user can list his personal space via multiple endpoints
|
||||
When user "Alice" lists all available spaces via the Graph API with query "$filter=driveType eq 'personal'"
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON response should contain space called "Alice Hansen" owned by "Alice" and match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"driveType",
|
||||
"name",
|
||||
"root",
|
||||
"owner",
|
||||
"webUrl"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["Alice Hansen"]
|
||||
},
|
||||
"driveType": {
|
||||
"type": "string",
|
||||
"enum": ["personal"]
|
||||
},
|
||||
"root": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"webDavUrl"
|
||||
],
|
||||
"properties": {
|
||||
"webDavUrl": {
|
||||
"type": "string",
|
||||
"enum": ["%base_url%/dav/spaces/%space_id%"]
|
||||
}
|
||||
}
|
||||
},
|
||||
"owner": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"user"
|
||||
],
|
||||
"properties": {
|
||||
"user": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"id"
|
||||
],
|
||||
"properties": {
|
||||
"id": {
|
||||
"type": "string",
|
||||
"enum": ["%user_id%"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"webUrl": {
|
||||
"type": "string",
|
||||
"enum": ["%base_url%/f/%space_id%"]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
When user "Alice" looks up the single space "Alice Hansen" via the Graph API by using its id
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON response should contain space called "Alice Hansen" and match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"driveType",
|
||||
"name",
|
||||
"root",
|
||||
"webUrl"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["Alice Hansen"]
|
||||
},
|
||||
"driveType": {
|
||||
"type": "string",
|
||||
"enum": ["personal"]
|
||||
},
|
||||
"root": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"webDavUrl"
|
||||
],
|
||||
"properties": {
|
||||
"webDavUrl": {
|
||||
"type": "string",
|
||||
"enum": ["%base_url%/dav/spaces/%space_id%"]
|
||||
}
|
||||
}
|
||||
},
|
||||
"webUrl": {
|
||||
"type": "string",
|
||||
"enum": ["%base_url%/f/%space_id%"]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
|
||||
|
||||
Scenario Outline: user can list his created spaces via multiple endpoints
|
||||
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
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"driveType",
|
||||
"driveAlias",
|
||||
"name",
|
||||
"id",
|
||||
"quota",
|
||||
"root",
|
||||
"webUrl"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["Project Venus"]
|
||||
},
|
||||
"driveType": {
|
||||
"type": "string",
|
||||
"enum": ["project"]
|
||||
},
|
||||
"driveAlias": {
|
||||
"type": "string",
|
||||
"enum": ["project/project-venus"]
|
||||
},
|
||||
"id": {
|
||||
"type": "string",
|
||||
"enum": ["%space_id%"]
|
||||
},
|
||||
"quota": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"total"
|
||||
],
|
||||
"properties": {
|
||||
"total": {
|
||||
"type": "number",
|
||||
"enum": [2000]
|
||||
}
|
||||
}
|
||||
},
|
||||
"root": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"webDavUrl"
|
||||
],
|
||||
"properties": {
|
||||
"webDavUrl": {
|
||||
"type": "string",
|
||||
"enum": ["%base_url%/dav/spaces/%space_id%"]
|
||||
}
|
||||
}
|
||||
},
|
||||
"webUrl": {
|
||||
"type": "string",
|
||||
"enum": ["%base_url%/f/%space_id%"]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
When user "Alice" looks up the single space "Project Venus" via the Graph API by using its id
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON response should contain space called "Project Venus" and match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"driveType",
|
||||
"driveAlias",
|
||||
"name",
|
||||
"id",
|
||||
"quota",
|
||||
"root",
|
||||
"webUrl"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["Project Venus"]
|
||||
},
|
||||
"driveType": {
|
||||
"type": "string",
|
||||
"enum": ["project"]
|
||||
},
|
||||
"driveAlias": {
|
||||
"type": "string",
|
||||
"enum": ["project/project-venus"]
|
||||
},
|
||||
"id": {
|
||||
"type": "string",
|
||||
"enum": ["%space_id%"]
|
||||
},
|
||||
"quota": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"total"
|
||||
],
|
||||
"properties": {
|
||||
"total": {
|
||||
"type": "number",
|
||||
"enum": [2000]
|
||||
}
|
||||
}
|
||||
},
|
||||
"root": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"webDavUrl"
|
||||
],
|
||||
"properties": {
|
||||
"webDavUrl": {
|
||||
"type": "string",
|
||||
"enum": ["%base_url%/dav/spaces/%space_id%"]
|
||||
}
|
||||
}
|
||||
},
|
||||
"webUrl": {
|
||||
"type": "string",
|
||||
"enum": ["%base_url%/f/%space_id%"]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| 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 "<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 response should not contain a space with name "Project Venus"
|
||||
Examples:
|
||||
| user-role |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
@issue-7160
|
||||
Scenario Outline: get share jail space information of the user when user has a pending share
|
||||
Given user "Brian" has been created with default attributes
|
||||
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 "<user-role>" to user "Alice" using the Graph API
|
||||
And user "Brian" has sent the following resource share invitation:
|
||||
| resource | test.txt |
|
||||
| space | Personal |
|
||||
| sharee | Alice |
|
||||
| shareType | user |
|
||||
| permissionsRole | Viewer |
|
||||
When user "Alice" lists all available spaces via the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON response should contain space called "Shares" owned by "Alice" and match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"driveType",
|
||||
"driveAlias",
|
||||
"name",
|
||||
"id",
|
||||
"root",
|
||||
"webUrl"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["Shares"]
|
||||
},
|
||||
"driveType": {
|
||||
"type": "string",
|
||||
"enum": ["virtual"]
|
||||
},
|
||||
"driveAlias": {
|
||||
"type": "string",
|
||||
"enum": ["virtual/shares"]
|
||||
},
|
||||
"id": {
|
||||
"type": "string",
|
||||
"enum": ["%space_id%"]
|
||||
},
|
||||
"quota": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"state"
|
||||
],
|
||||
"properties": {
|
||||
"state": {
|
||||
"type": "string",
|
||||
"enum": ["normal"]
|
||||
}
|
||||
}
|
||||
},
|
||||
"root": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"eTag",
|
||||
"webDavUrl"
|
||||
],
|
||||
"properties": {
|
||||
"eTag": {
|
||||
"type": "string",
|
||||
"enum": ["%space_etag%"]
|
||||
},
|
||||
"webDavUrl": {
|
||||
"type": "string",
|
||||
"enum": ["%base_url%/dav/spaces/%space_id%"]
|
||||
}
|
||||
}
|
||||
},
|
||||
"webUrl": {
|
||||
"type": "string",
|
||||
"enum": ["%base_url%/f/%space_id%"]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| user-role |
|
||||
| Admin |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
@@ -0,0 +1,43 @@
|
||||
@env-config
|
||||
Feature: public link for a space
|
||||
|
||||
Background:
|
||||
Given the config "OC_SHARING_PUBLIC_SHARE_MUST_HAVE_PASSWORD" has been set to "false"
|
||||
And these users have been created with default attributes:
|
||||
| username |
|
||||
| Alice |
|
||||
And using spaces DAV path
|
||||
And the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
|
||||
And user "Alice" has created a space "public space" with the default quota using the Graph API
|
||||
And user "Alice" has created the following space link share:
|
||||
| space | public space |
|
||||
| permissionsRole | view |
|
||||
And using SharingNG
|
||||
|
||||
@issue-10331
|
||||
Scenario: public tries to upload a file in the public space
|
||||
When the public uploads file "test.txt" with content "test" using the public WebDAV API
|
||||
And the HTTP status code should be "403"
|
||||
|
||||
@issue-10331
|
||||
Scenario: public tries to create a folder in the public space
|
||||
When the public creates folder "created-by-public" using the public WebDAV API
|
||||
And the HTTP status code should be "403"
|
||||
|
||||
@issue-10331
|
||||
Scenario: public tries to delete a file in the public space
|
||||
Given user "Alice" has uploaded a file inside space "public space" with content "some content" to "test.txt"
|
||||
When the public deletes file "test.txt" from the last public link share using the public WebDAV API
|
||||
And the HTTP status code should be "403"
|
||||
|
||||
@issue-10331
|
||||
Scenario: public tries to delete a folder in the public space
|
||||
And user "Alice" has created a folder "/public-folder" in space "public space"
|
||||
When the public deletes folder "public-folder" from the last public link share using the public WebDAV API
|
||||
And the HTTP status code should be "403"
|
||||
|
||||
@issue-10331
|
||||
Scenario: public tries to change content of a resources in the public space
|
||||
Given user "Alice" has uploaded a file inside space "public space" with content "some content" to "test.txt"
|
||||
When the public overwrites file "test.txt" with content "public content" using the public WebDAV API
|
||||
And the HTTP status code should be "403"
|
||||
@@ -0,0 +1,147 @@
|
||||
Feature: State of the quota
|
||||
As a user
|
||||
I want to be able to see the state of the quota
|
||||
So that I will not let the quota overrun
|
||||
|
||||
|
||||
quota state indication:
|
||||
| 0 - 75% | normal |
|
||||
| 76 - 90% | nearing |
|
||||
| 91 - 99% | critical |
|
||||
| 100 % | exceeded |
|
||||
|
||||
Background:
|
||||
Given user "Alice" has been created with default attributes
|
||||
And the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
|
||||
And using spaces DAV path
|
||||
|
||||
|
||||
Scenario Outline: quota information is returned in the list of spaces returned via the Graph API
|
||||
Given user "Alice" has created a space "<space-name>" of type "project" with quota "<quota>"
|
||||
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 "<space-name>" and match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"name",
|
||||
"quota"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["<space-name>"]
|
||||
},
|
||||
"quota": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"state",
|
||||
"total",
|
||||
"remaining",
|
||||
"used"
|
||||
],
|
||||
"properties": {
|
||||
"state" : {
|
||||
"type": "string",
|
||||
"enum": ["<state>"]
|
||||
},
|
||||
"total" : {
|
||||
"type": "number",
|
||||
"enum": [<quota>]
|
||||
},
|
||||
"remaining" : {
|
||||
"type": "number",
|
||||
"enum": [<remaining>]
|
||||
},
|
||||
"used": {
|
||||
"type": "number",
|
||||
"enum": [<used>]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| space-name | file-content | state | remaining | used | quota |
|
||||
| Quota1% | 1 | normal | 99 | 1 | 100 |
|
||||
| Quota75% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12345 | normal | 25 | 75 | 100 |
|
||||
| Quota76% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456 | nearing | 24 | 76 | 100 |
|
||||
| Quota90% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1234567890 | nearing | 10 | 90 | 100 |
|
||||
| Quota91% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1 | critical | 9 | 91 | 100 |
|
||||
| Quota99% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 | critical | 1 | 99 | 100 |
|
||||
| Quota100% | 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 1234567890 | exceeded | 0 | 100 | 100 |
|
||||
| Quota1 | 0 | normal | 2499999999999 | 1 | 2500000000000 |
|
||||
|
||||
|
||||
Scenario: file cannot be uploaded if there is insufficient quota
|
||||
Given user "Alice" has created a space "Project Alfa" of type "project" with quota "10"
|
||||
When user "Alice" uploads a file inside space "Project Alfa" with content "More than 10 bytes" to "test.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "507"
|
||||
|
||||
|
||||
Scenario: folder can be created even if there is insufficient quota for file content
|
||||
Given user "Alice" has created a space "Project Beta" of type "project" with quota "7"
|
||||
And user "Alice" has uploaded a file inside space "Project Beta" with content "7 bytes" to "test.txt"
|
||||
When user "Alice" creates a folder "NewFolder" in space "Project Beta" using the WebDav Api
|
||||
Then the HTTP status code should be "201"
|
||||
And for user "Alice" the space "Project Beta" should contain these entries:
|
||||
| NewFolder |
|
||||
|
||||
|
||||
Scenario: file can be overwritten if there is enough quota
|
||||
Given user "Alice" has created a space "Project Gamma" of type "project" with quota "10"
|
||||
And user "Alice" has uploaded a file inside space "Project Gamma" with content "7 bytes" to "test.txt"
|
||||
When user "Alice" uploads a file inside space "Project Gamma" with content "0010 bytes" to "test.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "204"
|
||||
|
||||
|
||||
Scenario: file cannot be overwritten if there is insufficient quota
|
||||
Given user "Alice" has created a space "Project Delta" of type "project" with quota "10"
|
||||
And user "Alice" has uploaded a file inside space "Project Delta" with content "7 bytes" to "test.txt"
|
||||
When user "Alice" uploads a file inside space "Project Delta" with content "00011 bytes" to "test.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "507"
|
||||
|
||||
|
||||
Scenario Outline: check the relative amount of quota of personal space
|
||||
Given user "Admin" has changed the quota of the personal space of user "Alice" to "10000"
|
||||
And user "Alice" has uploaded file "<file-upload>" to "/demo.txt"
|
||||
When the user "Alice" requests these endpoints with "GET" with basic auth
|
||||
| endpoint |
|
||||
| <end-point> |
|
||||
Then the HTTP status code should be "200"
|
||||
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-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
|
||||
Scenario: upload a file by setting КуСфера spaces max quota
|
||||
Given the config "OC_SPACES_MAX_QUOTA" has been set to "10"
|
||||
And user "Brian" has been created with default attributes
|
||||
When user "Brian" uploads file with content "more than 10 bytes content" to "lorem.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "507"
|
||||
|
||||
@env-config
|
||||
Scenario: try to create a space with quota greater than КуСфера spaces max quota
|
||||
Given the config "OC_SPACES_MAX_QUOTA" has been set to "50"
|
||||
And user "Brian" has been created with default attributes
|
||||
And the administrator has assigned the role "Space Admin" to user "Brian" using the Graph API
|
||||
When user "Brian" tries to create a space "new space" of type "project" with quota "51" using the Graph API
|
||||
Then the HTTP status code should be "400"
|
||||
And the user "Brian" should not have a space called "new space"
|
||||
|
||||
|
||||
Scenario: user can restore a file version even if there is not enough quota to do so
|
||||
Given user "Admin" has changed the quota of the personal space of user "Alice" to "30"
|
||||
And user "Alice" has uploaded file with content "file is less than 30 bytes" to "/file.txt"
|
||||
And user "Alice" has uploaded file with content "reduceContent" to "/file.txt"
|
||||
And user "Alice" has uploaded file with content "some content" to "newFile.txt"
|
||||
When user "Alice" restores version index "1" of file "/file.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "204"
|
||||
And the content of file "/file.txt" for user "Alice" should be "file is less than 30 bytes"
|
||||
@@ -0,0 +1,79 @@
|
||||
Feature: Remove files, folder
|
||||
As a user
|
||||
I want to be able to remove files, folders
|
||||
So that I can remove unnecessary objects
|
||||
|
||||
Background:
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
And using spaces DAV path
|
||||
And the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
|
||||
And user "Alice" has created a space "delete objects" with the default quota using the Graph API
|
||||
And user "Alice" has created a folder "folderForDeleting/sub1/sub2" in space "delete objects"
|
||||
And user "Alice" has uploaded a file inside space "delete objects" with content "some content" to "text.txt"
|
||||
|
||||
|
||||
Scenario Outline: user deletes a folder with some subfolders in a space via the webDav API
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | delete objects |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <space-role> |
|
||||
When user "<user>" removes the folder "folderForDeleting" from space "delete objects"
|
||||
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" <should-or-not-be-in-trash> exist in the trashbin of the space "delete objects"
|
||||
Examples:
|
||||
| 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 | Space Editor | 204 | should not | should |
|
||||
| Brian | Space Viewer | 403 | should | should not |
|
||||
|
||||
|
||||
Scenario Outline: user deletes a subfolder in a space via the webDav API
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | delete objects |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <space-role> |
|
||||
When user "<user>" removes the folder "folderForDeleting/sub1" from space "delete objects"
|
||||
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" <should-or-not-be-in-space> contain these entries:
|
||||
| sub1 |
|
||||
And as "<user>" folder "sub1" <should-or-not-be-in-trash> exist in the trashbin of the space "delete objects"
|
||||
Examples:
|
||||
| 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 | Space Editor | 204 | should not | should |
|
||||
| Brian | Space Viewer | 403 | should | should not |
|
||||
|
||||
|
||||
Scenario Outline: user deletes a file in a space via the webDav API
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | delete objects |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <space-role> |
|
||||
When user "<user>" removes the file "text.txt" from space "delete objects"
|
||||
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" <should-or-not-be-in-trash> exist in the trashbin of the space "delete objects"
|
||||
Examples:
|
||||
| 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 | Space Editor | 204 | should not | should |
|
||||
| Brian | Space Viewer | 403 | should | should not |
|
||||
|
||||
|
||||
Scenario: try to delete an empty string folder from a space
|
||||
When user "Alice" removes the folder "" from space "delete objects"
|
||||
Then the HTTP status code should be "405"
|
||||
@@ -0,0 +1,98 @@
|
||||
Feature: Restoring space
|
||||
As a manager of space
|
||||
I want to be able to restore a disabled space
|
||||
So that I can retrieve all the data belonging to the space
|
||||
|
||||
Background:
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
| Bob |
|
||||
And the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
|
||||
And user "Alice" has created a space "restore a space" of type "project" with quota "10"
|
||||
And using spaces DAV path
|
||||
|
||||
|
||||
Scenario: owner can restore a space via the Graph API
|
||||
Given user "Alice" has disabled a space "restore a space"
|
||||
When user "Alice" restores a disabled space "restore a space"
|
||||
Then the HTTP status code should be "200"
|
||||
|
||||
|
||||
Scenario: participants can see the data after the space is restored
|
||||
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 sent the following space share invitation:
|
||||
| space | restore a space |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Space Editor |
|
||||
And user "Alice" has sent the following space share invitation:
|
||||
| space | restore a space |
|
||||
| sharee | Bob |
|
||||
| shareType | user |
|
||||
| permissionsRole | Space Viewer |
|
||||
And user "Alice" has disabled a space "restore a space"
|
||||
When user "Alice" restores a disabled space "restore a space"
|
||||
Then for user "Alice" the space "restore a space" should contain these entries:
|
||||
| test.txt |
|
||||
| mainFolder |
|
||||
And for user "Brian" the space "restore a space" should contain these entries:
|
||||
| test.txt |
|
||||
| mainFolder |
|
||||
And for user "Bob" the space "restore a space" should contain these entries:
|
||||
| test.txt |
|
||||
| mainFolder |
|
||||
|
||||
|
||||
Scenario: participant can create data in the space after restoring
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | restore a space |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Space Editor |
|
||||
And user "Alice" has disabled a space "restore a space"
|
||||
And user "Alice" has restored a disabled space "restore a space"
|
||||
When user "Brian" creates a folder "mainFolder" in space "restore a space" using the WebDav Api
|
||||
And user "Brian" uploads a file inside space "restore a space" with content "test" to "test.txt" using the WebDAV API
|
||||
Then for user "Brian" the space "restore a space" should contain these entries:
|
||||
| test.txt |
|
||||
| mainFolder |
|
||||
|
||||
|
||||
Scenario Outline: user without space manager role cannot restore space
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | restore a space |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <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:
|
||||
| space-role |
|
||||
| Space Viewer |
|
||||
| Space Editor |
|
||||
|
||||
|
||||
Scenario Outline: user with role user and user light cannot restore space
|
||||
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:
|
||||
| user-role |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
@issue-5872
|
||||
Scenario Outline: admin and space admin can restore other space
|
||||
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:
|
||||
| user-role |
|
||||
| Admin |
|
||||
| Space Admin |
|
||||
@@ -0,0 +1,167 @@
|
||||
Feature: Set quota
|
||||
As a user
|
||||
I want to set quota to different users
|
||||
So that users can only take up a certain amount of storage space
|
||||
|
||||
Background:
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
|
||||
|
||||
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 "<user-role>" to user "Brian" using the Graph API
|
||||
When user "Alice" changes the quota of the personal space of user "Brian" to "100" using the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"quota"
|
||||
],
|
||||
"properties": {
|
||||
"quota": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"total"
|
||||
],
|
||||
"properties": {
|
||||
"total" : {
|
||||
"type": "number",
|
||||
"enum": [100]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| user-role |
|
||||
| Admin |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
|
||||
|
||||
Scenario Outline: non-admin user tries to set the personal space quota of other users
|
||||
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 personal space of user "Brian" to "100" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
Examples:
|
||||
| user-role-2 | user-role |
|
||||
| Space Admin | Admin |
|
||||
| Space Admin | Space Admin |
|
||||
| Space Admin | User |
|
||||
| Space Admin | User Light |
|
||||
| User | Admin |
|
||||
| User | Space Admin |
|
||||
| User | User |
|
||||
| User | User Light |
|
||||
| User Light | Admin |
|
||||
| User Light | Space Admin |
|
||||
| User Light | User |
|
||||
| User Light | User Light |
|
||||
|
||||
|
||||
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 "<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"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"name",
|
||||
"quota"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["Project Jupiter"]
|
||||
},
|
||||
"quota": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"total"
|
||||
],
|
||||
"properties": {
|
||||
"total" : {
|
||||
"type": "number",
|
||||
"enum": [100]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
Examples:
|
||||
| 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 "<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 sent the following space share invitation:
|
||||
| space | Project Jupiter |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <space-role> |
|
||||
When user "Brian" changes the quota of the "Project Jupiter" space to "100"
|
||||
Then the HTTP status code should be "403"
|
||||
Examples:
|
||||
| user-role | space-role |
|
||||
| User | Space Viewer |
|
||||
| User | Space Editor |
|
||||
| User | Manager |
|
||||
| User Light | Space Viewer |
|
||||
| User Light | Space Editor |
|
||||
| User Light | Manager |
|
||||
|
||||
|
||||
Scenario: admin user can set their own personal space quota
|
||||
When user "Admin" changes the quota of the personal space of user "Alice" to "100" using the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"quota"
|
||||
],
|
||||
"properties": {
|
||||
"quota": {
|
||||
"type": "object",
|
||||
"required": [
|
||||
"total"
|
||||
],
|
||||
"properties": {
|
||||
"total" : {
|
||||
"type": "number",
|
||||
"enum": [100]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
|
||||
|
||||
Scenario Outline: non-admin user tries to set their own personal space quota
|
||||
Given the administrator has assigned the role "<user-role>" to user "Alice" using the Graph API
|
||||
When user "Alice" changes the quota of the personal space of user "Alice" to "100" using the Graph API
|
||||
Then the HTTP status code should be "403"
|
||||
Examples:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| User |
|
||||
| User Light |
|
||||
@@ -0,0 +1,185 @@
|
||||
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
|
||||
|
||||
Background:
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
| Carol |
|
||||
And using spaces DAV path
|
||||
And the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
|
||||
And the administrator has assigned the role "Space Admin" to user "Brian" using the Graph API
|
||||
And user "Alice" has created a space "Project" of type "project" with quota "10"
|
||||
|
||||
|
||||
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 Graph API with query "$filter=driveType eq 'project'"
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON response should contain space called "Project" and match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"driveType",
|
||||
"name",
|
||||
"id"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["Project"]
|
||||
},
|
||||
"driveType": {
|
||||
"type": "string",
|
||||
"enum": ["project"]
|
||||
},
|
||||
"id": {
|
||||
"type": "string",
|
||||
"enum": ["%space_id%"]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
And the json response should not contain a space with name "Alice Hansen"
|
||||
|
||||
|
||||
Scenario: space admin user can see another personal spaces
|
||||
When user "Brian" lists all spaces via the Graph API with query "$filter=driveType eq 'personal'"
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON response should contain space called "Alice Hansen" and match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"driveType",
|
||||
"name",
|
||||
"id"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["Alice Hansen"]
|
||||
},
|
||||
"driveType": {
|
||||
"type": "string",
|
||||
"enum": ["personal"]
|
||||
},
|
||||
"id": {
|
||||
"type": "string",
|
||||
"enum": ["%space_id%"]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
And the json response should not contain a space with name "Project"
|
||||
|
||||
|
||||
Scenario: user without space admin permission cannot see another spaces
|
||||
When user "Carol" tries to list all spaces via the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the json response should not contain a space with name "Project"
|
||||
And the json response should not contain a space with name "Alice Hansen"
|
||||
|
||||
|
||||
Scenario: space admin user changes the name of the project space
|
||||
When user "Brian" changes the name of the "Project" space to "New Name" owned by user "Alice"
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"name"
|
||||
],
|
||||
"properties": {
|
||||
"name": {
|
||||
"type": "string",
|
||||
"enum": ["New Name"]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
|
||||
|
||||
Scenario: user without space admin permission tries to change the name of the project space
|
||||
When user "Carol" tries to change the name of the "Project" space to "New Name" owned by user "Alice"
|
||||
Then the HTTP status code should be "404"
|
||||
And the user "Alice" should have a space called "Project"
|
||||
|
||||
|
||||
Scenario: space admin user changes the description of the project space
|
||||
When user "Brian" changes the description of the "Project" space to "New description" owned by user "Alice"
|
||||
Then the HTTP status code should be "200"
|
||||
And the JSON data of the response should match
|
||||
"""
|
||||
{
|
||||
"type": "object",
|
||||
"required": [
|
||||
"description"
|
||||
],
|
||||
"properties": {
|
||||
"description": {
|
||||
"type": "string",
|
||||
"enum": ["New description"]
|
||||
}
|
||||
}
|
||||
}
|
||||
"""
|
||||
|
||||
|
||||
Scenario: user without space admin permission tries to change the description of the project space
|
||||
Given user "Alice" has changed the description of the "Project" space to "old description"
|
||||
When user "Carol" tries to change the description of the "Project" space to "New description" owned by user "Alice"
|
||||
Then the HTTP status code should be "404"
|
||||
|
||||
|
||||
Scenario: space admin user disables the project space
|
||||
When user "Brian" disables a space "Project" owned by user "Alice"
|
||||
Then the HTTP status code should be "204"
|
||||
And the user "Brian" should not have a space called "Project"
|
||||
|
||||
|
||||
Scenario: user without space admin permission tries to disable the project space
|
||||
When user "Carol" tries to disable a space "Project" owned by user "Alice"
|
||||
Then the HTTP status code should be "404"
|
||||
|
||||
|
||||
Scenario Outline: space admin user tries to disable the personal space
|
||||
When user "<user>" disables a space "Alice Hansen" owned by user "Alice"
|
||||
Then the HTTP status code should be "404"
|
||||
Examples:
|
||||
| user |
|
||||
| Brian |
|
||||
| Carol |
|
||||
|
||||
|
||||
Scenario: space admin user deletes the project space
|
||||
Given user "Alice" has disabled a space "Project"
|
||||
When user "Brian" deletes a space "Project" owned by user "Alice"
|
||||
Then the HTTP status code should be "204"
|
||||
And the user "Alice" should not have a space called "Project"
|
||||
|
||||
|
||||
Scenario: user without space admin permission tries to delete the project space
|
||||
Given user "Alice" has disabled a space "Project"
|
||||
When user "Carol" tries to delete a space "Project" owned by user "Alice"
|
||||
Then the HTTP status code should be "404"
|
||||
|
||||
|
||||
Scenario: space admin user enables the project space
|
||||
Given user "Alice" has disabled a space "Project"
|
||||
When user "Brian" restores a disabled space "Project" owned by user "Alice"
|
||||
Then the HTTP status code should be "200"
|
||||
|
||||
|
||||
Scenario: user without space admin permission tries to enable the project space
|
||||
Given user "Alice" has disabled a space "Project"
|
||||
When user "Carol" tries to restore a disabled space "Project" owned by user "Alice"
|
||||
Then the HTTP status code should be "404"
|
||||
And the user "Alice" should have a space "Project" in the disable state
|
||||
@@ -0,0 +1,305 @@
|
||||
Feature: Tag
|
||||
As a user
|
||||
I want to tag resources
|
||||
So that I can sort and search them quickly
|
||||
|
||||
Background:
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
And using spaces DAV path
|
||||
And the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
|
||||
And user "Alice" has created a space "use-tag" with the default quota using the Graph API
|
||||
And user "Alice" has created a folder "folderMain" in space "use-tag"
|
||||
And user "Alice" has uploaded a file inside space "use-tag" with content "some content" to "folderMain/insideTheFolder.txt"
|
||||
|
||||
|
||||
Scenario: user creates tags for resources in the project space
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | use-tag |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Space Viewer |
|
||||
When user "Alice" creates the following tags for folder "folderMain" of space "use-tag":
|
||||
| tag level#1 |
|
||||
| tag with symbols @^$#^%$@%!_+) |
|
||||
Then the HTTP status code should be "200"
|
||||
When user "Alice" sends PROPFIND request from the space "use-tag" to the resource "folderMain" with depth "0" using the WebDAV API
|
||||
Then the HTTP status code should be "207"
|
||||
And as user "Alice" the PROPFIND response should contain a resource "folderMain" with these key and value pairs:
|
||||
| key | value |
|
||||
| oc:tags | tag level#1,tag with symbols @^$#^%$@%!_+) |
|
||||
When user "Alice" creates the following tags for file "folderMain/insideTheFolder.txt" of space "use-tag":
|
||||
| fileTag |
|
||||
Then the HTTP status code should be "200"
|
||||
When user "Brian" sends PROPFIND request from the space "use-tag" to the resource "folderMain/insideTheFolder.txt" with depth "0" using the WebDAV API
|
||||
Then the HTTP status code should be "207"
|
||||
And as user "Alice" the PROPFIND response should contain a resource "insideTheFolder.txt" with these key and value pairs:
|
||||
| key | value |
|
||||
| oc:tags | fileTag |
|
||||
When user "Alice" lists all available tags via the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the response should contain following tags:
|
||||
| tag level#1 |
|
||||
| tag with symbols @^$#^%$@%!_+) |
|
||||
| fileTag |
|
||||
When user "Alice" lists all available tags via the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the response should contain following tags:
|
||||
| tag level#1 |
|
||||
| tag with symbols @^$#^%$@%!_+) |
|
||||
| fileTag |
|
||||
|
||||
|
||||
Scenario: user creates tags for resources in the personal space
|
||||
Given user "Alice" has created a folder "folderMain" in space "Personal"
|
||||
And user "Alice" has uploaded a file inside space "Personal" with content "some content" to "file.txt"
|
||||
When user "Alice" creates the following tags for folder "folderMain" of space "Personal":
|
||||
| my tag |
|
||||
| important |
|
||||
Then the HTTP status code should be "200"
|
||||
When user "Alice" creates the following tags for file "file.txt" of space "Personal":
|
||||
| fileTag |
|
||||
| tag with symbol @^$#^%$@%!_+) |
|
||||
Then the HTTP status code should be "200"
|
||||
When user "Alice" sends PROPFIND request from the space "Personal" to the resource "folderMain" with depth "0" using the WebDAV API
|
||||
Then the HTTP status code should be "207"
|
||||
And as user "Alice" the PROPFIND response should contain a resource "folderMain" with these key and value pairs:
|
||||
| key | value |
|
||||
| oc:tags | my tag,important |
|
||||
When user "Alice" sends PROPFIND request from the space "Personal" to the resource "file.txt" with depth "0" using the WebDAV API
|
||||
Then the HTTP status code should be "207"
|
||||
And as user "Alice" the PROPFIND response should contain a resource "file.txt" with these key and value pairs:
|
||||
| key | value |
|
||||
| oc:tags | fileTag,tag with symbol @^$#^%$@%!_+) |
|
||||
When user "Alice" lists all available tags via the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the response should contain following tags:
|
||||
| my tag |
|
||||
| important |
|
||||
| fileTag |
|
||||
| tag with symbol @^$#^%$@%!_+) |
|
||||
|
||||
|
||||
Scenario Outline: member of the space tries to create tag
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | use-tag |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <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 "<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 <should-or-not> contain following tags:
|
||||
| tag level#1 |
|
||||
| tag with symbols @^$#^%$@%!_+) |
|
||||
Examples:
|
||||
| space-role | http-status-code | should-or-not |
|
||||
| Space Viewer | 403 | should not |
|
||||
| Space Editor | 200 | should |
|
||||
| Manager | 200 | should |
|
||||
|
||||
|
||||
Scenario: recipient has a created tags if share is accepted
|
||||
Given user "Alice" has created the following tags for folder "folderMain" of the space "use-tag":
|
||||
| folderTag |
|
||||
| marketing |
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | folderMain |
|
||||
| space | use-tag |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Viewer |
|
||||
And user "Brian" has a share "folderMain" synced
|
||||
When user "Brian" lists all available tags via the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the response should contain following tags:
|
||||
| folderTag |
|
||||
| marketing |
|
||||
|
||||
|
||||
Scenario Outline: recipient of the shared resource tries to create a tag
|
||||
Given user "Alice" has sent the following resource share invitation:
|
||||
| resource | folderMain |
|
||||
| space | use-tag |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <permissions-role> |
|
||||
And user "Brian" has a share "folderMain" synced
|
||||
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 "<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 <should-or-not> contain following tags:
|
||||
| tag in a shared resource |
|
||||
| second tag |
|
||||
Examples:
|
||||
| permissions-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 |
|
||||
| Viewer | folder | folderMain | 403 | should not |
|
||||
| Editor | folder | folderMain | 200 | should |
|
||||
|
||||
|
||||
Scenario Outline: recipient of the shared resource tries to remove a tag
|
||||
Given user "Alice" has sent the following resource share invitation:
|
||||
| resource | folderMain |
|
||||
| space | use-tag |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <permissions-role> |
|
||||
And user "Brian" has a share "folderMain" synced
|
||||
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-type> "<resource>" of space "Shares":
|
||||
| tag in a shared resource |
|
||||
| second tag |
|
||||
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 <should-or-not> contain following tags:
|
||||
| tag in a shared resource |
|
||||
| second tag |
|
||||
Examples:
|
||||
| permissions-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 |
|
||||
| Viewer | folder | folderMain | 403 | should |
|
||||
| Editor | folder | folderMain | 200 | should not |
|
||||
|
||||
|
||||
Scenario: user removes folder tags
|
||||
Given user "Alice" has created the following tags for folder "folderMain" of the space "use-tag":
|
||||
| folderTag |
|
||||
| marketing |
|
||||
| development |
|
||||
When user "Alice" removes the following tags for folder "folderMain" of space "use-tag":
|
||||
| folderTag |
|
||||
| marketing |
|
||||
And user "Alice" sends PROPFIND request from the space "use-tag" to the resource "folderMain" with depth "0" using the WebDAV API
|
||||
Then the HTTP status code should be "207"
|
||||
And as user "Alice" the PROPFIND response should contain a resource "folderMain" with these key and value pairs:
|
||||
| key | value |
|
||||
| oc:tags | development |
|
||||
|
||||
|
||||
Scenario: user lists tags after deleting some folder tags
|
||||
Given user "Alice" has created the following tags for folder "folderMain" of the space "use-tag":
|
||||
| folderTag |
|
||||
| marketing |
|
||||
| development |
|
||||
When user "Alice" removes the following tags for folder "folderMain" of space "use-tag":
|
||||
| folderTag |
|
||||
| marketing |
|
||||
Then the HTTP status code should be "200"
|
||||
When user "Alice" lists all available tags via the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the response should contain following tags:
|
||||
| development |
|
||||
And the response should not contain following tags:
|
||||
| folderTag |
|
||||
| marketing |
|
||||
|
||||
|
||||
Scenario: user lists the tags after deleting a folder
|
||||
Given user "Alice" has created the following tags for folder "folderMain" of the space "use-tag":
|
||||
| folderTag |
|
||||
| marketing |
|
||||
When user "Alice" removes the folder "folderMain" from space "use-tag"
|
||||
Then the HTTP status code should be "204"
|
||||
When user "Alice" lists all available tags via the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the response should not contain following tags:
|
||||
| folderTag |
|
||||
| marketing |
|
||||
|
||||
|
||||
Scenario: user lists the tags after deleting a space
|
||||
Given user "Alice" has created the following tags for folder "folderMain" of the space "use-tag":
|
||||
| folderTag |
|
||||
| marketing |
|
||||
And user "Alice" has disabled a space "use-tag"
|
||||
When user "Alice" lists all available tags via the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the response should not contain following tags:
|
||||
| folderTag |
|
||||
| marketing |
|
||||
When user "Alice" deletes a space "use-tag"
|
||||
Then the HTTP status code should be "204"
|
||||
When user "Alice" lists all available tags via the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the response should not contain following tags:
|
||||
| folderTag |
|
||||
| marketing |
|
||||
|
||||
|
||||
Scenario: user lists the tags after restoring a deleted folder
|
||||
Given user "Alice" has created the following tags for folder "folderMain" of the space "use-tag":
|
||||
| folderTag |
|
||||
| marketing |
|
||||
And user "Alice" has removed the folder "folderMain" from space "use-tag"
|
||||
When user "Alice" restores the folder "folderMain" from the trash of the space "use-tag" to "/folderMain"
|
||||
Then the HTTP status code should be "201"
|
||||
When user "Alice" lists all available tags via the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the response should contain following tags:
|
||||
| folderTag |
|
||||
| marketing |
|
||||
|
||||
|
||||
Scenario: user creates a comma-separated list of tags for resources in the project space
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | use-tag |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Space Viewer |
|
||||
When user "Alice" creates the following tags for folder "folderMain" of space "use-tag":
|
||||
| finance,नेपाल |
|
||||
Then the HTTP status code should be "200"
|
||||
When user "Alice" sends PROPFIND request from the space "use-tag" to the resource "folderMain" with depth "0" using the WebDAV API
|
||||
Then the HTTP status code should be "207"
|
||||
And as user "Alice" the PROPFIND response should contain a resource "folderMain" with these key and value pairs:
|
||||
| key | value |
|
||||
| oc:tags | finance,नेपाल |
|
||||
When user "Alice" creates the following tags for file "folderMain/insideTheFolder.txt" of space "use-tag":
|
||||
| file,नेपाल,Tag |
|
||||
Then the HTTP status code should be "200"
|
||||
When user "Brian" sends PROPFIND request from the space "use-tag" to the resource "folderMain/insideTheFolder.txt" with depth "0" using the WebDAV API
|
||||
Then the HTTP status code should be "207"
|
||||
And as user "Alice" the PROPFIND response should contain a resource "insideTheFolder.txt" with these key and value pairs:
|
||||
| key | value |
|
||||
| oc:tags | file,नेपाल,Tag |
|
||||
When user "Alice" lists all available tags via the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the response should contain following tags:
|
||||
| finance |
|
||||
| नेपाल |
|
||||
| file |
|
||||
| Tag |
|
||||
|
||||
|
||||
Scenario: setting a comma-separated list of tags adds to any existing tags on the resource
|
||||
Given user "Alice" has created the following tags for folder "folderMain" of the space "use-tag":
|
||||
| finance,hr |
|
||||
When user "Alice" creates the following tags for folder "folderMain" of space "use-tag":
|
||||
| engineering,finance,qa |
|
||||
Then the HTTP status code should be "200"
|
||||
When user "Alice" sends PROPFIND request from the space "use-tag" to the resource "folderMain" with depth "0" using the WebDAV API
|
||||
Then the HTTP status code should be "207"
|
||||
And as user "Alice" the PROPFIND response should contain a resource "folderMain" with these key and value pairs:
|
||||
| key | value |
|
||||
| oc:tags | engineering,finance,hr,qa |
|
||||
When user "Alice" lists all available tags via the Graph API
|
||||
Then the HTTP status code should be "200"
|
||||
And the response should contain following tags:
|
||||
| engineering |
|
||||
| finance |
|
||||
| hr |
|
||||
| qa |
|
||||
@@ -0,0 +1,121 @@
|
||||
Feature: Restore files, folder
|
||||
As a user with manager and editor role
|
||||
I want to be able to restore files, folders
|
||||
So that I can get the resources that were accidentally deleted
|
||||
|
||||
Background:
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
And using spaces DAV path
|
||||
And the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
|
||||
And user "Alice" has created a space "restore objects" with the default quota using the Graph API
|
||||
And user "Alice" has created a folder "newFolder" in space "restore objects"
|
||||
And user "Alice" has uploaded a file inside space "restore objects" with content "test" to "newFolder/file.txt"
|
||||
|
||||
|
||||
Scenario Outline: user with different role can see deleted objects in trash bin of the space via the webDav API
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | restore objects |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <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"
|
||||
Then the HTTP status code should be "207"
|
||||
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:
|
||||
| space-role |
|
||||
| Manager |
|
||||
| Space Editor |
|
||||
| Space Viewer |
|
||||
|
||||
|
||||
Scenario Outline: user can restore a folder with some objects from the trash via the webDav API
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | restore objects |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <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 "<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" <should-or-not-be-in-trash> exist in the trashbin of the space "restore objects"
|
||||
Examples:
|
||||
| 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 | Space Editor | 201 | should | should not |
|
||||
| Brian | Space Viewer | 403 | should not | should |
|
||||
|
||||
|
||||
Scenario Outline: user can restore a file from the trash via the webDav API
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | restore objects |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <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 "<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" <should-or-not-be-in-trash> exist in the trashbin of the space "restore objects"
|
||||
Examples:
|
||||
| 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 | Space Editor | 201 | should | should not |
|
||||
| Brian | Space Viewer | 403 | should not | should |
|
||||
|
||||
|
||||
Scenario Outline: only space manager can purge the trash via the webDav API
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | restore objects |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <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 "<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:
|
||||
| space-role | http-status-code | should-or-not-be-in-trash |
|
||||
| Manager | 204 | should not |
|
||||
| Space Editor | 403 | should |
|
||||
| Space 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 "<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:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| Admin |
|
||||
|
||||
|
||||
Scenario Outline: admin user without space-manager role cannot purge the trash
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | restore objects |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Space Editor |
|
||||
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:
|
||||
| user-role |
|
||||
| Space Admin |
|
||||
| Admin |
|
||||
|
||||
@@ -0,0 +1,146 @@
|
||||
Feature: upload resources using TUS protocol
|
||||
As a user
|
||||
I want to be able to upload files
|
||||
So that I can store and share files between multiple client systems
|
||||
|
||||
Background:
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Alice |
|
||||
And the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
|
||||
And using spaces DAV path
|
||||
|
||||
|
||||
Scenario: upload a file within the set quota to a project space
|
||||
Given user "Alice" has created a space "Project Jupiter" of type "project" with quota "10000"
|
||||
When user "Alice" uploads a file with content "uploaded content" to "/upload.txt" via TUS inside of the space "Project Jupiter" using the WebDAV API
|
||||
Then for user "Alice" the space "Project Jupiter" should contain these entries:
|
||||
| upload.txt |
|
||||
|
||||
|
||||
Scenario: upload a file bigger than the set quota to a project space
|
||||
Given user "Alice" has created a space "Project Jupiter" of type "project" with quota "10"
|
||||
When user "Alice" creates a new TUS resource for the space "Project Jupiter" with content "file content is 24 bytes" using the WebDAV API with these headers:
|
||||
| Upload-Length | 24 |
|
||||
# dXBsb2FkLnR4dA== is the base64 encoded value of filename upload.txt
|
||||
| Upload-Metadata | filename dXBsb2FkLnR4dA== |
|
||||
| Content-Type | application/offset+octet-stream |
|
||||
| Tus-Resumable | 1.0.0 |
|
||||
| Tus-Extension | creation-with-upload |
|
||||
Then the HTTP status code should be "507"
|
||||
And for user "Alice" the space "Project Jupiter" should not contain these entries:
|
||||
| upload.txt |
|
||||
|
||||
|
||||
Scenario: upload the same file after renaming the first one
|
||||
Given user "Alice" has uploaded a file with content "uploaded content" to "/upload.txt" via TUS inside of the space "Alice Hansen"
|
||||
And user "Alice" has moved file "upload.txt" to "test.txt" in space "Personal"
|
||||
When user "Alice" uploads a file with content "uploaded content" to "/upload.txt" via TUS inside of the space "Alice Hansen" using the WebDAV API
|
||||
Then for user "Alice" the space "Personal" should contain these entries:
|
||||
| test.txt |
|
||||
| upload.txt |
|
||||
|
||||
@issue-10346
|
||||
Scenario Outline: upload a zero-byte file inside a shared folder
|
||||
Given using <dav-path-version> DAV path
|
||||
And user "Brian" has been created with default attributes
|
||||
And user "Alice" has created folder "testFolder"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | testFolder |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "testFolder" synced
|
||||
When user "Brian" uploads file "filesForUpload/zerobyte.txt" to "Shares/testFolder/textfile.txt" using the TUS protocol on the WebDAV API
|
||||
Then the content of file "Shares/testFolder/textfile.txt" for user "Brian" should be ""
|
||||
And the content of file "testFolder/textfile.txt" for user "Alice" should be ""
|
||||
Examples:
|
||||
| dav-path-version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
|
||||
Scenario: upload a zero-byte file inside a shared folder (spaces dav path)
|
||||
Given using spaces DAV path
|
||||
And user "Brian" has been created with default attributes
|
||||
And user "Alice" has created folder "testFolder"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | testFolder |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Editor |
|
||||
And user "Brian" has a share "testFolder" synced
|
||||
When user "Brian" uploads a file from "filesForUpload/zerobyte.txt" to "testFolder/textfile.txt" via TUS inside of the space "Shares" using the WebDAV API
|
||||
Then for user "Brian" the content of the file "testFolder/textfile.txt" of the space "Shares" should be ""
|
||||
And for user "Alice" the content of the file "testFolder/textfile.txt" of the space "Personal" should be ""
|
||||
|
||||
|
||||
Scenario: upload a zero-byte file inside a project space
|
||||
Given using spaces DAV path
|
||||
And the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
|
||||
And user "Alice" has created a space "new-space" with the default quota using the Graph API
|
||||
When user "Alice" uploads a file from "filesForUpload/zerobyte.txt" to "textfile.txt" via TUS inside of the space "new-space" using the WebDAV API
|
||||
Then for user "Alice" the content of the file "textfile.txt" of the space "new-space" should be ""
|
||||
|
||||
@issue-8003 @issue-10346
|
||||
Scenario Outline: replace a shared file with zero-byte file
|
||||
Given using <dav-path-version> DAV path
|
||||
And user "Brian" has been created with default attributes
|
||||
And user "Alice" has uploaded file with content "This is TUS upload" to "textfile.txt"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | textfile.txt |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | File Editor |
|
||||
And user "Brian" has a share "textfile.txt" synced
|
||||
When user "Brian" uploads file "filesForUpload/zerobyte.txt" to "Shares/textfile.txt" using the TUS protocol on the WebDAV API
|
||||
Then the content of file "Shares/textfile.txt" for user "Brian" should be ""
|
||||
And the content of file "textfile.txt" for user "Alice" should be ""
|
||||
Examples:
|
||||
| dav-path-version |
|
||||
| old |
|
||||
| new |
|
||||
|
||||
@issue-8003
|
||||
Scenario: replace a shared file with zero-byte file (spaces dav path)
|
||||
Given using spaces DAV path
|
||||
And user "Brian" has been created with default attributes
|
||||
And user "Alice" has uploaded file with content "This is TUS upload" to "textfile.txt"
|
||||
And user "Alice" has sent the following resource share invitation:
|
||||
| resource | textfile.txt |
|
||||
| space | Personal |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | File Editor |
|
||||
And user "Brian" has a share "textfile.txt" synced
|
||||
When user "Brian" uploads a file from "filesForUpload/zerobyte.txt" to "textfile.txt" via TUS inside of the space "Shares" using the WebDAV API
|
||||
Then for user "Brian" the content of the file "textfile.txt" of the space "Shares" should be ""
|
||||
And for user "Alice" the content of the file "textfile.txt" of the space "Personal" should be ""
|
||||
|
||||
@issue-8003
|
||||
Scenario: replace a file inside a project space with zero-byte file
|
||||
Given using spaces DAV path
|
||||
And the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
|
||||
And user "Alice" has created a space "new-space" with the default quota using the Graph API
|
||||
And user "Alice" has uploaded a file inside space "new-space" with content "This is TUS upload" to "textfile.txt"
|
||||
When user "Alice" uploads a file from "filesForUpload/zerobyte.txt" to "textfile.txt" via TUS inside of the space "new-space" using the WebDAV API
|
||||
Then for user "Alice" the content of the file "textfile.txt" of the space "new-space" should be ""
|
||||
|
||||
@issue-8003
|
||||
Scenario: replace a file inside a shared project space with zero-byte file
|
||||
Given using spaces DAV path
|
||||
And user "Brian" has been created with default attributes
|
||||
And the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
|
||||
And user "Alice" has created a space "new-space" with the default quota using the Graph API
|
||||
And user "Alice" has uploaded a file inside space "new-space" with content "This is TUS upload" to "textfile.txt"
|
||||
And user "Alice" has sent the following space share invitation:
|
||||
| space | new-space |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | Space Editor |
|
||||
When user "Brian" uploads a file from "filesForUpload/zerobyte.txt" to "textfile.txt" via TUS inside of the space "new-space" using the WebDAV API
|
||||
Then for user "Brian" the content of the file "textfile.txt" of the space "new-space" should be ""
|
||||
And for user "Alice" the content of the file "textfile.txt" of the space "new-space" should be ""
|
||||
@@ -0,0 +1,141 @@
|
||||
Feature: Upload files into a space
|
||||
As a user
|
||||
I want to be able to create folders and files in the space
|
||||
So that I can store various information in them
|
||||
|
||||
Background:
|
||||
Given these users have been created with default attributes:
|
||||
| username |
|
||||
| Alice |
|
||||
| Brian |
|
||||
| Bob |
|
||||
And the administrator has assigned the role "Space Admin" to user "Alice" using the Graph API
|
||||
And user "Alice" has created a space "Project Ceres" of type "project" with quota "2000"
|
||||
And using spaces DAV path
|
||||
|
||||
|
||||
Scenario Outline: user creates a folder in the space via the Graph API
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | Project Ceres |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <space-role> |
|
||||
When user "Brian" creates a folder "mainFolder" in space "Project Ceres" using the WebDav Api
|
||||
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:
|
||||
| space-role | http-status-code | should-or-not |
|
||||
| Manager | 201 | should |
|
||||
| Space Editor | 201 | should |
|
||||
| Space Viewer | 403 | should not |
|
||||
|
||||
|
||||
Scenario Outline: user uploads a file in shared space via the Graph API
|
||||
Given user "Alice" has sent the following space share invitation:
|
||||
| space | Project Ceres |
|
||||
| sharee | Brian |
|
||||
| shareType | user |
|
||||
| permissionsRole | <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 "<http-status-code>"
|
||||
And for user "Brian" the space "Project Ceres" <should-or-not> contain these entries:
|
||||
| test.txt |
|
||||
Examples:
|
||||
| space-role | http-status-code | should-or-not |
|
||||
| Manager | 201 | should |
|
||||
| Space Editor | 201 | should |
|
||||
| Space Viewer | 403 | should not |
|
||||
|
||||
|
||||
Scenario: user can create subfolders in a space via the Graph API
|
||||
When user "Alice" creates a subfolder "mainFolder/subFolder1/subFolder2" in space "Project Ceres" using the WebDav Api
|
||||
Then the HTTP status code should be "201"
|
||||
And for user "Alice" the space "Project Ceres" should contain these entries:
|
||||
| mainFolder |
|
||||
And for user "Alice" folder "mainFolder/subFolder1/" of the space "Project Ceres" should contain these entries:
|
||||
| subFolder2 |
|
||||
|
||||
|
||||
Scenario: user can create a folder and upload a file to a space
|
||||
When user "Alice" creates a folder "NewFolder" in space "Project Ceres" using the WebDav Api
|
||||
Then the HTTP status code should be "201"
|
||||
And user "Alice" uploads a file inside space "Project Ceres" with content "Test" to "test.txt" using the WebDAV API
|
||||
And the HTTP status code should be "201"
|
||||
And for user "Alice" the space "Project Ceres" should contain these entries:
|
||||
| NewFolder |
|
||||
| test.txt |
|
||||
|
||||
|
||||
Scenario: user cannot create a folder or a file in a space if they do not have permission
|
||||
When user "Bob" creates a folder "forAlice" in space "Project Ceres" owned by the user "Alice" using the WebDav Api
|
||||
Then the HTTP status code should be "404"
|
||||
When user "Bob" uploads a file inside space "Project Ceres" owned by the user "Alice" with content "Test" to "test.txt" using the WebDAV API
|
||||
Then the HTTP status code should be "404"
|
||||
And for user "Alice" the space "Project Ceres" should not contain these entries:
|
||||
| forAlice |
|
||||
| test.txt |
|
||||
|
||||
|
||||
Scenario: user cannot create folder with an existing name
|
||||
Given user "Alice" has created a folder "NewFolder" in space "Project Ceres"
|
||||
When user "Alice" creates a folder "NewFolder" in space "Project Ceres" using the WebDav Api
|
||||
Then the HTTP status code should be "405"
|
||||
|
||||
|
||||
Scenario Outline: user cannot create subfolder in a nonexistent folder
|
||||
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:
|
||||
| folder-name |
|
||||
| foo/bar |
|
||||
| foo/bar/baz |
|
||||
|
||||
@issue-10331 @issue-10469
|
||||
Scenario: public uploads a zero byte file to a public share folder
|
||||
Given using SharingNG
|
||||
And user "Alice" has created folder "/uploadFolder"
|
||||
And user "Alice" has created the following resource link share:
|
||||
| resource | uploadFolder |
|
||||
| space | Personal |
|
||||
| permissionsRole | createOnly |
|
||||
| password | %public% |
|
||||
When the public uploads file "filesForUpload/zerobyte.txt" to "textfile.txt" inside last link shared folder with password "%public%" using the public WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And for user "Alice" folder "uploadFolder" of the space "Personal" should contain these files:
|
||||
| textfile.txt |
|
||||
And for user "Alice" folder "uploadFolder" of the space "Personal" should not contain these files:
|
||||
| textfile (1).txt |
|
||||
| textfile (2).txt |
|
||||
|
||||
@issue-10331 @issue-10469
|
||||
Scenario: public uploads a zero byte file to a public share folder inside project space
|
||||
Given using SharingNG
|
||||
And user "Alice" has created a folder "/uploadFolder" in space "Project Ceres"
|
||||
And user "Alice" has created the following resource link share:
|
||||
| resource | uploadFolder |
|
||||
| space | Project Ceres |
|
||||
| permissionsRole | createOnly |
|
||||
| password | %public% |
|
||||
When the public uploads file "filesForUpload/zerobyte.txt" to "textfile.txt" inside last link shared folder with password "%public%" using the public WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And for user "Alice" folder "uploadFolder" of the space "Project Ceres" should contain these files:
|
||||
| textfile.txt |
|
||||
And for user "Alice" folder "uploadFolder" of the space "Project Ceres" should not contain these files:
|
||||
| textfile (1).txt |
|
||||
| textfile (2).txt |
|
||||
|
||||
@issue-10331 @issue-10469
|
||||
Scenario: public uploads a zero byte file to a public share project space
|
||||
Given using SharingNG
|
||||
And user "Alice" has created the following space link share:
|
||||
| space | Project Ceres |
|
||||
| permissionsRole | createOnly |
|
||||
| password | %public% |
|
||||
When the public uploads file "filesForUpload/zerobyte.txt" to "textfile.txt" inside last link shared folder with password "%public%" using the public WebDAV API
|
||||
Then the HTTP status code should be "201"
|
||||
And for user "Alice" the space "Project Ceres" should contain these files:
|
||||
| textfile.txt |
|
||||
And for user "Alice" the space "Project Ceres" should not contain these files:
|
||||
| textfile (1).txt |
|
||||
| textfile (2).txt |
|
||||
Reference in New Issue
Block a user