Merge pull request #5561 from owncloud/forward-port-share=permission-CoreApiSharePublicLink3

[tests-only][full-ci]Forward-port refactor share permission related scenario
This commit is contained in:
Phil Davis
2023-02-14 14:22:35 +05:45
committed by GitHub
5 changed files with 46 additions and 312 deletions

View File

@@ -253,18 +253,16 @@ cannot share a folder with create permission
- [coreApiSharePublicLink2/copyFromPublicLink.feature:174](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiSharePublicLink2/copyFromPublicLink.feature#L174)
- [coreApiSharePublicLink2/copyFromPublicLink.feature:189](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiSharePublicLink2/copyFromPublicLink.feature#L189)
- [coreApiSharePublicLink2/copyFromPublicLink.feature:190](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiSharePublicLink2/copyFromPublicLink.feature#L190)
- [coreApiSharePublicLink3/updatePublicLinkShare.feature:45](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiSharePublicLink3/updatePublicLinkShare.feature#L45)
- [coreApiSharePublicLink3/updatePublicLinkShare.feature:46](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiSharePublicLink3/updatePublicLinkShare.feature#L46)
#### [Upload-only shares must not overwrite but create a separate file](https://github.com/owncloud/ocis/issues/1267)
- [coreApiSharePublicLink3/uploadToPublicLinkShare.feature:24](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiSharePublicLink3/uploadToPublicLinkShare.feature#L24)
- [coreApiSharePublicLink3/uploadToPublicLinkShare.feature:273](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiSharePublicLink3/uploadToPublicLinkShare.feature#L273)
- [coreApiSharePublicLink3/uploadToPublicLinkShare.feature:10](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiSharePublicLink3/uploadToPublicLinkShare.feature#L10)
- [coreApiSharePublicLink3/uploadToPublicLinkShare.feature:131](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiSharePublicLink3/uploadToPublicLinkShare.feature#L131)
#### [Set quota over settings](https://github.com/owncloud/ocis/issues/1290)
- [coreApiSharePublicLink3/uploadToPublicLinkShare.feature:160](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiSharePublicLink3/uploadToPublicLinkShare.feature#L160)
- [coreApiSharePublicLink3/uploadToPublicLinkShare.feature:179](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiSharePublicLink3/uploadToPublicLinkShare.feature#L179)
- [coreApiSharePublicLink3/uploadToPublicLinkShare.feature:84](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiSharePublicLink3/uploadToPublicLinkShare.feature#L84)
- [coreApiSharePublicLink3/uploadToPublicLinkShare.feature:93](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiSharePublicLink3/uploadToPublicLinkShare.feature#L93)
#### [deleting a file inside a received shared folder is moved to the trash-bin of the sharer not the receiver](https://github.com/owncloud/ocis/issues/1124)
@@ -701,11 +699,6 @@ Not everything needs to be implemented for ocis. While the oc10 testsuite covers
- [coreApiWebdavUpload1/uploadFileToBlacklistedName.feature:70](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToBlacklistedName.feature#L70)
- [coreApiWebdavUpload1/uploadFileToBlacklistedName.feature:76](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavUpload1/uploadFileToBlacklistedName.feature#L76)
#### [Allow public link sharing only for certain groups feature not implemented](https://github.com/owncloud/ocis/issues/4623)
- [coreApiSharePublicLink3/allowGroupToCreatePublicLinks.feature:35](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiSharePublicLink3/allowGroupToCreatePublicLinks.feature#L35)
- [coreApiSharePublicLink3/allowGroupToCreatePublicLinks.feature:92](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiSharePublicLink3/allowGroupToCreatePublicLinks.feature#L92)
#### [Preview of text file with UTF content does not render correctly](https://github.com/owncloud/ocis/issues/2570)
- [coreApiWebdavPreviews/previews.feature:211](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiWebdavPreviews/previews.feature#L211)

View File

@@ -2858,7 +2858,9 @@ trait Sharing {
"uid_file_owner",
"share_with",
"displayname_file_owner",
"displayname_owner"
"displayname_owner",
"additional_info_owner",
"additional_info_file_owner"
];
foreach ($bodyRows as $field => $value) {
if (\in_array($field, $userRelatedFieldNames)) {

View File

@@ -1,110 +0,0 @@
@api @files_sharing-app-required @notToImplementOnOcis
Feature: public share sharers groups setting
As an admin
I should be able to allow only certain groups to create public links
So that random links are not generated on my file system
Background:
Given group "grp1" has been created
And user "Alice" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "file to share with user" to "/fileToShare.txt"
Scenario: users present in public share shares groups can create new public link shares
Given parameter "public_share_sharers_groups_allowlist_enabled" of app "files_sharing" has been set to "yes"
And parameter "public_share_sharers_groups_allowlist" of app "files_sharing" has been set to '["grp1"]'
And user "Alice" has been added to group "grp1"
When user "Alice" creates a public link share using the sharing API with settings
| path | fileToShare.txt |
Then the OCS status code should be "100"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" should include
| item_type | file |
| mimetype | text/plain |
| file_target | /fileToShare.txt |
| path | /fileToShare.txt |
| permissions | read |
| share_type | public_link |
| displayname_file_owner | %displayname% |
| displayname_owner | %displayname% |
| uid_file_owner | %username% |
| uid_owner | %username% |
| name | |
Scenario: users not present in public share shares groups cannot create a new public link share
Given parameter "public_share_sharers_groups_allowlist_enabled" of app "files_sharing" has been set to "yes"
And parameter "public_share_sharers_groups_allowlist" of app "files_sharing" has been set to '["grp1"]'
When user "Alice" creates a public link share using the sharing API with settings
| path | fileToShare.txt |
Then the OCS status code should be "403"
And the HTTP status code should be "200"
And the OCS status message should be "Public link creation is only possible for certain groups"
Scenario: existing links can still be updated by sharers even if they are not present in public share sharers groups
Given user "Alice" has created a public link share with settings
| path | /fileToShare.txt |
| permissions | read |
And parameter "public_share_sharers_groups_allowlist_enabled" of app "files_sharing" has been set to "yes"
And parameter "public_share_sharers_groups_allowlist" of app "files_sharing" has been set to '["grp1"]'
When user "Alice" updates the last public link share using the sharing API with
| expireDate | 2040-01-01T23:59:59+0100 |
Then the HTTP status code should be "200"
And the OCS status code should be "100"
And the fields of the last response to user "Alice" should include
| expiration | 2040-01-01 22:59:59 |
Scenario: existing links can still be deleted by sharers even if they are not present in public share sharers groups
Given user "Alice" has created a public link share with settings
| path | /fileToShare.txt |
| permissions | read |
| name | shared-link |
And parameter "public_share_sharers_groups_allowlist_enabled" of app "files_sharing" has been set to "yes"
And parameter "public_share_sharers_groups_allowlist" of app "files_sharing" has been set to '["grp1"]'
When user "Alice" deletes public link share named "shared-link" in file "fileToShare.txt" using the sharing API
Then the HTTP status code should be "200"
And the OCS status code should be "100"
And as user "Alice" the file "fileToShare.txt" should not have any shares
Scenario: creating a new link share is not restricted if no groups are inside the allowed public share sharers groups even if allowlist is enabled
Given parameter "public_share_sharers_groups_allowlist_enabled" of app "files_sharing" has been set to "yes"
When user "Alice" creates a public link share using the sharing API with settings
| path | fileToShare.txt |
Then the OCS status code should be "100"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" should include
| item_type | file |
| mimetype | text/plain |
| file_target | /fileToShare.txt |
| path | /fileToShare.txt |
| permissions | read |
| share_type | public_link |
| displayname_file_owner | %displayname% |
| displayname_owner | %displayname% |
| uid_file_owner | %username% |
| uid_owner | %username% |
| name | |
Scenario: multiple groups can be added to public share sharers groups allow list
Given parameter "public_share_sharers_groups_allowlist_enabled" of app "files_sharing" has been set to "yes"
And user "Brian" has been created with default attributes and without skeleton files
And user "Carol" has been created with default attributes and without skeleton files
And user "Brian" has uploaded file with content "file to share with user" to "/fileToShare.txt"
And user "Carol" has uploaded file with content "file to share with user" to "/fileToShare.txt"
And group "grp2" has been created
And user "Alice" has been added to group "grp1"
And user "Brian" has been added to group "grp2"
And parameter "public_share_sharers_groups_allowlist" of app "files_sharing" has been set to '["grp1", "grp2"]'
When user "Alice" creates a public link share using the sharing API with settings
| path | fileToShare.txt |
And user "Brian" creates a public link share using the sharing API with settings
| path | fileToShare.txt |
And user "Carol" creates a public link share using the sharing API with settings
| path | fileToShare.txt |
Then the HTTP status code of responses on all endpoints should be "200"
And the OCS status code of responses on each endpoint should be "100, 100, 403" respectively
And the OCS status message should be "Public link creation is only possible for certain groups"

View File

@@ -14,7 +14,7 @@ Feature: update a public link share
When user "Alice" updates the last public link share using the sharing API with
| expireDate | 2040-01-01T23:59:59+0100 |
Then the OCS status code should be "<ocs_status_code>"
And the OCS status message should be "Ok"
And the OCS status message should be "OK"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" should include
| id | A_STRING |
@@ -28,8 +28,8 @@ Feature: update a public link share
| token | A_STRING |
| uid_file_owner | %username% |
| displayname_file_owner | %displayname% |
| additional_info_owner | |
| additional_info_file_owner | |
| additional_info_owner | %emailaddress% |
| additional_info_file_owner | %emailaddress% |
| item_type | folder |
| item_source | A_STRING |
| path | /FOLDER |
@@ -413,25 +413,17 @@ Feature: update a public link share
| permissions | read |
And user "Alice" has updated the last public link share with
| permissions | read,update,create,delete |
When the public deletes file "CHILD/child.txt" from the last public link share using the <public-webdav-api-version> public WebDAV API
And the public deletes file "parent.txt" from the last public link share using the <public-webdav-api-version> public WebDAV API
When the public deletes file "CHILD/child.txt" from the last public link share using the new public WebDAV API
And the public deletes file "parent.txt" from the last public link share using the new public WebDAV API
Then the HTTP status code of responses on all endpoints should be "204"
And as "Alice" file "PARENT/CHILD/child.txt" should not exist
And as "Alice" file "PARENT/parent.txt" should not exist
@notToImplementOnOCIS @issue-ocis-2079
Examples:
| ocs_api_version | public-webdav-api-version |
| 1 | old |
| 2 | old |
| ocs_api_version |
| 1 |
| 2 |
Examples:
| ocs_api_version | public-webdav-api-version |
| 1 | new |
| 2 | new |
@skipOnOcV10
Scenario Outline: API responds with a full set of parameters when owner renames the folder with a public link in ocis
Given using OCS API version "<ocs_api_version>"
And using <dav-path> DAV path
@@ -478,7 +470,6 @@ Feature: update a public link share
| spaces | 2 | 200 |
@skipOnOcV10
Scenario Outline: API responds with a full set of parameters when owner renames the file with a public link in ocis
Given using OCS API version "<ocs_api_version>"
And using <dav-path> DAV path

View File

@@ -1,4 +1,4 @@
@api @files_sharing-app-required @public_link_share-feature-required @issue-ocis-reva-315 @issue-ocis-reva-316
@api @files_sharing-app-required @public_link_share-feature-required @issue-ocis-reva-315 @issue-ocis-reva-316 @issue-ocis-2079
Feature: upload to a public link share
@@ -6,20 +6,6 @@ Feature: upload to a public link share
Given user "Alice" has been created with default attributes and without skeleton files
And user "Alice" has created folder "FOLDER"
@smokeTest @notToImplementOnOCIS @issue-ocis-2079
Scenario: Uploading same file to a public upload-only share multiple times via old API
# The old API needs to have the header OC-Autorename: 1 set to do the autorename
Given user "Alice" has created a public link share with settings
| path | FOLDER |
| permissions | create |
When the public uploads file "test.txt" with content "test" using the old public WebDAV API
And the public uploads file "test.txt" with content "test2" with auto-rename mode using the old public WebDAV API
Then the HTTP status code should be "201"
And the following headers should match these regular expressions
| ETag | /^"[a-f0-9:\.]{1,32}"$/ |
And the content of file "/FOLDER/test.txt" for user "Alice" should be "test"
And the content of file "/FOLDER/test (2).txt" for user "Alice" should be "test2"
@smokeTest @issue-ocis-reva-286
Scenario: Uploading same file to a public upload-only share multiple times via new API
# The new API does the autorename automatically in upload-only folders
@@ -41,235 +27,107 @@ Feature: upload to a public link share
| path | FOLDER |
| permissions | create |
And user "Alice" has deleted folder "/FOLDER"
When the public uploads file "test.txt" with content "test" using the <public-webdav-api-version> public WebDAV API
When the public uploads file "test.txt" with content "test" using the new public WebDAV API
And the HTTP status code should be "404"
@notToImplementOnOCIS @issue-ocis-2079
Examples:
| dav-path | public-webdav-api-version |
| old | old |
| new | old |
@issue-ocis-reva-290
Examples:
| dav-path | public-webdav-api-version |
| old | new |
| new | new |
| dav-path |
| old |
| new |
@personalSpace @skipOnOcV10
@personalSpace
Examples:
| dav-path | public-webdav-api-version |
| spaces | new |
| dav-path |
| spaces |
Scenario Outline: Uploading file to a public read-only share folder with public API does not work
@issue-reva-292
Scenario: Uploading file to a public read-only share folder with public API does not work
Given user "Alice" has created a public link share with settings
| path | FOLDER |
| permissions | read |
When the public uploads file "test.txt" with content "test" using the <public-webdav-api-version> public WebDAV API
When the public uploads file "test.txt" with content "test" using the new public WebDAV API
And the HTTP status code should be "403"
@notToImplementOnOCIS @issue-ocis-2079
Examples:
| public-webdav-api-version |
| old |
@issue-ocis-reva-292
Examples:
| public-webdav-api-version |
| new |
Scenario Outline: Uploading to a public upload-only share with public API
Scenario: Uploading to a public upload-only share with public API
Given user "Alice" has created a public link share with settings
| path | FOLDER |
| permissions | create |
When the public uploads file "test.txt" with content "test-file" using the <public-webdav-api-version> public WebDAV API
When the public uploads file "test.txt" with content "test-file" using the new public WebDAV API
Then the HTTP status code should be "201"
And the content of file "/FOLDER/test.txt" for user "Alice" should be "test-file"
And the following headers should match these regular expressions
| ETag | /^"[a-f0-9:\.]{1,32}"$/ |
@notToImplementOnOCIS @issue-ocis-2079
Examples:
| public-webdav-api-version |
| old |
Examples:
| public-webdav-api-version |
| new |
Scenario Outline: Uploading to a public upload-only share with password with public API
Scenario: Uploading to a public upload-only share with password with public API
Given user "Alice" has created a public link share with settings
| path | FOLDER |
| password | %public% |
| permissions | create |
When the public uploads file "test.txt" with password "%public%" and content "test-file" using the <public-webdav-api-version> public WebDAV API
When the public uploads file "test.txt" with password "%public%" and content "test-file" using the new public WebDAV API
Then the HTTP status code should be "201"
And the content of file "/FOLDER/test.txt" for user "Alice" should be "test-file"
@notToImplementOnOCIS @issue-ocis-2079
Examples:
| public-webdav-api-version |
| old |
Examples:
| public-webdav-api-version |
| new |
Scenario Outline: Uploading to a public read/write share with password with public API
Scenario: Uploading to a public read/write share with password with public API
Given user "Alice" has created a public link share with settings
| path | FOLDER |
| password | %public% |
| permissions | change |
When the public uploads file "test.txt" with password "%public%" and content "test-file" using the <public-webdav-api-version> public WebDAV API
When the public uploads file "test.txt" with password "%public%" and content "test-file" using the new public WebDAV API
Then the HTTP status code should be "201"
And the content of file "/FOLDER/test.txt" for user "Alice" should be "test-file"
@notToImplementOnOCIS @issue-ocis-2079
Examples:
| public-webdav-api-version |
| old |
Examples:
| public-webdav-api-version |
| new |
Scenario Outline: Uploading file to a public shared folder with read/write permission when the sharer has insufficient quota does not work with public API
Scenario: Uploading file to a public shared folder with read/write permission when the sharer has insufficient quota does not work with public API
When user "Alice" creates a public link share using the sharing API with settings
| path | FOLDER |
| permissions | change |
And the quota of user "Alice" has been set to "0"
When the public uploads file "test.txt" with content "test-file" using the <public-webdav-api-version> public WebDAV API
When the public uploads file "test.txt" with content "test-file" using the new public WebDAV API
Then the HTTP status code should be "507"
@notToImplementOnOCIS @issue-ocis-2079
Examples:
| public-webdav-api-version |
| old |
@issue-ocis-reva-195
Examples:
| public-webdav-api-version |
| new |
Scenario Outline: Uploading file to a public shared folder with upload-only permission when the sharer has insufficient quota does not work with public API
@issue-reva-195
Scenario: Uploading file to a public shared folder with upload-only permission when the sharer has insufficient quota does not work with public API
When user "Alice" creates a public link share using the sharing API with settings
| path | FOLDER |
| permissions | create |
And the quota of user "Alice" has been set to "0"
When the public uploads file "test.txt" with content "test-file" using the <public-webdav-api-version> public WebDAV API
When the public uploads file "test.txt" with content "test-file" using the new public WebDAV API
Then the HTTP status code should be "507"
@notToImplementOnOCIS @issue-ocis-2079
Examples:
| public-webdav-api-version |
| old |
@issue-ocis-reva-195
Examples:
| public-webdav-api-version |
| new |
Scenario Outline: Uploading file to a public shared folder does not work when allow public uploads has been disabled after sharing the folder with public API
Given user "Alice" has created a public link share with settings
| path | FOLDER |
| permissions | create |
And parameter "shareapi_allow_public_upload" of app "core" has been set to "no"
When the public uploads file "test.txt" with content "test-file" using the <public-webdav-api-version> public WebDAV API
Then the HTTP status code should be "403"
@notToImplementOnOCIS @issue-ocis-2079
Examples:
| public-webdav-api-version |
| old |
| new |
Scenario Outline: Uploading file to a public shared folder does not work when allow public uploads has been disabled before sharing and again enabled after sharing the folder with public API
@issue-reva-41
Scenario: Uploading file to a public shared folder does not work when allow public uploads has been disabled before sharing and again enabled after sharing the folder with public API
Given parameter "shareapi_allow_public_upload" of app "core" has been set to "no"
And user "Alice" has created a public link share with settings
| path | FOLDER |
And parameter "shareapi_allow_public_upload" of app "core" has been set to "yes"
When the public uploads file "test.txt" with content "test-file" using the <public-webdav-api-version> public WebDAV API
When the public uploads file "test.txt" with content "test-file" using the new public WebDAV API
And the HTTP status code should be "403"
@notToImplementOnOCIS @issue-ocis-2079
Examples:
| public-webdav-api-version |
| old |
@issue-ocis-reva-41
Examples:
| public-webdav-api-version |
| new |
Scenario Outline: Uploading file to a public shared folder works when allow public uploads has been disabled and again enabled after sharing the folder with public API
@issue-reva-41
Scenario: Uploading file to a public shared folder works when allow public uploads has been disabled and again enabled after sharing the folder with public API
Given user "Alice" has created a public link share with settings
| path | FOLDER |
| permissions | create |
And parameter "shareapi_allow_public_upload" of app "core" has been set to "no"
And parameter "shareapi_allow_public_upload" of app "core" has been set to "yes"
When the public uploads file "test.txt" with content "test-file" using the <public-webdav-api-version> public WebDAV API
When the public uploads file "test.txt" with content "test-file" using the new public WebDAV API
Then the HTTP status code should be "201"
And the content of file "/FOLDER/test.txt" for user "Alice" should be "test-file"
@notToImplementOnOCIS @issue-ocis-2079
Examples:
| public-webdav-api-version |
| old |
@issue-ocis-reva-41
Examples:
| public-webdav-api-version |
| new |
@smokeTest
Scenario Outline: Uploading to a public upload-write and no edit and no overwrite share with public API
Scenario: Uploading to a public upload-write and no edit and no overwrite share with public API
Given user "Alice" has created a public link share with settings
| path | FOLDER |
| permissions | uploadwriteonly |
When the public uploads file "test.txt" with content "test-file" using the <public-webdav-api-version> public WebDAV API
When the public uploads file "test.txt" with content "test-file" using the new public WebDAV API
Then the HTTP status code should be "201"
And the content of file "/FOLDER/test.txt" for user "Alice" should be "test-file"
@notToImplementOnOCIS @issue-ocis-2079
Examples:
| public-webdav-api-version |
| old |
Examples:
| public-webdav-api-version |
| new |
@smokeTest @notToImplementOnOCIS @issue-ocis-2079
Scenario: Uploading same file to a public upload-write and no edit and no overwrite share multiple times with old public API
Given user "Alice" has created a public link share with settings
| path | FOLDER |
| permissions | uploadwriteonly |
When the public uploads file "test.txt" with content "test" using the old public WebDAV API
Then the HTTP status code should be "201"
And the following headers should match these regular expressions
| ETag | /^"[a-f0-9:\.]{1,32}"$/ |
When the public uploads file "test.txt" with content "test2" using the old public WebDAV API
# Uncomment these once the issue is fixed
# Then the HTTP status code should be "201"
# And the content of file "/FOLDER/test.txt" for user "Alice" should be "test"
# And the content of file "/FOLDER/test (2).txt" for user "Alice" should be "test2"
Then the HTTP status code should be "403"
And the content of file "/FOLDER/test.txt" for user "Alice" should be "test"
@smokeTest @issue-ocis-reva-286
@smokeTest @issue-reva-286
Scenario: Uploading same file to a public upload-write and no edit and no overwrite share multiple times with new public API
Given user "Alice" has created a public link share with settings
| path | FOLDER |