Skip to content

Add tests to create shares with only create,delete permissions #35921

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
phil-davis merged 1 commit into from
Jul 25, 2019
Merged

Add tests to create shares with only create,delete permissions #35921

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
119 changes: 119 additions & 0 deletions tests/acceptance/features/apiShareManagementBasic/createShare.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -576,6 +576,125 @@ Feature: sharing
| 1 | 404 | 200 | PARENT | 32 |
| 2 | 404 | 404 | PARENT | 32 |

@issue-35922
Scenario Outline: Cannot create a share of a file with a user with only create permission
Given using OCS API version "<ocs_api_version>"
And user "user1" has been created with default attributes and without skeleton files
When user "user0" creates a share using the sharing API with settings
| path | textfile0.txt |
| shareWith | user1 |
| shareType | user |
| permissions | create |
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "<http_status_code>"
# delete the following step when the issue is fixed. The share should not be created at all.
And the fields of the last response should include
| share_with | user1 |
| share_type | user |
| file_target | /textfile0.txt |
| path | /textfile0.txt |
| permissions | 0 |
And as "user1" entry "textfile0.txt" should not exist
Examples:
| ocs_api_version | ocs_status_code | http_status_code |
| 1 | 100 | 200 |
| 2 | 200 | 200 |
#| 1 | 400 | 200 |
#| 2 | 400 | 400 |

@issue-35922
Scenario Outline: Cannot create a share of a file with a user with only (create,)delete permission
Given using OCS API version "<ocs_api_version>"
And user "user1" has been created with default attributes and without skeleton files
When user "user0" creates a share using the sharing API with settings
| path | textfile0.txt |
| shareWith | user1 |
| shareType | user |
| permissions | <permissions> |
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "<http_status_code>"
# delete the following step when the issue is fixed. The share should not be created at all.
And the fields of the last response should include
| share_with | user1 |
| share_type | user |
| file_target | /textfile0.txt |
| path | /textfile0.txt |
| permissions | 1 |
# because the share got created wrongly with read permission, the file exists for the sharee
And as "user1" entry "textfile0.txt" should exist
#And as "user1" entry "textfile0.txt" should not exist
Examples:
| ocs_api_version | ocs_status_code | http_status_code | permissions |
| 1 | 100 | 200 | delete |
| 2 | 200 | 200 | delete |
| 1 | 100 | 200 | create,delete |
| 2 | 200 | 200 | create,delete |
#| 1 | 404 | 200 | delete |
#| 2 | 404 | 404 | delete |
#| 1 | 404 | 200 | create,delete |
#| 2 | 404 | 404 | create,delete |
@issue-35922
Scenario Outline: Cannot create a share of a file with a group with only create permission
Given using OCS API version "<ocs_api_version>"
And user "user1" has been created with default attributes and without skeleton files
And group "grp1" has been created
And user "user1" has been added to group "grp1"
When user "user0" creates a share using the sharing API with settings
| path | textfile0.txt |
| shareWith | grp1 |
| shareType | group |
| permissions | create |
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "<http_status_code>"
# delete the following step when the issue is fixed. The share should not be created at all.
And the fields of the last response should include
| share_with | grp1 |
| share_type | group |
| file_target | /textfile0.txt |
| path | /textfile0.txt |
| permissions | 0 |
And as "user1" entry "textfile0.txt" should not exist
Examples:
| ocs_api_version | ocs_status_code | http_status_code |
| 1 | 100 | 200 |
| 2 | 200 | 200 |
#| 1 | 400 | 200 |
#| 2 | 400 | 400 |

@issue-35922
Scenario Outline: Cannot create a share of a file with a group with only (create,)delete permission
Given using OCS API version "<ocs_api_version>"
And user "user1" has been created with default attributes and without skeleton files
And group "grp1" has been created
And user "user1" has been added to group "grp1"
When user "user0" creates a share using the sharing API with settings
| path | textfile0.txt |
| shareWith | grp1 |
| shareType | group |
| permissions | <permissions> |
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "<http_status_code>"
# delete the following step when the issue is fixed. The share should not be created at all.
And the fields of the last response should include
| share_with | grp1 |
| share_type | group |
| file_target | /textfile0.txt |
| path | /textfile0.txt |
| permissions | 1 |
# because the share got created wrongly with read permission, the file exists for the sharee
And as "user1" entry "textfile0.txt" should exist
#And as "user1" entry "textfile0.txt" should not exist
Examples:
| ocs_api_version | ocs_status_code | http_status_code | permissions |
| 1 | 100 | 200 | delete |
| 2 | 200 | 200 | delete |
| 1 | 100 | 200 | create,delete |
| 2 | 200 | 200 | create,delete |
#| 1 | 404 | 200 | delete |
#| 2 | 404 | 404 | delete |
#| 1 | 404 | 200 | create,delete |
#| 2 | 404 | 404 | create,delete |

Scenario Outline: user who is excluded from sharing tries to share a file with another user
Given using OCS API version "<ocs_api_version>"
And user "user1" has been created with default attributes and skeleton files
Expand Down
40 changes: 40 additions & 0 deletions tests/acceptance/features/apiShareUpdate/updateShare.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -309,6 +309,46 @@ Feature: sharing
| 1 | 200 |
| 2 | 400 |

Scenario Outline: Cannot update a share of a file with a user to have only create and/or delete permission
Given using OCS API version "<ocs_api_version>"
And user "user1" has been created with default attributes and without skeleton files
And user "user0" has shared file "textfile0.txt" with user "user1"
When user "user0" updates the last share using the sharing API with
| permissions | <permissions> |
Then the OCS status code should be "400"
And the HTTP status code should be "<http_status_code>"
# user1 should still have at least read access to the shared file
And as "user1" entry "textfile0.txt" should exist
Examples:
| ocs_api_version | http_status_code | permissions |
| 1 | 200 | create |
| 2 | 400 | create |
| 1 | 200 | delete |
| 2 | 400 | delete |
| 1 | 200 | create,delete |
| 2 | 400 | create,delete |

Scenario Outline: Cannot update a share of a file with a group to have only create and/or delete permission
Given using OCS API version "<ocs_api_version>"
And user "user1" has been created with default attributes and without skeleton files
And group "grp1" has been created
And user "user1" has been added to group "grp1"
And user "user0" has shared file "textfile0.txt" with group "grp1"
When user "user0" updates the last share using the sharing API with
| permissions | <permissions> |
Then the OCS status code should be "400"
And the HTTP status code should be "<http_status_code>"
# user1 in grp1 should still have at least read access to the shared file
And as "user1" entry "textfile0.txt" should exist
Examples:
| ocs_api_version | http_status_code | permissions |
| 1 | 200 | create |
| 2 | 400 | create |
| 1 | 200 | delete |
| 2 | 400 | delete |
| 1 | 200 | create,delete |
| 2 | 400 | create,delete |

Scenario: Share ownership change after moving a shared file outside of an outer share
Given these users have been created with default attributes and without skeleton files:
| username |
Expand Down