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

[full-ci] Delete resharing tests (#8704)

Browse Source 
* feat: disable resharing by default

delete re-sharing tests

* fix tests

---------

Co-authored-by: Michael Barz <mbarz@owncloud.com>
This commit is contained in:
Viktor Scharf
2024-03-27 10:30:25 +01:00
committed by GitHub
co-authored by Michael Barz
parent 3143fd9c76
commit 79c74711c4
43 changed files with 367 additions and 1678 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tests/acceptance/config/behat-core.yml
-20
View File
@@ -145,26 +145,6 @@ default:
- WebDavPropertiesContext:
- OcisConfigContext:
coreApiShareReshareToShares1:
paths:
- "%paths.base%/../features/coreApiShareReshareToShares1"
context: *common_ldap_suite_context
contexts:
- FeatureContext: *common_feature_context_params
- PublicWebDavContext:
- TrashbinContext:
- WebDavPropertiesContext:
coreApiShareReshareToShares2:
paths:
- "%paths.base%/../features/coreApiShareReshareToShares2"
context: *common_ldap_suite_context
contexts:
- FeatureContext: *common_feature_context_params
- PublicWebDavContext:
- TrashbinContext:
- WebDavPropertiesContext:
coreApiShareUpdateToShares:
paths:
- "%paths.base%/../features/coreApiShareUpdateToShares"
tests/acceptance/expected-failures-API-on-OCIS-storage.md
+8 -32
View File
@@ -71,14 +71,6 @@ File and sync features in a shared scenario
- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:159](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L159)
- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:160](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L160)
#### [sharing the shares folder to users exits with different status code than in oc10 backend](https://github.com/owncloud/ocis/issues/2215)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:654](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L654)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:655](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L655)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:672](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L672)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:673](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L673)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:687](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L687)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:688](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L688)
#### [file_target of an auto-renamed file is not correct directly after sharing](https://github.com/owncloud/core/issues/32322)
@@ -133,29 +125,13 @@ cannot share a folder with create permission
- [coreApiTrashbin/trashbinSharingToShares.feature:201](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiTrashbin/trashbinSharingToShares.feature#L201)
- [coreApiTrashbin/trashbinSharingToShares.feature:224](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiTrashbin/trashbinSharingToShares.feature#L224)
#### [Expiration date for shares is not implemented](https://github.com/owncloud/ocis/issues/1250)
#### Expiration date of user shares
- [coreApiShareReshareToShares2/reShareWithExpiryDate.feature:33](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareReshareToShares2/reShareWithExpiryDate.feature#L33)
- [coreApiShareReshareToShares2/reShareWithExpiryDate.feature:34](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareReshareToShares2/reShareWithExpiryDate.feature#L34)
#### Expiration date of group shares
- [coreApiShareReshareToShares2/reShareWithExpiryDate.feature:56](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareReshareToShares2/reShareWithExpiryDate.feature#L56)
- [coreApiShareReshareToShares2/reShareWithExpiryDate.feature:57](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareReshareToShares2/reShareWithExpiryDate.feature#L57)
#### [Cannot move folder/file from one received share to another](https://github.com/owncloud/ocis/issues/2442)
- [coreApiShareUpdateToShares/updateShare.feature:124](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L124)
- [coreApiShareUpdateToShares/updateShare.feature:154](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L154)
#### [Sharing folder and sub-folder with same user but different permission,the permission of sub-folder is not obeyed ](https://github.com/owncloud/ocis/issues/2440)
- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:213](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L213)
- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:239](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L239)
- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:324](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L324)
- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:350](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L350)
- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:292](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L292)
- [coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature:318](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature#L318)
#### [Empty OCS response for a share create request using a disabled user](https://github.com/owncloud/ocis/issues/2212)
@@ -164,13 +140,13 @@ cannot share a folder with create permission
#### [Edit user share response has a "name" field](https://github.com/owncloud/ocis/issues/1225)
- [coreApiShareUpdateToShares/updateShare.feature:227](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L227)
- [coreApiShareUpdateToShares/updateShare.feature:228](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L228)
- [coreApiShareUpdateToShares/updateShare.feature:161](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L161)
- [coreApiShareUpdateToShares/updateShare.feature:162](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature#L162)
#### [Share lists deleted user as 'user'](https://github.com/owncloud/ocis/issues/903)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:594](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L594)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:595](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L595)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:544](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L544)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:545](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L545)
#### [deleting a share with wrong authentication returns OCS status 996 / HTTP 500](https://github.com/owncloud/ocis/issues/1229)
@@ -278,8 +254,8 @@ And other missing implementation of favorites
#### [Sharing a same file twice to the same group](https://github.com/owncloud/ocis/issues/1710)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:638](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L638)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:639](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L639)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:588](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L588)
- [coreApiShareManagementBasicToShares/createShareToSharesFolder.feature:589](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature#L589)
#### [PATCH request for TUS upload with wrong checksum gives incorrect response](https://github.com/owncloud/ocis/issues/1755)
tests/acceptance/expected-failures-localAPI-on-OCIS-storage.md
+8 -2
View File
@@ -24,8 +24,8 @@ The expected failures in this file are from features in the owncloud/ocis repo.
### [Shared mount folder gets deleted when overwritten by a file from personal space](https://github.com/owncloud/ocis/issues/7208)
- [apiSpacesShares/copySpaces.feature:510](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesShares/copySpaces.feature#L510)
- [apiSpacesShares/copySpaces.feature:523](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesShares/copySpaces.feature#L523)
- [apiSpacesShares/copySpaces.feature:512](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesShares/copySpaces.feature#L512)
- [apiSpacesShares/copySpaces.feature:525](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesShares/copySpaces.feature#L525)
#### [PATCH request for TUS upload with wrong checksum gives incorrect response](https://github.com/owncloud/ocis/issues/1755)
@@ -285,5 +285,11 @@ The expected failures in this file are from features in the owncloud/ocis repo.
- [apiSpacesDavOperation/moveByFileId.feature:464](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L464)
- [apiSpacesDavOperation/moveByFileId.feature:465](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesDavOperation/moveByFileId.feature#L465)
### [Delete resharing tests ](https://github.com/owncloud/ocis/pull/8704)
- [apiSpacesShares/shareSubItemOfSpace.feature:119](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesShares/shareSubItemOfSpace.feature#L119)
- [apiSpacesShares/shareSubItemOfSpace.feature:132](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesShares/shareSubItemOfSpace.feature#L132)
- [apiSpacesShares/shareSubItemOfSpace.feature:145](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesShares/shareSubItemOfSpace.feature#L145)
- [apiSpacesShares/shareSubItemOfSpace.feature:156](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiSpacesShares/shareSubItemOfSpace.feature#L156)
- Note: always have an empty line at the end of this file.
The bash script that processes this file requires that the last line has a newline on the end.
tests/acceptance/features/apiContract/sharesReport.feature
+2 -2
View File
@@ -11,7 +11,7 @@ Feature: REPORT request to Shares space
And user "Alice" has created folder "/folderMain"
And user "Alice" has created folder "/folderMain/SubFolder1"
And user "Alice" has created folder "/folderMain/SubFolder1/subFOLDER2"
And user "Alice" has shared entry "/folderMain" with user "Brian" with permissions "17"
And user "Alice" has shared entry "/folderMain" with user "Brian" with permissions "1"
Scenario Outline: check the REPORT response of the found folder
@@ -60,7 +60,7 @@ Feature: REPORT request to Shares space
Given user "Brian" has disabled auto-accepting
And using <dav-path-version> DAV path
And user "Alice" has created folder "/folderToBrian"
And user "Alice" has shared entry "/folderToBrian" with user "Brian" with permissions "17"
And user "Alice" has shared entry "/folderToBrian" with user "Brian" with permissions "1"
When user "Brian" searches for "folderToBrian" using the WebDAV API
Then the HTTP status code should be "207"
And the following headers should match these regular expressions
tests/acceptance/features/apiGraph/userGDPRExport.feature
-5
View File
@@ -625,7 +625,6 @@ Feature: user GDPR (General Data Protection Regulation) report
"permissions": {
"type": "object",
"required": [
"add_grant",
"get_path",
"get_quota",
"initiate_file_download",
@@ -634,10 +633,6 @@ Feature: user GDPR (General Data Protection Regulation) report
"stat"
],
"properties": {
"add_grant" : {
"type": "boolean",
"enum": [true]
},
"get_path" : {
"type": "boolean",
"enum": [true]
tests/acceptance/features/apiNotification/emailNotification.feature
+1 -1
View File
@@ -30,7 +30,7 @@ Feature: Email notification
Scenario: user gets an email notification when someone shares a file
Given user "Alice" has uploaded file with content "sample text" to "lorem.txt"
When user "Alice" shares file "lorem.txt" with user "Brian" with permissions "17" using the sharing API
When user "Alice" shares file "lorem.txt" with user "Brian" using the sharing API
Then the HTTP status code should be "200"
And the OCS status code should be "100"
And user "Brian" should have received the following email from user "Alice"
tests/acceptance/features/apiNotification/notification.feature
+2 -2
View File
@@ -242,7 +242,7 @@ Feature: Notification
Scenario Outline: get a notification about a file share in various languages
Given user "Brian" has switched the system language to "<language>" using the <api> API
And user "Alice" has shared entry "textfile1.txt" with user "Brian" with permissions "17"
And user "Alice" has shared entry "textfile1.txt" with user "Brian"
When user "Brian" lists all notifications
Then the HTTP status code should be "200"
And the JSON response should contain a notification message with the subject "<subject>" and the message-details should match
@@ -272,7 +272,7 @@ Feature: Notification
@env-config
Scenario: get a notification about a file share in default languages
Given the config "OCIS_DEFAULT_LANGUAGE" has been set to "de"
And user "Alice" has shared entry "textfile1.txt" with user "Brian" with permissions "17"
And user "Alice" has shared entry "textfile1.txt" with user "Brian"
When user "Brian" lists all notifications
Then the HTTP status code should be "200"
And the JSON response should contain a notification message with the subject "Neue Freigabe" and the message-details should match
tests/acceptance/features/apiReshare/disableReshare.feature
-57
View File
@@ -1,57 +0,0 @@
@env-config
Feature: share by disabling re-share
As a user
I want to share resources
So that other users can have access to them but cannot re-share them
Background:
Given the config "FRONTEND_ENABLE_RESHARING" has been set to "false"
And these users have been created with default attributes and without skeleton files:
| username |
| Alice |
| Brian |
And user "Alice" has created folder "test"
Scenario Outline: share folder with different roles
Given using <dav-path-version> DAV path
When user "Alice" creates a share inside of space "Personal" with settings:
| path | test |
| shareWith | Brian |
| role | <role> |
Then the HTTP status code should be "200"
And the OCS status code should be "200"
And the fields of the last response to user "Alice" sharing with user "Brian" should include
| permissions | <expected-permissions> |
Examples:
| dav-path-version | role | expected-permissions |
| old | editor | 15 |
| old | viewer | 1 |
| new | editor | 15 |
| new | viewer | 1 |
| spaces | editor | 15 |
| spaces | viewer | 1 |
Scenario Outline: try to re-share folder
Given using <dav-path-version> DAV path
And user "Carol" has been created with default attributes and without skeleton files
And user "Alice" has created a share inside of space "Personal" with settings:
| path | test |
| shareWith | Brian |
| role | <role> |
When user "Brian" creates a share inside of space "Shares" with settings:
| path | test |
| shareWith | Carol |
| role | <role> |
Then the HTTP status code should be "403"
And the OCS status code should be "403"
And the OCS status message should be "No share permission"
Examples:
| dav-path-version | role |
| old | editor |
| old | viewer |
| new | editor |
| new | viewer |
| spaces | editor |
| spaces | viewer |
tests/acceptance/features/apiReshare/resharing.feature
+76 -101
View File
@@ -1,10 +1,7 @@
Feature: Resharing
Feature: re-share resources
As a user
I want to reshare resources
So that other users can have access to them
Note - this feature is run in CI with ACCOUNTS_HASH_DIFFICULTY set to the default for production
See https://github.com/owncloud/ocis/issues/1542 and https://github.com/owncloud/ocis/pull/839
I cannot to re-share resources
This feature has been removed from ocis
Background:
Given these users have been created with default attributes and without skeleton files:
@@ -12,109 +9,87 @@ Feature: Resharing
| Alice |
| Brian |
| Carol |
| Damian |
| Ember |
| Fred |
| Gina |
And user "Alice" has created folder "folder"
And user "Alice" has shared folder "folder" with user "Brian" with permissions "31"
And user "Brian" has shared folder "Shares/folder" with user "Carol" with permissions "31"
And user "Carol" has shared folder "Shares/folder" with user "Damian" with permissions "17"
And user "Alice" has created folder "test"
Scenario Outline: user should only be able to see direct outgoing shares not all the chain
Given user "Brian" has shared folder "Shares/folder" with user "Fred" with permissions "17"
When user "<user>" gets all the shares inside the folder "Shares/folder" using the sharing API
Then the OCS status code should be "100"
And the HTTP status code should be "200"
And the response should contain <visible-shares-no> entries
And user "Brian" should not be included in the response
And user "Carol" <carol-visible> included in the response
And user "Damian" <damian-visible> included in the response
And user "Fred" <fred-visible> included in the response
Scenario Outline: share folder with different roles
Given using <dav-path-version> DAV path
When user "Alice" creates a share inside of space "Personal" with settings:
| path | test |
| shareWith | Brian |
| role | <role> |
Then the HTTP status code should be "200"
And the OCS status code should be "200"
And the fields of the last response to user "Alice" sharing with user "Brian" should include
| permissions | <expected-permissions> |
Examples:
| user | visible-shares-no | carol-visible | damian-visible | fred-visible |
| Brian | 2 | should be | should not be | should be |
| Carol | 1 | should not be | should be | should not be |
| Damian | 0 | should not be | should not be | should not be |
| Fred | 0 | should not be | should not be | should not be |
| dav-path-version | role | expected-permissions |
| old | editor | 15 |
| old | viewer | 1 |
| new | editor | 15 |
| new | viewer | 1 |
| spaces | editor | 15 |
| spaces | viewer | 1 |
Scenario: owners can see all the chain
When user "Alice" gets all the shares inside the folder "folder" using the sharing API
Then the OCS status code should be "100"
And the HTTP status code should be "200"
And the response should contain 3 entries
And user "Brian" should be included in the response
And user "Carol" should be included in the response
And user "Damian" should be included in the response
@skipOnRevaMaster
Scenario: user can't share with more permissions than they have
When user "Damian" shares folder "Shares/folder" with user "Ember" with permissions "31" using the sharing API
Then the OCS status code should be "403"
And the OCS status message should be "Cannot set the requested share permissions"
Scenario Outline: editing reshares
Given user "Carol" has shared folder "Shares/folder" with user "Fred" with permissions "17"
When user "<user>" updates the last share using the sharing API with
| permissions | 31 |
Then the OCS status code should be "<ocs-status-code>"
And user "Fred" <can-upload> able to upload file "filesForUpload/textfile.txt" to "/Shares/folder/textfile.txt"
Scenario Outline: try to re-share folder
Given using <dav-path-version> DAV path
And user "Alice" has created a share inside of space "Personal" with settings:
| path | test |
| shareWith | Brian |
| role | <role> |
When user "Brian" creates a share inside of space "Shares" with settings:
| path | test |
| shareWith | Carol |
| role | <role> |
Then the HTTP status code should be "403"
And the OCS status code should be "403"
And the OCS status message should be "No share permission"
Examples:
| user | ocs-status-code | can-upload |
| Alice | 100 | should be |
| Brian | 998 | should not be |
| Carol | 100 | should be |
| dav-path-version | role |
| old | editor |
| old | viewer |
| new | editor |
| new | viewer |
| spaces | editor |
| spaces | viewer |
Scenario Outline: deleting reshares
Given user "Carol" has shared folder "Shares/folder" with user "Gina" with permissions "17"
When user "<user>" deletes the last share using the sharing API
Then the OCS status code should be "<ocs-status-code>"
And as "Gina" folder "Shares/folder" <exists>
And as "Carol" folder "Shares/folder" should exist
Scenario Outline: try to re-share file
Given user "Alice" has uploaded file with content "other data" to "/textfile1.txt"
Given using <dav-path-version> DAV path
And user "Alice" has created a share inside of space "Personal" with settings:
| path | textfile1.txt |
| shareWith | Brian |
| role | <role> |
When user "Brian" creates a share inside of space "Shares" with settings:
| path | textfile1.txt |
| shareWith | Carol |
| role | <role> |
Then the HTTP status code should be "403"
And the OCS status code should be "403"
And the OCS status message should be "No share permission"
Examples:
| user | ocs-status-code | exists |
| Alice | 100 | should not exist |
| Brian | 998 | should exist |
| Carol | 100 | should not exist |
| dav-path-version | role |
| old | editor |
| old | viewer |
| new | editor |
| new | viewer |
| spaces | editor |
| spaces | viewer |
@skipOnRevaMaster
Scenario Outline: resharing folder with different permissions
When user "<user>" shares folder "Shares/folder" with user "Ember" with permissions "<sharee-permissions>" using the sharing API
Then the OCS status code should be "<ocs-status-code>"
Scenario Outline: try to create a link to the shared folder
Given using OCS API version "<ocs_api_version>"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "all"
When user "Brian" creates a public link share using the sharing API with settings
| path | /Shares/test |
| permissions | 1 |
| password | %public% |
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "<http_status_code>"
Examples:
| user | sharee-permissions | ocs-status-code |
| Brian | 17 | 100 |
| Carol | 31 | 100 |
| Damian | 17 | 100 |
| Damian | 27 | 403 |
| Damian | 31 | 403 |
@skipOnRevaMaster
Scenario Outline: Resharing files with different permissions
Given user "Alice" has uploaded file with content "Random data" to "/file.txt"
And user "Alice" has shared file "/file.txt" with user "Brian" with permissions "<sharee-permissions>"
When user "Brian" shares file "Shares/file.txt" with user "Fred" with permissions "<grantee-permissions>" using the sharing API
Then the OCS status code should be "<ocs-status-code>"
Examples:
| sharee-permissions | grantee-permissions | ocs-status-code |
| 17 | 17 | 100 |
| 17 | 19 | 403 |
| 19 | 19 | 100 |
Scenario Outline: resharing with group with different permissions
Given group "security department" has been created
And the administrator has added a user "Ember" to the group "security department" using the Graph API
And the administrator has added a user "Fred" to the group "security department" using the Graph API
When user "Brian" shares folder "Shares/folder" with group "security department" with permissions "<sharee-permissions>" using the sharing API
Then the OCS status code should be "100"
And user "Ember" <can-upload> able to upload file "filesForUpload/textfile.txt" to "/Shares/folder/textfile.txt"
And user "Fred" <can-upload> able to upload file "filesForUpload/textfile.txt" to "/Shares/folder/textfile.txt"
Examples:
| sharee-permissions | can-upload |
| 17 | should not be |
| 31 | should be |
| ocs_api_version | ocs_status_code | http_status_code |
| 1 | 403 | 200 |
| 2 | 403 | 403 |
tests/acceptance/features/apiSharingNg/propfindShares.feature
+6 -6
View File
@@ -37,11 +37,11 @@ Feature: propfind a shares
And the "PROPFIND" response to user "Brian" should contain a mountpoint "Shares" with these key and value pairs:
| key | value |
| oc:name | <resource> |
| oc:permissions | SR |
| oc:permissions | S |
And the "PROPFIND" response to user "Brian" should contain a mountpoint "Shares" with these key and value pairs:
| key | value |
| oc:name | <resource-2> |
| oc:permissions | SR |
| oc:permissions | S |
Examples:
| resource | resource-2 |
| textfile.txt | textfile (1).txt |
@@ -76,12 +76,12 @@ Feature: propfind a shares
| key | value |
| oc:fileid | UUIDof:<resource> |
| oc:name | <resource> |
| oc:permissions | SR |
| oc:permissions | S |
And the "PROPFIND" response to user "Brian" should contain a mountpoint "Shares" with these key and value pairs:
| key | value |
| oc:fileid | UUIDof:<resource-2> |
| oc:name | <resource-2> |
| oc:permissions | SR |
| oc:permissions | S |
Examples:
| dav-path-version | resource | resource-2 |
| old | textfile.txt | textfile (1).txt |
@@ -114,9 +114,9 @@ Feature: propfind a shares
| key | value |
| oc:fileid | UUIDof:folderToShare (1) |
| oc:name | folderToShare |
| oc:permissions | SR |
| oc:permissions | S |
And the "PROPFIND" response to user "Brian" should contain a mountpoint "folderToShare (1)" with these key and value pairs:
| key | value |
| oc:fileid | UUIDof:textfile.txt |
| oc:name | textfile.txt |
| oc:permissions | SR |
| oc:permissions | S |
tests/acceptance/features/apiSharingNg/shareInvitations.feature
+30 -17
View File
@@ -271,7 +271,6 @@ Feature: Send a sharing invitations
"""
Examples:
| permissions-action |
| permissions/create |
| upload/create |
| path/read |
| quota/read |
@@ -283,10 +282,7 @@ Feature: Send a sharing invitations
| basic/read |
| versions/update |
| deleted/update |
| permissions/update |
| permissions/delete |
| deleted/delete |
| permissions/deny |
Scenario Outline: send share invitation for a folder to user with different permissions
@@ -366,7 +362,6 @@ Feature: Send a sharing invitations
"""
Examples:
| permissions-action |
| permissions/create |
| children/create |
| upload/create |
| path/read |
@@ -380,11 +375,8 @@ Feature: Send a sharing invitations
| path/update |
| versions/update |
| deleted/update |
| permissions/update |
| standard/delete |
| permissions/delete |
| deleted/delete |
| permissions/deny |
Scenario Outline: send share invitation for a file to group with different permissions
@@ -470,7 +462,6 @@ Feature: Send a sharing invitations
"""
Examples:
| permissions-action |
| permissions/create |
| upload/create |
| path/read |
| quota/read |
@@ -482,10 +473,7 @@ Feature: Send a sharing invitations
| basic/read |
| versions/update |
| deleted/update |
| permissions/update |
| permissions/delete |
| deleted/delete |
| permissions/deny |
Scenario Outline: send share invitation for a folder to group with different permissions
@@ -571,7 +559,6 @@ Feature: Send a sharing invitations
"""
Examples:
| permissions-action |
| permissions/create |
| children/create |
| upload/create |
| path/read |
@@ -585,11 +572,8 @@ Feature: Send a sharing invitations
| path/update |
| versions/update |
| deleted/update |
| permissions/update |
| standard/delete |
| permissions/delete |
| deleted/delete |
| permissions/deny |
Scenario Outline: send share invitation with expiration date to user with different roles
@@ -2375,4 +2359,33 @@ Feature: Send a sharing invitations
| Space Viewer | space type is not eligible for sharing |
| Space Editor | space type is not eligible for sharing |
| Manager | space type is not eligible for sharing |
| Co Owner | Key: 'DriveItemInvite.Roles' Error:Field validation for 'Roles' failed on the 'available_role' tag |
| Co Owner | Key: 'DriveItemInvite.Roles' Error:Field validation for 'Roles' failed on the 'available_role' tag |
Scenario Outline: try to send share invitation with re-sharing permissions
Given group "grp1" has been created
And user "Alice" has created folder "FolderToShare"
And the following users have been added to the following groups
| username | groupname |
| Brian | grp1 |
And user "Alice" has uploaded file with content "to share" to "textfile1.txt"
When user "Alice" sends the following share invitation using the Graph API:
| resource | textfile1.txt |
| space | Personal |
| sharee | grp1 |
| shareType | group |
| permissionsAction | <permissions-action> |
Then the HTTP status code should be "400"
When user "Alice" sends the following share invitation using the Graph API:
| resource | FolderToShare |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsAction | <permissions-action> |
Then the HTTP status code should be "400"
Examples:
| permissions-action |
| permissions/create |
| permissions/update |
| permissions/delete |
| permissions/deny |
tests/acceptance/features/apiSpaces/listSpaces.feature
+1 -1
View File
@@ -80,7 +80,7 @@ Feature: List and create spaces
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 without skeleton files
And user "Brian" has created folder "folder"
And user "Brian" has shared folder "folder" with user "Alice" with permissions "31"
And user "Brian" has shared folder "folder" with user "Alice" with permissions "15"
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
tests/acceptance/features/apiSpaces/tag.feature
-4
View File
@@ -136,10 +136,8 @@ Feature: Tag
| space-role | resource-type | resource | http-status-code | should-or-not |
| viewer | file | folderMain/insideTheFolder.txt | 403 | should not |
| editor | file | folderMain/insideTheFolder.txt | 200 | should |
| manager | file | folderMain/insideTheFolder.txt | 200 | should |
| viewer | folder | folderMain | 403 | should not |
| editor | folder | folderMain | 200 | should |
| manager | folder | folderMain | 200 | should |
Scenario Outline: recipient of the shared resource tries to remove a tag
@@ -163,10 +161,8 @@ Feature: Tag
| space-role | resource-type | resource | http-status-code | should-or-not |
| viewer | file | folderMain/insideTheFolder.txt | 403 | should |
| editor | file | folderMain/insideTheFolder.txt | 200 | should not |
| manager | file | folderMain/insideTheFolder.txt | 200 | should not |
| viewer | folder | folderMain | 403 | should |
| editor | folder | folderMain | 200 | should not |
| manager | folder | folderMain | 200 | should not |
Scenario: user removes folder tags
tests/acceptance/features/apiSpacesDavOperation/fileVersionByFileID.feature
+16 -15
View File
@@ -18,19 +18,18 @@ Feature: checking file versions using file id
Scenario Outline: check the file versions of a file shared from project space
Given user "Alice" has created a share inside of space "Project1" with settings:
| path | text.txt |
| shareWith | Brian |
| role | <space-role> |
| path | text.txt |
| shareWith | Brian |
| role | <role> |
When user "Alice" gets the number of versions of file "/text.txt" using file-id path "/meta/<<FILEID>>/v"
Then the HTTP status code should be "207"
And the number of versions should be "1"
When user "Brian" tries to get the number of versions of file "/text.txt" using file-id path "/meta/<<FILEID>>/v"
Then the HTTP status code should be "403"
Examples:
| space-role |
| editor |
| viewer |
| all |
| role |
| editor |
| viewer |
Scenario Outline: check the versions of a file in a shared space as editor/manager
@@ -60,9 +59,9 @@ Feature: checking file versions using file id
Scenario Outline: check the versions of a file after moving to a shared folder inside a project space as editor/viewer
Given user "Alice" has created a folder "testFolder" in space "Project1"
And user "Alice" has created a share inside of space "Project1" with settings:
| path | testFolder |
| shareWith | Brian |
| role | <space-role> |
| path | testFolder |
| shareWith | Brian |
| role | <role> |
And user "Alice" has moved file "text.txt" to "/testFolder/movedText.txt" in space "Project1"
When user "Alice" gets the number of versions of file "/testFolder/movedText.txt" using file-id path "/meta/<<FILEID>>/v"
Then the HTTP status code should be "207"
@@ -70,17 +69,19 @@ Feature: checking file versions using file id
When user "Brian" tries to get the number of versions of file "/Shares/testFolder/movedText.txt" using file-id path "/meta/<<FILEID>>/v"
Then the HTTP status code should be "403"
Examples:
| space-role |
| editor |
| viewer |
| role |
| editor |
| viewer |
@issue-7738
Scenario: check the versions of a file after moving it to a shared folder of a project space shared with all permissions
Scenario: check the versions of a file after moving it to a shared folder inside a project space as manager
Given user "Alice" has created a folder "testFolder" in space "Project1"
And user "Alice" has created a share inside of space "Project1" with settings:
| path | testFolder |
| shareWith | Brian |
| role | all |
And user "Alice" has shared a space "Project1" with settings:
| shareWith | Brian |
| role | manager |
And user "Alice" has moved file "text.txt" to "/testFolder/movedText.txt" in space "Project1"
When user "Brian" gets the number of versions of file "/text.txt" using file-id path "/meta/<<FILEID>>/v"
Then the HTTP status code should be "207"
tests/acceptance/features/apiSpacesDavOperation/propfindByFileId.feature
+2 -2
View File
@@ -110,7 +110,7 @@ Feature: propfind a file using file id
And the "PROPFIND" response to user "Alice" should contain a mountpoint "Brian Murphy" with these key and value pairs:
| key | value |
| oc:name | textfile.txt |
| oc:permissions | SRNVW |
| oc:permissions | SNVW |
Examples:
| dav-path |
| /remote.php/dav/spaces/<<FILEID>> |
@@ -128,7 +128,7 @@ Feature: propfind a file using file id
And the "PROPFIND" response to user "Alice" should contain a mountpoint "Brian Murphy" with these key and value pairs:
| key | value |
| oc:name | textfile.txt |
| oc:permissions | RDNVWZP |
| oc:permissions | DNVW |
Examples:
| dav-path |
| /remote.php/dav/spaces/<<FILEID>> |
tests/acceptance/features/apiSpacesShares/copySpaces.feature
+36 -34
View File
@@ -116,7 +116,9 @@ Feature: copy file
And user "Brian" has shared a space "Project" with settings:
| shareWith | Alice |
| role | <space-role> |
And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "31"
And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "15"
| shareWith | Alice |
| role | <role> |
When user "Alice" copies file "/project.txt" from space "Project" to "/testshare/project.txt" inside space "Shares" using the WebDAV API
Then the HTTP status code should be "201"
And for user "Alice" folder "testshare" of the space "Shares" should contain these files:
@@ -137,7 +139,7 @@ Feature: copy file
And user "Brian" has shared a space "Project" with settings:
| shareWith | Alice |
| role | <space-role> |
And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "17"
And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "1"
When user "Alice" copies file "/project.txt" from space "Project" to "/testshare/project.txt" inside space "Shares" using the WebDAV API
Then the HTTP status code should be "403"
And for user "Alice" folder "testshare" of the space "Shares" should not contain these files:
@@ -182,7 +184,7 @@ Feature: copy file
Scenario: user copies a file from personal space to share space with role editor
Given user "Brian" has created folder "/testshare"
And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "31"
And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "15"
And user "Alice" has uploaded file with content "personal content" to "personal.txt"
When user "Alice" copies file "/personal.txt" from space "Personal" to "/testshare/personal.txt" inside space "Shares" using the WebDAV API
Then the HTTP status code should be "201"
@@ -193,7 +195,7 @@ Feature: copy file
Scenario: user copies a file from personal space to share space with role viewer
Given user "Brian" has created folder "/testshare"
And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "17"
And user "Brian" has shared folder "/testshare" with user "Alice" with permissions "1"
And user "Alice" has uploaded file with content "personal content" to "/personal.txt"
When user "Alice" copies file "/personal.txt" from space "Personal" to "/testshare/personal.txt" inside space "Shares" using the WebDAV API
Then the HTTP status code should be "403"
@@ -213,8 +215,8 @@ Feature: copy file
And for user "Alice" the content of the file "/testshare.txt" of the space "Personal" should be "testshare content"
Examples:
| permissions |
| 31 |
| 17 |
| 15 |
| 1 |
Scenario Outline: user copies a file from share space with different role to project space with different role
@@ -233,10 +235,10 @@ Feature: copy file
And for user "Alice" the content of the file "/testshare.txt" of the space "Project" should be "testshare content"
Examples:
| space-role | permissions |
| manager | 31 |
| manager | 17 |
| editor | 31 |
| editor | 17 |
| manager | 15 |
| manager | 1 |
| editor | 15 |
| editor | 1 |
Scenario Outline: user copies a file from share space with different role to project space with role viewer
@@ -254,8 +256,8 @@ Feature: copy file
| /testshare.txt |
Examples:
| permissions |
| 31 |
| 17 |
| 15 |
| 1 |
Scenario Outline: user copies a file from share space with different role to share space with role editor
@@ -263,7 +265,7 @@ Feature: copy file
And user "Brian" has created folder "/testshare2"
And user "Brian" has uploaded file with content "testshare1 content" to "/testshare1/testshare1.txt"
And user "Brian" has shared folder "/testshare1" with user "Alice" with permissions "<permissions>"
And user "Brian" has shared folder "/testshare2" with user "Alice" with permissions "31"
And user "Brian" has shared folder "/testshare2" with user "Alice" with permissions "15"
When user "Alice" copies file "/testshare1/testshare1.txt" from space "Shares" to "/testshare2/testshare1.txt" inside space "Shares" using the WebDAV API
Then the HTTP status code should be "201"
And for user "Alice" folder "testshare2" of the space "Shares" should contain these files:
@@ -274,8 +276,8 @@ Feature: copy file
And for user "Brian" the content of the file "/testshare1/testshare1.txt" of the space "Personal" should be "testshare1 content"
Examples:
| permissions |
| 31 |
| 17 |
| 15 |
| 1 |
Scenario Outline: user copies a file from share space with different role to share space with role viewer
@@ -283,7 +285,7 @@ Feature: copy file
And user "Brian" has created folder "/testshare2"
And user "Brian" has uploaded file with content "testshare1 content" to "/testshare1/testshare1.txt"
And user "Brian" has shared folder "/testshare1" with user "Alice" with permissions "<permissions>"
And user "Brian" has shared folder "/testshare2" with user "Alice" with permissions "17"
And user "Brian" has shared folder "/testshare2" with user "Alice" with permissions "1"
When user "Alice" copies file "/testshare1/testshare1.txt" from space "Shares" to "/testshare2/testshare1.txt" inside space "Shares" using the WebDAV API
Then the HTTP status code should be "403"
And for user "Alice" folder "testshare2" of the space "Shares" should not contain these files:
@@ -292,8 +294,8 @@ Feature: copy file
| testshare1.txt |
Examples:
| permissions |
| 31 |
| 17 |
| 15 |
| 1 |
Scenario Outline: copying a folder within the same project space with different role
@@ -378,12 +380,12 @@ Feature: copy file
| <entry> |
Examples:
| space-role | should-or-not | permissions | status-code | parent-folder | entry |
| manager | should | 31 | 201 | testshare/folder1 | demo.txt |
| editor | should | 31 | 201 | testshare/folder1 | demo.txt |
| viewer | should | 31 | 201 | testshare/folder1 | demo.txt |
| manager | should not | 17 | 403 | testshare | folder1 |
| editor | should not | 17 | 403 | testshare | folder1 |
| viewer | should not | 17 | 403 | testshare | folder1 |
| manager | should | 15 | 201 | testshare/folder1 | demo.txt |
| editor | should | 15 | 201 | testshare/folder1 | demo.txt |
| viewer | should | 15 | 201 | testshare/folder1 | demo.txt |
| manager | should not | 1 | 403 | testshare | folder1 |
| editor | should not | 1 | 403 | testshare | folder1 |
| viewer | should not | 1 | 403 | testshare | folder1 |
Scenario Outline: user copies a folder from personal space to project space with different role
@@ -416,8 +418,8 @@ Feature: copy file
| <resource> |
Examples:
| permissions | should-or-not | status-code | parent-folder | resource |
| 31 | should | 201 | testshare/folder1 | demo.txt |
| 17 | should not | 403 | testshare | folder1 |
| 15 | should | 201 | testshare/folder1 | demo.txt |
| 1 | should not | 403 | testshare | folder1 |
Scenario Outline: user copies a folder from share space with different role to personal space
@@ -432,8 +434,8 @@ Feature: copy file
And for user "Alice" the content of the file "/testshare.txt" of the space "Personal" should be "testshare content"
Examples:
| permissions |
| 31 |
| 17 |
| 15 |
| 1 |
Scenario Outline: user copies a folder from share space with different role to project space with different role
@@ -452,10 +454,10 @@ Feature: copy file
| testshare.txt |
Examples:
| space-role | permissions |
| manager | 31 |
| manager | 17 |
| editor | 31 |
| editor | 17 |
| manager | 15 |
| manager | 1 |
| editor | 15 |
| editor | 1 |
Scenario Outline: user copies a folder from share space with different role to project space with role viewer
@@ -474,8 +476,8 @@ Feature: copy file
| folder1 |
Examples:
| permissions |
| 31 |
| 17 |
| 15 |
| 1 |
Scenario: copying a file to a folder with no permissions
tests/acceptance/features/apiSpacesShares/shareOperations.feature
+36 -36
View File
@@ -19,7 +19,7 @@ Feature: sharing
| propertyName |
| ocs:share-permissions |
Then the HTTP status code should be "207"
And the single response should contain a property "ocs:share-permissions" with value "19"
And the single response should contain a property "ocs:share-permissions" with value "3"
Scenario: correct webdav share-permissions for received group shared file with edit and reshare permissions
@@ -27,15 +27,15 @@ Feature: sharing
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file with content "foo" to "/tmp.txt"
And user "Alice" has created a share with settings
| path | /tmp.txt |
| shareType | group |
| permissions | share,update,read |
| shareWith | grp1 |
| path | /tmp.txt |
| shareType | group |
| permissions | update,read |
| shareWith | grp1 |
When user "Brian" gets the following properties of file "/tmp.txt" inside space "Shares" using the WebDAV API
| propertyName |
| ocs:share-permissions |
Then the HTTP status code should be "207"
And the single response should contain a property "ocs:share-permissions" with value "19"
And the single response should contain a property "ocs:share-permissions" with value "3"
Scenario: correct webdav share-permissions for received file with edit permissions but no reshare permissions
@@ -67,9 +67,9 @@ Feature: sharing
Given user "Alice" has uploaded file with content "foo" to "/tmp.txt"
And user "Alice" has shared file "tmp.txt" with user "Brian"
When user "Alice" updates the last share using the sharing API with
| permissions | share,read |
| permissions | read |
Then the HTTP status code should be "200"
And as user "Brian" file "/tmp.txt" inside space "Shares" should contain a property "ocs:share-permissions" with value "17"
And as user "Brian" file "/tmp.txt" inside space "Shares" should contain a property "ocs:share-permissions" with value "1"
Scenario: correct webdav share-permissions for received group shared file with reshare permissions but no edit permissions
@@ -77,15 +77,15 @@ Feature: sharing
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file with content "foo" to "/tmp.txt"
And user "Alice" has created a share with settings
| path | /tmp.txt |
| shareType | group |
| permissions | share,read |
| shareWith | grp1 |
| path | /tmp.txt |
| shareType | group |
| permissions | read |
| shareWith | grp1 |
When user "Brian" gets the following properties of file "/tmp.txt" inside space "Shares" using the WebDAV API
| propertyName |
| ocs:share-permissions |
Then the HTTP status code should be "207"
And the single response should contain a property "ocs:share-permissions" with value "17"
And the single response should contain a property "ocs:share-permissions" with value "1"
Scenario: correct webdav share-permissions for received folder with all permissions
@@ -95,7 +95,7 @@ Feature: sharing
| propertyName |
| ocs:share-permissions |
Then the HTTP status code should be "207"
And the single response should contain a property "ocs:share-permissions" with value "31"
And the single response should contain a property "ocs:share-permissions" with value "15"
Scenario: correct webdav share-permissions for received group shared folder with all permissions
@@ -110,16 +110,16 @@ Feature: sharing
| propertyName |
| ocs:share-permissions |
Then the HTTP status code should be "207"
And the single response should contain a property "ocs:share-permissions" with value "31"
And the single response should contain a property "ocs:share-permissions" with value "15"
Scenario: correct webdav share-permissions for received folder with all permissions but edit
Given user "Alice" has created folder "/tmp"
And user "Alice" has shared file "/tmp" with user "Brian"
When user "Alice" updates the last share using the sharing API with
| permissions | share,delete,create,read |
| permissions | delete,create,read |
Then the HTTP status code should be "200"
And as user "Brian" folder "/tmp" inside space "Shares" should contain a property "ocs:share-permissions" with value "29"
And as user "Brian" folder "/tmp" inside space "Shares" should contain a property "ocs:share-permissions" with value "13"
Scenario: correct webdav share-permissions for received group shared folder with all permissions but edit
@@ -127,24 +127,24 @@ Feature: sharing
And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "/tmp"
And user "Alice" has created a share with settings
| path | tmp |
| shareType | group |
| shareWith | grp1 |
| permissions | share,delete,create,read |
| path | tmp |
| shareType | group |
| shareWith | grp1 |
| permissions | delete,create,read |
When user "Brian" gets the following properties of folder "/tmp" inside space "Shares" using the WebDAV API
| propertyName |
| ocs:share-permissions |
Then the HTTP status code should be "207"
And the single response should contain a property "ocs:share-permissions" with value "29"
And the single response should contain a property "ocs:share-permissions" with value "13"
Scenario: correct webdav share-permissions for received folder with all permissions but create
Given user "Alice" has created folder "/tmp"
And user "Alice" has shared file "/tmp" with user "Brian"
When user "Alice" updates the last share using the sharing API with
| permissions | share,delete,update,read |
| permissions | delete,update,read |
Then the HTTP status code should be "200"
And as user "Brian" folder "/tmp" inside space "Shares" should contain a property "ocs:share-permissions" with value "27"
And as user "Brian" folder "/tmp" inside space "Shares" should contain a property "ocs:share-permissions" with value "11"
Scenario: correct webdav share-permissions for received group shared folder with all permissions but create
@@ -152,24 +152,24 @@ Feature: sharing
And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "/tmp"
And user "Alice" has created a share with settings
| path | tmp |
| shareType | group |
| shareWith | grp1 |
| permissions | share,delete,update,read |
| path | tmp |
| shareType | group |
| shareWith | grp1 |
| permissions | delete,update,read |
When user "Brian" gets the following properties of folder "/tmp" inside space "Shares" using the WebDAV API
| propertyName |
| ocs:share-permissions |
Then the HTTP status code should be "207"
And the single response should contain a property "ocs:share-permissions" with value "27"
And the single response should contain a property "ocs:share-permissions" with value "11"
Scenario: correct webdav share-permissions for received folder with all permissions but delete
Given user "Alice" has created folder "/tmp"
And user "Alice" has shared file "/tmp" with user "Brian"
When user "Alice" updates the last share using the sharing API with
| permissions | share,create,update,read |
| permissions | create,update,read |
Then the HTTP status code should be "200"
And as user "Brian" folder "/tmp" inside space "Shares" should contain a property "ocs:share-permissions" with value "23"
And as user "Brian" folder "/tmp" inside space "Shares" should contain a property "ocs:share-permissions" with value "7"
Scenario: correct webdav share-permissions for received group shared folder with all permissions but delete
@@ -177,15 +177,15 @@ Feature: sharing
And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "/tmp"
And user "Alice" has created a share with settings
| path | tmp |
| shareType | group |
| shareWith | grp1 |
| permissions | share,create,update,read |
| path | tmp |
| shareType | group |
| shareWith | grp1 |
| permissions | create,update,read |
When user "Brian" gets the following properties of folder "/tmp" inside space "Shares" using the WebDAV API
| propertyName |
| ocs:share-permissions |
Then the HTTP status code should be "207"
And the single response should contain a property "ocs:share-permissions" with value "23"
And the single response should contain a property "ocs:share-permissions" with value "7"
Scenario: correct webdav share-permissions for received folder with all permissions but share
tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature
+2 -60
View File
@@ -143,7 +143,7 @@ Feature: share resources where the sharee receives the share in multiple ways
| file_target | /zzzfolder |
| item_type | folder |
| permissions | read,delete |
When user "Carol" shares folder "zzzfolder" with user "Alice" with permissions "read,share" using the sharing API
When user "Carol" shares folder "zzzfolder" with user "Alice" with permissions "read" using the sharing API
Then the HTTP status code should be "200"
And the OCS status code should be "<ocs-status-code>"
And as "Alice" the info about the last share by user "Carol" with user "Alice" should include
@@ -262,38 +262,6 @@ Feature: share resources where the sharee receives the share in multiple ways
And user "Alice" should not be able to delete folder "/Shares/child1/child2"
Scenario: sharing parent folder to user with all permissions and its child folder to group with read permission then check reshare operation
Given group "grp1" has been created
And user "Carol" has been created with default attributes and without skeleton files
And user "Carol" has created the following folders
| path |
| /parent |
| /parent/child1 |
| /parent/child1/child2 |
And user "Alice" has been added to group "grp1"
And user "Brian" has been added to group "grp1"
And user "Carol" has created a share with settings
| path | /parent |
| shareType | user |
| shareWith | Brian |
| permissions | all |
And user "Carol" has created a share with settings
| path | /parent/child1 |
| shareType | group |
| shareWith | grp1 |
| permissions | read |
When user "Brian" creates a share using the sharing API with settings
| path | /Shares/parent |
| shareType | user |
| shareWith | Alice |
| permissions | read |
Then the HTTP status code should be "200"
And the OCS status code should be "100"
And as "Brian" folder "/Shares/child1" should exist
And as "Alice" folder "/Shares/child1" should exist
And as "Alice" folder "/Shares/parent" should exist
Scenario: sharing parent folder to group with read permission and its child folder to user with all permissions then check create operation
Given group "grp1" has been created
And user "Carol" has been created with default attributes and without skeleton files
@@ -373,32 +341,6 @@ Feature: share resources where the sharee receives the share in multiple ways
And user "Alice" should not be able to delete folder "/Shares/parent/child1"
Scenario: sharing parent folder to group with read permission and its child folder to user with all permissions then check reshare operation
Given group "grp1" has been created
And user "Carol" has been created with default attributes and without skeleton files
And user "Carol" has created the following folders
| path |
| /parent |
| /parent/child1 |
| /parent/child1/child2 |
And user "Alice" has been added to group "grp1"
And user "Brian" has been added to group "grp1"
And user "Carol" has created a share with settings
| path | /parent |
| shareType | group |
| shareWith | grp1 |
| permissions | read |
And user "Carol" has created a share with settings
| path | /parent/child1 |
| shareType | user |
| shareWith | Brian |
| permissions | all |
And user "Brian" should be able to share folder "/Shares/child1" with user "Alice" with permissions "read" using the sharing API
And as "Brian" folder "/Shares/parent" should exist
And as "Alice" folder "/Shares/parent" should exist
And as "Alice" folder "/Shares/child1" should exist
Scenario: sharing parent folder to one group with all permissions and its child folder to another group with read permission
Given these groups have been created:
| groupname |
@@ -429,7 +371,7 @@ Feature: share resources where the sharee receives the share in multiple ways
And user "Alice" should be able to delete folder "/Shares/parent/child1/fo1"
And user "Alice" should be able to delete folder "/Shares/parent/child1/child2/fo2"
And user "Alice" should be able to rename file "/Shares/parent/child1/child2/textfile-2.txt" to "/Shares/parent/child1/child2/rename.txt"
And user "Alice" should be able to share folder "/Shares/parent/child1" with group "grp3" with permissions "all" using the sharing API
And user "Alice" should not be able to share folder "/Shares/parent/child1" with group "grp3" with permissions "all" using the sharing API
And as "Brian" folder "/Shares/child1" should exist
And user "Brian" should not be able to create folder "/Shares/child1/fo1"
And user "Brian" should not be able to create folder "/Shares/child1/child2/fo2"
tests/acceptance/features/coreApiShareManagementBasicToShares/createShareToSharesFolder.feature
+18 -117
View File
@@ -8,7 +8,7 @@ Feature: sharing
Given user "Alice" has been created with default attributes and without skeleton files
@smokeTest
Scenario Outline: creating a share of a file with a user, the default permissions are read(1)+update(2)+can-share(16)
Scenario Outline: creating a share of a file with a user, the default permissions are read(1)+update(2)
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
@@ -21,7 +21,7 @@ Feature: sharing
| share_with_user_type | 0 |
| file_target | /Shares/textfile0.txt |
| path | /textfile0.txt |
| permissions | share,read,update |
| permissions | read,update |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| item_type | file |
@@ -47,7 +47,7 @@ Feature: sharing
| share_with_displayname | %displayname% |
| file_target | /Shares/sample,1.txt |
| path | /sample,1.txt |
| permissions | share,read,update |
| permissions | read,update |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| item_type | file |
@@ -83,11 +83,11 @@ Feature: sharing
Examples:
| ocs-api-version | requested-permissions | granted-permissions | ocs-status-code |
# Ask for full permissions. You get share plus read plus update. create and delete do not apply to shares of a file
| 1 | 31 | 19 | 100 |
| 2 | 31 | 19 | 200 |
# Ask for read, share (17), create and delete. You get share plus read
| 1 | 29 | 17 | 100 |
| 2 | 29 | 17 | 200 |
| 1 | 15 | 3 | 100 |
| 2 | 15 | 3 | 200 |
# Ask for read, create and delete. You get share plus read
| 1 | 13 | 1 | 100 |
| 2 | 13 | 1 | 200 |
# Ask for read, update, create, delete. You get read plus update.
| 1 | 15 | 3 | 100 |
| 2 | 15 | 3 | 200 |
@@ -128,7 +128,7 @@ Feature: sharing
| 2 | 400 |
@issue-2133
Scenario Outline: creating a share of a folder with a user, the default permissions are all permissions(31)
Scenario Outline: creating a share of a folder with a user, the default permissions are all permissions(15)
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "/FOLDER"
@@ -153,7 +153,7 @@ Feature: sharing
| 2 | 200 |
Scenario Outline: creating a share of a file with a group, the default permissions are read(1)+update(2)+can-share(16)
Scenario Outline: creating a share of a file with a group, the default permissions are read(1)+update(2)
Given using OCS API version "<ocs-api-version>"
And group "grp1" has been created
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
@@ -165,7 +165,7 @@ Feature: sharing
| share_with_displayname | grp1 |
| file_target | /Shares/textfile0.txt |
| path | /textfile0.txt |
| permissions | share,read,update |
| permissions | read,update |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| item_type | file |
@@ -178,7 +178,7 @@ Feature: sharing
| 2 | 200 |
Scenario Outline: creating a share of a folder with a group, the default permissions are all permissions(31)
Scenario Outline: creating a share of a folder with a group, the default permissions are all permissions(15)
Given using OCS API version "<ocs-api-version>"
And group "grp1" has been created
And user "Alice" has created folder "/FOLDER"
@@ -363,7 +363,7 @@ Feature: sharing
| share_with | brian |
| file_target | /Shares/randomfile.txt |
| path | /randomfile.txt |
| permissions | share,read,update |
| permissions | read,update |
| uid_owner | %username% |
Then user "brian" should see the following elements
| /Shares/randomfile.txt |
@@ -496,56 +496,6 @@ Feature: sharing
And the content of file "/Shares/common/sub/textfile0.txt" for user "Brian" should be "BLABLABLA" plus end-of-line
And the content of file "/common/sub/textfile0.txt" for user "Alice" should be "BLABLABLA" plus end-of-line
@issue-enterprise-3896 @issue-2201
Scenario: sharing back to resharer is allowed
Given these users have been created with default attributes and without skeleton files:
| username |
| Brian |
| Carol |
And user "Alice" has created folder "userZeroFolder"
And user "Alice" has shared folder "userZeroFolder" with user "Brian"
And user "Brian" has created folder "/Shares/userZeroFolder/userOneFolder"
And user "Brian" has shared folder "/Shares/userZeroFolder/userOneFolder" with user "Carol" with permissions "read, share"
When user "Carol" shares folder "/Shares/userOneFolder" with user "Brian" using the sharing API
Then the HTTP status code should be "200"
# Then the HTTP status code should be "405"
And the sharing API should report to user "Brian" that no shares are in the pending state
And as "Brian" folder "/Shares/userOneFolder" should not exist
@issue-enterprise-3896 @issue-2201
Scenario: sharing back to original sharer is allowed
Given these users have been created with default attributes and without skeleton files:
| username |
| Brian |
| Carol |
And user "Alice" has created folder "userZeroFolder"
And user "Alice" has shared folder "userZeroFolder" with user "Brian"
And user "Brian" has created folder "/Shares/userZeroFolder/userOneFolder"
And user "Brian" has shared folder "/Shares/userZeroFolder/userOneFolder" with user "Carol" with permissions "read, share"
When user "Carol" shares folder "/Shares/userOneFolder" with user "Alice" using the sharing API
Then the HTTP status code should be "200"
# Then the HTTP status code should be "405"
And the sharing API should report to user "Alice" that no shares are in the pending state
And as "Alice" folder "/Shares/userOneFolder" should not exist
@issue-enterprise-3896 @issue-2201
Scenario: sharing a subfolder to a user that already received parent folder share
Given these users have been created with default attributes and without skeleton files:
| username |
| Brian |
| Carol |
| David |
And user "Alice" has created folder "userZeroFolder"
And user "Alice" has shared folder "userZeroFolder" with user "Brian"
And user "Alice" has shared folder "userZeroFolder" with user "Carol"
And user "Brian" has created folder "/Shares/userZeroFolder/userOneFolder"
And user "Brian" has shared folder "/Shares/userZeroFolder/userOneFolder" with user "David" with permissions "read, share"
When user "David" shares folder "/Shares/userOneFolder" with user "Carol" using the sharing API
Then the HTTP status code should be "200"
# Then the HTTP status code should be "405"
And the sharing API should report to user "Carol" that no shares are in the pending state
And as "Carol" folder "/Shares/userOneFolder" should not exist
@smokeTest
Scenario Outline: creating a share of a renamed file
Given using OCS API version "<ocs-api-version>"
@@ -560,7 +510,7 @@ Feature: sharing
| share_with_displayname | %displayname% |
| file_target | /Shares/renamed.txt |
| path | /renamed.txt |
| permissions | share,read,update |
| permissions | read,update |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| item_type | file |
@@ -630,59 +580,10 @@ Feature: sharing
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with group "grp1"
When user "Alice" shares file "textfile0.txt" with group "grp1" using the sharing API
Then the HTTP status code should be "<http-status-code>"
Then the HTTP status code should be "<http-status>"
And the OCS status code should be "403"
And the OCS status message should be "Path already shared with this group"
Examples:
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
@issue-2215
Scenario Outline: sharing the shares folder to users is not possible
Given using OCS API version "<ocs-api-version>"
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 "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
When user "Brian" shares folder "Shares" with user "Carol" using the sharing API
Then the HTTP status code should be "<http-status-code>"
And the OCS status code should be "403"
And the OCS status message should be "Path contains files shared with you"
Examples:
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
@issue-2215
Scenario Outline: sharing the shares folder to groups is not possible
Given using OCS API version "<ocs-api-version>"
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 group "share_group" has been created
And user "Carol" has been added to group "share_group"
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
When user "Brian" shares folder "Shares" with group "share_group" using the sharing API
Then the HTTP status code should be "<http-status-code>"
And the OCS status code should be "403"
And the OCS status message should be "Path contains files shared with you"
Examples:
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
@issue-2215
Scenario Outline: sharing the shares folder as public link is not possible
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
When user "Brian" creates a public link share of folder "Shares" using the sharing API
Then the HTTP status code should be "<http-status-code>"
And the OCS status code should be "403"
And the OCS status message should be "Path contains files shared with you"
Examples:
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
| ocs-api-version | http-status |
| 1 | 200 |
| 2 | 403 |
tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature
+1 -1
View File
@@ -94,7 +94,7 @@ Feature: accept/decline shares coming from internal users
| share_type | user |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| permissions | share,read,update |
| permissions | read,update |
| uid_file_owner | %username% |
| displayname_file_owner | %displayname% |
| state | 0 |
tests/acceptance/features/coreApiShareManagementToShares/acceptSharesToSharesFolder.feature
+1 -1
View File
@@ -44,7 +44,7 @@ Feature: accept/decline shares coming from internal users to the Shares folder
| share_with_displayname | %displayname% |
| file_target | /Shares/textfile0.txt |
| path | /Shares/textfile0.txt |
| permissions | share,read,update |
| permissions | read,update |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| item_type | file |
tests/acceptance/features/coreApiShareManagementToShares/mergeShare.feature
+3 -3
View File
@@ -30,7 +30,7 @@ Feature: sharing
And user "Brian" accepts share "/merge-test-outside-perms" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And as user "Brian" folder "/Shares/merge-test-outside-perms" should contain a property "oc:permissions" with value "SRDNVCK"
And as user "Brian" folder "/Shares/merge-test-outside-perms" should contain a property "oc:permissions" with value "SDNVCK"
And as "Brian" folder "/Shares/merge-test-outside-perms (2)" should not exist
@@ -56,7 +56,7 @@ Feature: sharing
And user "Brian" accepts share "/merge-test-outside-twogroups-perms" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And as user "Brian" folder "/Shares/merge-test-outside-twogroups-perms" should contain a property "oc:permissions" with value "SRDNVCK"
And as user "Brian" folder "/Shares/merge-test-outside-twogroups-perms" should contain a property "oc:permissions" with value "SDNVCK"
And as "Brian" folder "/Shares/merge-test-outside-twogroups-perms (2)" should not exist
@@ -70,7 +70,7 @@ Feature: sharing
And user "Brian" accepts share "/merge-test-outside-twogroups-member-perms" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "100"
And the HTTP status code of responses on all endpoints should be "200"
And as user "Brian" folder "/Shares/merge-test-outside-twogroups-member-perms" should contain a property "oc:permissions" with value "SRDNVCK"
And as user "Brian" folder "/Shares/merge-test-outside-twogroups-member-perms" should contain a property "oc:permissions" with value "SDNVCK"
And as "Brian" folder "/Shares/merge-test-outside-twogroups-member-perms (2)" should not exist
tests/acceptance/features/coreApiShareManagementToShares/moveReceivedShare.feature
+14 -14
View File
@@ -136,10 +136,10 @@ Feature: sharing
And as "Alice" file "Shares/TMP" should not exist
Scenario: receiver renames a received share with share, read, change permissions inside the Shares folder
Scenario: receiver renames a received share with read, change permissions inside the Shares folder
Given user "Alice" has created folder "folderToShare"
And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "/folderToShare/fileInside"
And user "Alice" has shared folder "folderToShare" with user "Brian" with permissions "share,read,change"
And user "Alice" has shared folder "folderToShare" with user "Brian" with permissions "read,change"
When user "Brian" moves folder "/Shares/folderToShare" to "/Shares/myFolder" using the WebDAV API
Then the HTTP status code should be "201"
And as "Brian" folder "/Shares/myFolder" should exist
@@ -151,10 +151,10 @@ Feature: sharing
But as "Alice" file "/folderToShare/fileInside" should not exist
Scenario: receiver tries to rename a received share with share, read permissions inside the Shares folder
Scenario: receiver tries to rename a received share with read permissions inside the Shares folder
Given user "Alice" has created folder "folderToShare"
And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "/folderToShare/fileInside"
And user "Alice" has shared folder "folderToShare" with user "Brian" with permissions "share,read"
And user "Alice" has shared folder "folderToShare" with user "Brian" with permissions "read"
When user "Brian" moves folder "/Shares/folderToShare" to "/Shares/myFolder" using the WebDAV API
Then the HTTP status code should be "201"
And as "Brian" folder "/Shares/myFolder" should exist
@@ -205,22 +205,22 @@ Feature: sharing
But as "Alice" folder "myFolder" should not exist
Scenario: receiver renames a received file share with read,update,share permissions inside the Shares folder in group sharing
Scenario: receiver renames a received file share with read,update permissions inside the Shares folder in group sharing
Given group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt"
And user "Alice" has shared file "fileToShare.txt" with group "grp1" with permissions "read,update,share"
And user "Alice" has shared file "fileToShare.txt" with group "grp1" with permissions "read,update"
When user "Brian" moves folder "/Shares/fileToShare.txt" to "/Shares/newFile.txt" using the WebDAV API
Then the HTTP status code should be "201"
And as "Brian" file "/Shares/newFile.txt" should exist
But as "Alice" file "/Shares/newFile.txt" should not exist
Scenario: receiver renames a received folder share with share, read, change permissions inside the Shares folder in group sharing
Scenario: receiver renames a received folder share with read, change permissions inside the Shares folder in group sharing
Given group "grp1" has been created
And user "Alice" has created folder "PARENT"
And user "Brian" has been added to group "grp1"
And user "Alice" has shared folder "PARENT" with group "grp1" with permissions "share,read,change"
And user "Alice" has shared folder "PARENT" with group "grp1" with permissions "read,change"
When user "Brian" moves folder "/Shares/PARENT" to "/Shares/myFolder" using the WebDAV API
Then the HTTP status code should be "201"
And as "Brian" folder "/Shares/myFolder" should exist
@@ -231,18 +231,18 @@ Feature: sharing
Given group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "fileToShare.txt"
And user "Alice" has shared file "fileToShare.txt" with group "grp1" with permissions "share,read"
And user "Alice" has shared file "fileToShare.txt" with group "grp1" with permissions "read"
When user "Brian" moves file "/Shares/fileToShare.txt" to "/Shares/newFile.txt" using the WebDAV API
Then the HTTP status code should be "201"
And as "Brian" file "/Shares/newFile.txt" should exist
But as "Alice" file "/Shares/newFile.txt" should not exist
Scenario: receiver renames a received folder share with share, read permissions inside the Shares folder in group sharing
Scenario: receiver renames a received folder share with read permissions inside the Shares folder in group sharing
Given group "grp1" has been created
And user "Alice" has created folder "PARENT"
And user "Brian" has been added to group "grp1"
And user "Alice" has shared folder "PARENT" with group "grp1" with permissions "share,read"
And user "Alice" has shared folder "PARENT" with group "grp1" with permissions "read"
When user "Brian" moves folder "/Shares/PARENT" to "/Shares/myFolder" using the WebDAV API
Then the HTTP status code should be "201"
And as "Brian" folder "/Shares/myFolder" should exist
@@ -270,19 +270,19 @@ Feature: sharing
| @a#8a=b?c=d | @a#8a=b?c=d grp | ?a#8 a=b?c=d |
@issue-2141
Scenario Outline: receiver renames a received file share to name with special characters with share, read, change permissions in group sharing
Scenario Outline: receiver renames a received file share to name with special characters with read, change permissions in group sharing
Given group "grp1" has been created
And user "Carol" has been added to group "grp1"
And user "Alice" has created folder "<sharer-folder>"
And user "Alice" has created folder "<group-folder>"
And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "/<sharer-folder>/fileInside"
And user "Alice" has uploaded file with content "thisIsAFileInsideTheSharedFolder" to "/<group-folder>/fileInside"
And user "Alice" has shared folder "<sharer-folder>" with user "Brian" with permissions "share,read,change"
And user "Alice" has shared folder "<sharer-folder>" with user "Brian" with permissions "read,change"
When user "Brian" moves folder "/Shares/<sharer-folder>/fileInside" to "/Shares/<sharer-folder>/<receiver_file>" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "<sharer-folder>/<receiver_file>" should exist
And as "Brian" file "/Shares/<sharer-folder>/<receiver_file>" should exist
When user "Alice" shares folder "<group-folder>" with group "grp1" with permissions "share,read,change" using the sharing API
When user "Alice" shares folder "<group-folder>" with group "grp1" with permissions "read,change" using the sharing API
And user "Carol" moves folder "/Shares/<group-folder>/fileInside" to "/Shares/<group-folder>/<receiver_file>" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "<group-folder>/<receiver_file>" should exist
tests/acceptance/features/coreApiShareOperationsToShares1/gettingShares.feature
+2 -43
View File
@@ -59,47 +59,6 @@ Feature: sharing
| 1 | 100 |
| 2 | 200 |
@smokeTest
Scenario Outline: getting all shares of a file with reshares
Given using OCS API version "<ocs-api-version>"
And these users have been created with default attributes and without skeleton files:
| username |
| Carol |
| David |
And user "Alice" has uploaded file with content "some data" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
And user "Brian" has shared file "/Shares/textfile0.txt" with user "Carol"
When user "Alice" gets all the shares with reshares of the file "textfile0.txt" using the sharing API
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And user "Brian" should be included in the response
And user "Carol" should be included in the response
And user "David" should not be included in the response
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@smokeTest
Scenario Outline: resource can be reshared to resource owner
Given using OCS API version "<ocs-api-version>"
And group "grp1" has been created
And user "Carol" has been created with default attributes and without skeleton files
And user "Carol" has been added to group "grp1"
And user "Carol" has created folder "/shared"
And user "Carol" has uploaded file with content "some data" to "/shared/shared_file.txt"
And user "Carol" has shared folder "/shared" with user "Brian"
And user "Brian" has shared folder "/Shares/shared" with group "grp1"
# no need to accept this share as it is Carol's file
When user "Carol" gets all the shares shared with her using the sharing API
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And file "/Shares/shared" should be included in the response
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@smokeTest @issue-1226 @issue-1270 @issue-1271
Scenario Outline: getting share info of a share
Given using OCS API version "<ocs-api-version>"
@@ -117,7 +76,7 @@ Feature: sharing
| file_source | A_STRING |
| file_target | /Shares/file_to_share.txt |
| path | /file_to_share.txt |
| permissions | share,read,update |
| permissions | read,update |
| stime | A_NUMBER |
| storage | A_STRING |
| mail_send | 0 |
@@ -181,7 +140,7 @@ Feature: sharing
| file_source | A_STRING |
| file_target | /Shares/file_to_share.txt |
| path | /PARENT/file_to_share.txt |
| permissions | share,read,update |
| permissions | read,update |
| stime | A_NUMBER |
| storage | A_STRING |
| mail_send | 0 |
tests/acceptance/features/coreApiShareOperationsToShares2/getWebDAVSharePermissions.feature
+39 -39
View File
@@ -31,7 +31,7 @@ Feature: sharing
| spaces |
@skipOnReva
Scenario Outline: check webdav share-permissions for received file with edit and reshare permissions
Scenario Outline: check webdav share-permissions for received file with edit
Given using <dav-path-version> DAV path
And user "Alice" has uploaded file with content "foo" to "/tmp.txt"
And user "Alice" has shared file "/tmp.txt" with user "Brian"
@@ -39,28 +39,28 @@ Feature: sharing
| propertyName |
| ocs:share-permissions |
Then the HTTP status code should be "207"
And the single response should contain a property "ocs:share-permissions" with value "19"
And the single response should contain a property "ocs:share-permissions" with value "3"
Examples:
| dav-path-version |
| old |
| new |
Scenario Outline: check webdav share-permissions for received group shared file with edit and reshare permissions
Scenario Outline: check webdav share-permissions for received group shared file with edit
Given using <dav-path-version> DAV path
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file with content "foo" to "/tmp.txt"
And user "Alice" has created a share with settings
| path | /tmp.txt |
| shareType | group |
| permissions | share,update,read |
| shareWith | grp1 |
| path | /tmp.txt |
| shareType | group |
| permissions | update,read |
| shareWith | grp1 |
When user "Brian" gets the following properties of file "/Shares/tmp.txt" using the WebDAV API
| propertyName |
| ocs:share-permissions |
Then the HTTP status code should be "207"
And the single response should contain a property "ocs:share-permissions" with value "19"
And the single response should contain a property "ocs:share-permissions" with value "3"
Examples:
| dav-path-version |
| old |
@@ -102,14 +102,14 @@ Feature: sharing
| new |
@skipOnReva @issue-2213
Scenario Outline: check webdav share-permissions for received file with reshare permissions but no edit permissions
Scenario Outline: check webdav share-permissions for received file without edit permissions
Given using <dav-path-version> DAV path
And user "Alice" has uploaded file with content "foo" to "/tmp.txt"
And user "Alice" has shared file "tmp.txt" with user "Brian"
When user "Alice" updates the last share using the sharing API with
| permissions | share,read |
| permissions | read |
Then the HTTP status code should be "200"
And as user "Brian" file "/Shares/tmp.txt" should contain a property "ocs:share-permissions" with value "17"
And as user "Brian" file "/Shares/tmp.txt" should contain a property "ocs:share-permissions" with value "1"
Examples:
| dav-path-version |
| old |
@@ -122,15 +122,15 @@ Feature: sharing
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file with content "foo" to "/tmp.txt"
And user "Alice" has created a share with settings
| path | /tmp.txt |
| shareType | group |
| permissions | share,read |
| shareWith | grp1 |
| path | /tmp.txt |
| shareType | group |
| permissions | read |
| shareWith | grp1 |
When user "Brian" gets the following properties of file "/Shares/tmp.txt" using the WebDAV API
| propertyName |
| ocs:share-permissions |
Then the HTTP status code should be "207"
And the single response should contain a property "ocs:share-permissions" with value "17"
And the single response should contain a property "ocs:share-permissions" with value "1"
Examples:
| dav-path-version |
| old |
@@ -164,7 +164,7 @@ Feature: sharing
| propertyName |
| ocs:share-permissions |
Then the HTTP status code should be "207"
And the single response should contain a property "ocs:share-permissions" with value "31"
And the single response should contain a property "ocs:share-permissions" with value "15"
Examples:
| dav-path-version |
| old |
@@ -184,7 +184,7 @@ Feature: sharing
| propertyName |
| ocs:share-permissions |
Then the HTTP status code should be "207"
And the single response should contain a property "ocs:share-permissions" with value "31"
And the single response should contain a property "ocs:share-permissions" with value "15"
Examples:
| dav-path-version |
| old |
@@ -196,9 +196,9 @@ Feature: sharing
And user "Alice" has created folder "/tmp"
And user "Alice" has shared file "/tmp" with user "Brian"
When user "Alice" updates the last share using the sharing API with
| permissions | share,delete,create,read |
| permissions | delete,create,read |
Then the HTTP status code should be "200"
And as user "Brian" folder "/Shares/tmp" should contain a property "ocs:share-permissions" with value "29"
And as user "Brian" folder "/Shares/tmp" should contain a property "ocs:share-permissions" with value "13"
Examples:
| dav-path-version |
| old |
@@ -211,15 +211,15 @@ Feature: sharing
And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "/tmp"
And user "Alice" has created a share with settings
| path | tmp |
| shareType | group |
| shareWith | grp1 |
| permissions | share,delete,create,read |
| path | tmp |
| shareType | group |
| shareWith | grp1 |
| permissions | delete,create,read |
When user "Brian" gets the following properties of folder "/Shares/tmp" using the WebDAV API
| propertyName |
| ocs:share-permissions |
Then the HTTP status code should be "207"
And the single response should contain a property "ocs:share-permissions" with value "29"
And the single response should contain a property "ocs:share-permissions" with value "13"
Examples:
| dav-path-version |
| old |
@@ -231,9 +231,9 @@ Feature: sharing
And user "Alice" has created folder "/tmp"
And user "Alice" has shared file "/tmp" with user "Brian"
When user "Alice" updates the last share using the sharing API with
| permissions | share,delete,update,read |
| permissions | delete,update,read |
Then the HTTP status code should be "200"
And as user "Brian" folder "/Shares/tmp" should contain a property "ocs:share-permissions" with value "27"
And as user "Brian" folder "/Shares/tmp" should contain a property "ocs:share-permissions" with value "11"
Examples:
| dav-path-version |
| old |
@@ -246,15 +246,15 @@ Feature: sharing
And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "/tmp"
And user "Alice" has created a share with settings
| path | tmp |
| shareType | group |
| shareWith | grp1 |
| permissions | share,delete,update,read |
| path | tmp |
| shareType | group |
| shareWith | grp1 |
| permissions | delete,update,read |
When user "Brian" gets the following properties of folder "/Shares/tmp" using the WebDAV API
| propertyName |
| ocs:share-permissions |
Then the HTTP status code should be "207"
And the single response should contain a property "ocs:share-permissions" with value "27"
And the single response should contain a property "ocs:share-permissions" with value "11"
Examples:
| dav-path-version |
| old |
@@ -266,9 +266,9 @@ Feature: sharing
And user "Alice" has created folder "/tmp"
And user "Alice" has shared file "/tmp" with user "Brian"
When user "Alice" updates the last share using the sharing API with
| permissions | share,create,update,read |
| permissions | create,update,read |
Then the HTTP status code should be "200"
And as user "Brian" folder "/Shares/tmp" should contain a property "ocs:share-permissions" with value "23"
And as user "Brian" folder "/Shares/tmp" should contain a property "ocs:share-permissions" with value "7"
Examples:
| dav-path-version |
| old |
@@ -281,15 +281,15 @@ Feature: sharing
And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "/tmp"
And user "Alice" has created a share with settings
| path | tmp |
| shareType | group |
| shareWith | grp1 |
| permissions | share,create,update,read |
| path | tmp |
| shareType | group |
| shareWith | grp1 |
| permissions | create,update,read |
When user "Brian" gets the following properties of folder "/Shares/tmp" using the WebDAV API
| propertyName |
| ocs:share-permissions |
Then the HTTP status code should be "207"
And the single response should contain a property "ocs:share-permissions" with value "23"
And the single response should contain a property "ocs:share-permissions" with value "7"
Examples:
| dav-path-version |
| old |
tests/acceptance/features/coreApiShareOperationsToShares2/shareAccessByID.feature
+1 -1
View File
@@ -23,7 +23,7 @@ Feature: share access by ID
| share_with_displayname | %displayname% |
| file_target | /Shares/textfile0.txt |
| path | /textfile0.txt |
| permissions | share,read,update |
| permissions | read,update |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| item_type | file |
tests/acceptance/features/coreApiSharePublicLink2/reShareAsPublicLinkToSharesNewDav.feature
-184
View File
@@ -1,184 +0,0 @@
Feature: reshare as public link
As a user
I want to create public link shares from files/folders shared with me
So that I can give controlled access to others
Background:
Given these users have been created with default attributes and without skeleton files:
| username |
| Alice |
| Brian |
@skipOnReva
Scenario Outline: creating a public link from a share with read permission only is not allowed
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/test"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "read"
When user "Brian" creates a public link share using the sharing API with settings
| path | /Shares/test |
| publicUpload | false |
| password | %public% |
Then the OCS status code should be "403"
And the HTTP status code should be "<http-status-code>"
Examples:
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
@skipOnReva
Scenario Outline: creating a public link from a share with share+read only permissions is allowed
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/test"
And user "Alice" has uploaded file with content "some content" to "/test/file.txt"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read"
When user "Brian" creates a public link share using the sharing API with settings
| path | /Shares/test |
| publicUpload | false |
| password | %public% |
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
When the public downloads file "file.txt" from inside the last public link shared folder with password "%public%" using the new public WebDAV API
Then the HTTP status code should be "200"
And the downloaded content should be "some content"
But uploading a file should not work using the new public WebDAV API
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@skipOnReva
Scenario Outline: creating an upload public link from a share with share+read only permissions is not allowed
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/test"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read"
When user "Brian" creates a public link share using the sharing API with settings
| path | /Shares/test |
| permissions | read,update,create,delete |
| publicUpload | true |
| password | %public% |
Then the OCS status code should be "403"
And the HTTP status code should be "<http-status-code>"
Examples:
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
@skipOnReva
Scenario Outline: creating a public link from a share with read+write permissions only is not allowed
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/test"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "change"
When user "Brian" creates a public link share using the sharing API with settings
| path | /Shares/test |
| publicUpload | true |
| password | %public% |
Then the OCS status code should be "403"
And the HTTP status code should be "<http-status-code>"
Examples:
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
@skipOnReva
Scenario Outline: creating a public link from a share with share+read+write permissions is allowed
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/test"
And user "Alice" has uploaded file with content "some content" to "/test/file.txt"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "all"
When user "Brian" creates a public link share using the sharing API with settings
| path | /Shares/test |
| publicUpload | false |
| password | %public% |
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
When the public downloads file "file.txt" from inside the last public link shared folder with password "%public%" using the new public WebDAV API
Then the HTTP status code should be "200"
And the downloaded content should be "some content"
But uploading a file should not work using the new public WebDAV API
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@skipOnReva
Scenario Outline: creating an upload public link from a share with share+read+write permissions is allowed
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/test"
And user "Alice" has uploaded file with content "some content" to "/test/file.txt"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "all"
When user "Brian" creates a public link share using the sharing API with settings
| path | /Shares/test |
| permissions | read,update,create,delete |
| publicUpload | true |
| password | %public% |
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
When the public downloads file "file.txt" from inside the last public link shared folder with password "%public%" using the new public WebDAV API
Then the HTTP status code should be "200"
And the downloaded content should be "some content"
And uploading a file with password "%public%" should work using the new public WebDAV API
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@skipOnReva
Scenario Outline: creating an upload public link from a sub-folder of a share with share+read only permissions is not allowed
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/test"
And user "Alice" has created folder "/test/sub"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read"
When user "Brian" creates a public link share using the sharing API with settings
| path | /Shares/test/sub |
| permissions | read,update,create,delete |
| publicUpload | true |
| password | %public% |
Then the OCS status code should be "403"
And the HTTP status code should be "<http-status-code>"
Examples:
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
@skipOnReva
Scenario Outline: increasing permissions of a public link of a share with share+read only permissions is not allowed
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/test"
And user "Alice" has created folder "/test/sub"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read"
And user "Brian" has created a public link share with settings
| path | /Shares/test |
| permissions | read |
| publicUpload | false |
| password | %public% |
When user "Brian" updates the last public link share using the sharing API with
| permissions | read,update,create,delete |
Then the OCS status code should be "403"
And the HTTP status code should be "<http-status-code>"
And uploading a file should not work using the new public WebDAV API
Examples:
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
@skipOnReva
Scenario Outline: increasing permissions of a public link from a sub-folder of a share with share+read only permissions is not allowed
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/test"
And user "Alice" has created folder "/test/sub"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read"
And user "Brian" has created a public link share with settings
| path | /Shares/test/sub |
| permissions | read |
| publicUpload | false |
| password | %public% |
And uploading a file should not work using the new public WebDAV API
When user "Brian" updates the last public link share using the sharing API with
| permissions | read,update,create,delete |
Then the OCS status code should be "403"
And the HTTP status code should be "<http-status-code>"
And uploading a file should not work using the new public WebDAV API
Examples:
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
tests/acceptance/features/coreApiSharePublicLink2/updatePublicLinkShare.feature
-83
View File
@@ -232,89 +232,6 @@ Feature: update a public link share
| 1 | 100 |
| 2 | 200 |
@skipOnReva
Scenario Outline: adding public upload to a read only shared folder as recipient is not allowed using the public API
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "/test"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read"
And user "Brian" has created a public link share with settings
| path | /Shares/test |
| publicUpload | false |
| password | %public% |
When user "Brian" updates the last public link share using the sharing API with
| publicUpload | true |
Then the OCS status code should be "403"
And the HTTP status code should be "<http-status-code>"
And uploading a file should not work using the old public WebDAV API
And uploading a file should not work using the new public WebDAV API
Examples:
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
@skipOnReva
Scenario Outline:adding public upload to a shared folder as recipient is allowed with permissions using the public API
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "/test"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "all"
And user "Brian" has created a public link share with settings
| path | /Shares/test |
| publicUpload | false |
| password | %public% |
When user "Brian" updates the last public link share using the sharing API with
| publicUpload | true |
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And uploading a file with password "%public%" should work using the old public WebDAV API
And uploading a file with password "%public%" should work using the new public WebDAV API
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@skipOnReva
Scenario Outline: adding public link with all permissions to a read only shared folder as recipient is not allowed using the public API
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "/test"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "share,read"
And user "Brian" has created a public link share with settings
| path | /Shares/test |
| permissions | read |
| password | %public% |
When user "Brian" updates the last public link share using the sharing API with
| permissions | read,update,create,delete |
Then the OCS status code should be "403"
And the HTTP status code should be "<http-status-code>"
And uploading a file should not work using the old public WebDAV API
And uploading a file should not work using the new public WebDAV API
Examples:
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
@skipOnReva
Scenario Outline: adding public link with all permissions to a read only shared folder as recipient is allowed with permissions using the public API
Given using OCS API version "<ocs-api-version>"
And user "Brian" has been created with default attributes and without skeleton files
And user "Alice" has created folder "/test"
And user "Alice" has shared folder "/test" with user "Brian" with permissions "all"
And user "Brian" has created a public link share with settings
| path | /Shares/test |
| permissions | read |
| password | %public% |
When user "Brian" updates the last public link share using the sharing API with
| permissions | read,update,create,delete |
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And uploading a file with password "%public%" should work using the new public WebDAV API
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@issue-1269
Scenario Outline: updating share permissions from change to read restricts public from deleting files using the public API
Given using OCS API version "<ocs-api-version>"
tests/acceptance/features/coreApiShareReshareToShares1/reShare.feature
-283
View File
@@ -1,283 +0,0 @@
@issue-1328 @skipOnReva
Feature: sharing
As a user
I want to re-share a resource
So that other users can have access to it
Background:
Given these users have been created with default attributes and without skeleton files:
| username |
| Alice |
| Brian |
| Carol |
@smokeTest @skipOnRevaMaster
Scenario Outline: user is not allowed to reshare file when reshare permission is not given
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update"
When user "Brian" shares file "/Shares/textfile0.txt" with user "Carol" with permissions "read,update" using the sharing API
Then the OCS status code should be "403"
And the HTTP status code should be "<http-status-code>"
And as "Carol" file "/Shares/textfile0.txt" should not exist
And the sharing API should report to user "Carol" that no shares are in the pending state
But as "Brian" file "/Shares/textfile0.txt" should exist
Examples:
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
@skipOnRevaMaster
Scenario Outline: user is not allowed to reshare folder when reshare permission is not given
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "read,update"
When user "Brian" shares folder "/Shares/FOLDER" with user "Carol" with permissions "read,update" using the sharing API
Then the OCS status code should be "403"
And the HTTP status code should be "<http-status-code>"
And as "Carol" folder "/Shares/FOLDER" should not exist
And the sharing API should report to user "Carol" that no shares are in the pending state
But as "Brian" folder "/Shares/FOLDER" should exist
Examples:
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
@smokeTest
Scenario Outline: user is allowed to reshare file with the same permissions
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "share,read"
When user "Brian" shares file "/Shares/textfile0.txt" with user "Carol" with permissions "share,read" using the sharing API
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as "Carol" file "/Shares/textfile0.txt" should exist
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: user is allowed to reshare folder with the same permissions
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "share,read"
When user "Brian" shares folder "/Shares/FOLDER" with user "Carol" with permissions "share,read" using the sharing API
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as "Carol" folder "/Shares/FOLDER" should exist
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: user is allowed to reshare file with less permissions
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "share,update,read"
When user "Brian" shares file "/Shares/textfile0.txt" with user "Carol" with permissions "share,read" using the sharing API
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as "Carol" file "/Shares/textfile0.txt" should exist
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: user is allowed to reshare folder with less permissions
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "share,update,read"
When user "Brian" shares folder "/Shares/FOLDER" with user "Carol" with permissions "share,read" using the sharing API
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as "Carol" folder "/Shares/FOLDER" should exist
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@skipOnRevaMaster
Scenario Outline: user is not allowed to reshare file and set more permissions bits
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions 17
When user "Brian" shares file "/Shares/textfile0.txt" with user "Carol" with permissions <reshare-permissions> using the sharing API
Then the OCS status code should be "403"
And the HTTP status code should be "<http-status-code>"
And as "Carol" file "/Shares/textfile0.txt" should not exist
And the sharing API should report to user "Carol" that no shares are in the pending state
But as "Brian" file "/Shares/textfile0.txt" should exist
Examples:
| ocs-api-version | http-status-code | reshare-permissions |
# passing on more bits including reshare
| 1 | 200 | 19 |
| 2 | 403 | 19 |
| 1 | 200 | 23 |
| 2 | 403 | 23 |
| 1 | 200 | 31 |
| 2 | 403 | 31 |
# passing on more bits but not reshare
| 1 | 200 | 3 |
| 2 | 403 | 3 |
| 1 | 200 | 7 |
| 2 | 403 | 7 |
| 1 | 200 | 15 |
| 2 | 403 | 15 |
Scenario Outline: user is allowed to reshare file and set create (4) or delete (8) permissions bits, which get ignored
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions <received-permissions>
When user "Brian" shares file "/Shares/textfile0.txt" with user "Carol" with permissions <reshare-permissions> using the sharing API
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the fields of the last response to user "Brian" sharing with user "Carol" should include
| share_with | %username% |
| file_target | /Shares/textfile0.txt |
| path | /textfile0.txt |
| permissions | <granted-permissions> |
| uid_owner | %username% |
And as "Carol" file "/Shares/textfile0.txt" should exist
# The receiver of the reshare can always delete their received share, even though they do not have delete permission
And user "Carol" should be able to delete file "/Shares/textfile0.txt"
# But the upstream sharers will still have the file
But as "Brian" file "/Shares/textfile0.txt" should exist
And as "Alice" file "/textfile0.txt" should exist
Examples:
| ocs-api-version | ocs-status-code | received-permissions | reshare-permissions | granted-permissions |
| 1 | 100 | 19 | 23 | 19 |
| 2 | 200 | 19 | 23 | 19 |
| 1 | 100 | 19 | 31 | 19 |
| 2 | 200 | 19 | 31 | 19 |
| 1 | 100 | 19 | 7 | 3 |
| 2 | 200 | 19 | 7 | 3 |
| 1 | 100 | 19 | 15 | 3 |
| 2 | 200 | 19 | 15 | 3 |
| 1 | 100 | 17 | 21 | 17 |
| 2 | 200 | 17 | 21 | 17 |
| 1 | 100 | 17 | 5 | 1 |
| 2 | 200 | 17 | 5 | 1 |
| 1 | 100 | 17 | 25 | 17 |
| 2 | 200 | 17 | 25 | 17 |
| 1 | 100 | 17 | 9 | 1 |
| 2 | 200 | 17 | 9 | 1 |
@skipOnRevaMaster
Scenario Outline: user is not allowed to reshare folder and set more permissions bits
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/PARENT"
And user "Alice" has shared folder "/PARENT" with user "Brian" with permissions <received-permissions>
When user "Brian" shares folder "/Shares/PARENT" with user "Carol" with permissions <reshare-permissions> using the sharing API
Then the OCS status code should be "403"
And the HTTP status code should be "<http-status-code>"
And as "Carol" folder "/Shares/PARENT" should not exist
And the sharing API should report to user "Carol" that no shares are in the pending state
But as "Brian" folder "/Shares/PARENT" should exist
Examples:
| ocs-api-version | http-status-code | received-permissions | reshare-permissions |
# try to pass on more bits including reshare
| 1 | 200 | 17 | 19 |
| 2 | 403 | 17 | 19 |
| 1 | 200 | 17 | 21 |
| 2 | 403 | 17 | 21 |
| 1 | 200 | 17 | 23 |
| 2 | 403 | 17 | 23 |
| 1 | 200 | 17 | 31 |
| 2 | 403 | 17 | 31 |
| 1 | 200 | 19 | 23 |
| 2 | 403 | 19 | 23 |
| 1 | 200 | 19 | 31 |
| 2 | 403 | 19 | 31 |
# try to pass on more bits but not reshare
| 1 | 200 | 17 | 3 |
| 2 | 403 | 17 | 3 |
| 1 | 200 | 17 | 5 |
| 2 | 403 | 17 | 5 |
| 1 | 200 | 17 | 7 |
| 2 | 403 | 17 | 7 |
| 1 | 200 | 17 | 15 |
| 2 | 403 | 17 | 15 |
| 1 | 200 | 19 | 7 |
| 2 | 403 | 19 | 7 |
| 1 | 200 | 19 | 15 |
| 2 | 403 | 19 | 15 |
@skipOnRevaMaster
Scenario Outline: user is not allowed to reshare folder and add delete permission bit (8)
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/PARENT"
And user "Alice" has shared folder "/PARENT" with user "Brian" with permissions <received-permissions>
When user "Brian" shares folder "/Shares/PARENT" with user "Carol" with permissions <reshare-permissions> using the sharing API
Then the OCS status code should be "403"
And the HTTP status code should be "<http-status-code>"
And as "Carol" folder "/Shares/PARENT" should not exist
And the sharing API should report to user "Carol" that no shares are in the pending state
But as "Brian" folder "/Shares/PARENT" should exist
Examples:
| ocs-api-version | http-status-code | received-permissions | reshare-permissions |
# try to pass on extra delete (including reshare)
| 1 | 200 | 17 | 25 |
| 2 | 403 | 17 | 25 |
| 1 | 200 | 19 | 27 |
| 2 | 403 | 19 | 27 |
| 1 | 200 | 23 | 31 |
| 2 | 403 | 23 | 31 |
# try to pass on extra delete (but not reshare)
| 1 | 200 | 17 | 9 |
| 2 | 403 | 17 | 9 |
| 1 | 200 | 19 | 11 |
| 2 | 403 | 19 | 11 |
| 1 | 200 | 23 | 15 |
| 2 | 403 | 23 | 15 |
Scenario Outline: reshare a file with same name as a deleted file
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
And user "Alice" has deleted file "textfile0.txt"
And user "Alice" has uploaded file with content "ownCloud new test text file 0" to "/textfile0.txt"
When user "Alice" shares file "textfile0.txt" with user "Brian" using the sharing API
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And the content of file "/Shares/textfile0.txt" for user "Brian" should be "ownCloud new test text file 0"
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: reshare a folder with same name as a deleted folder
Given using OCS API version "<ocs-api-version>"
And user "Alice" has created folder "/PARENT"
And user "Alice" has shared folder "PARENT" with user "Brian"
And user "Alice" has deleted folder "PARENT"
And user "Alice" has created folder "/PARENT"
When user "Alice" shares folder "PARENT" with user "Brian" using the sharing API
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as "Brian" folder "/Shares/PARENT" should exist
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: reshare a folder with same name as a deleted file
Given using OCS API version "<ocs-api-version>"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
And user "Alice" has deleted file "/textfile0.txt"
And user "Alice" has created folder "/textfile0.txt"
When user "Alice" shares folder "textfile0.txt" with user "Brian" using the sharing API
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as "Brian" folder "/Shares/textfile0.txt" should exist
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
tests/acceptance/features/coreApiShareReshareToShares1/reShareChain.feature
-22
View File
@@ -1,22 +0,0 @@
@issue-2141 @skipOnReva
Feature: resharing can be done on a reshared resource
As a user
I want to re-share a resource
So that other users can have access to it
Scenario: reshared files can be still accessed if a user in the middle removes it
Given these users have been created with default attributes and without skeleton files:
| username |
| Alice |
| Brian |
| Carol |
| David |
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with user "Brian"
And user "Brian" has shared file "/Shares/textfile0.txt" with user "Carol"
And user "Carol" has shared file "/Shares/textfile0.txt" with user "David"
When user "Brian" deletes file "/Shares/textfile0.txt" using the WebDAV API
Then the HTTP status code should be "204"
And the content of file "/Shares/textfile0.txt" for user "Carol" should be "ownCloud test text file 0"
And the content of file "/Shares/textfile0.txt" for user "David" should be "ownCloud test text file 0"
tests/acceptance/features/coreApiShareReshareToShares1/reShareDisabled.feature
-22
View File
@@ -1,22 +0,0 @@
@issue-1328 @skipOnReva
Feature: resharing can be disabled
As a user
I want to share a resource without reshare permission
So that the resource won't be accessible to unwanted individuals
Scenario Outline: ordinary sharing is allowed when allow resharing has been disabled
Given these users have been created with default attributes and without skeleton files:
| username |
| Alice |
| Brian |
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And using OCS API version "<ocs-api-version>"
When user "Alice" shares file "/textfile0.txt" with user "Brian" with permissions "share,update,read" using the sharing API
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as "Brian" file "/Shares/textfile0.txt" should exist
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
tests/acceptance/features/coreApiShareReshareToShares2/reShareSubfolder.feature
-135
View File
@@ -1,135 +0,0 @@
@issue-1328 @skipOnReva
Feature: a subfolder of a received share can be reshared
As a user
I want to re-share a resource
So that other users can have access to it
Background:
Given these users have been created with default attributes and without skeleton files:
| username |
| Alice |
| Brian |
| Carol |
And user "Alice" has created folder "/TMP"
And user "Alice" has created folder "/TMP/SUB"
@smokeTest @issue-2214
Scenario Outline: user is allowed to reshare a sub-folder with the same permissions
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,read"
When user "Brian" shares folder "/Shares/TMP/SUB" with user "Carol" with permissions "share,read" using the sharing API
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as "Carol" folder "/Shares/SUB" should exist
And as "Brian" folder "/Shares/TMP/SUB" should exist
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@skipOnRevaMaster
Scenario Outline: user is not allowed to reshare a sub-folder with more permissions
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions <received-permissions>
When user "Brian" shares folder "/Shares/TMP/SUB" with user "Carol" with permissions <reshare-permissions> using the sharing API
Then the OCS status code should be "403"
And the HTTP status code should be "<http-status-code>"
And as "Carol" folder "/Shares/SUB" should not exist
And the sharing API should report to user "Carol" that no shares are in the pending state
And as "Brian" folder "/Shares/TMP/SUB" should exist
Examples:
| ocs-api-version | http-status-code | received-permissions | reshare-permissions |
# try to pass on more bits including reshare
| 1 | 200 | 17 | 19 |
| 2 | 403 | 17 | 19 |
| 1 | 200 | 17 | 21 |
| 2 | 403 | 17 | 21 |
| 1 | 200 | 17 | 23 |
| 2 | 403 | 17 | 23 |
| 1 | 200 | 17 | 31 |
| 2 | 403 | 17 | 31 |
| 1 | 200 | 19 | 23 |
| 2 | 403 | 19 | 23 |
| 1 | 200 | 19 | 31 |
| 2 | 403 | 19 | 31 |
# try to pass on more bits but not reshare
| 1 | 200 | 17 | 3 |
| 2 | 403 | 17 | 3 |
| 1 | 200 | 17 | 5 |
| 2 | 403 | 17 | 5 |
| 1 | 200 | 17 | 7 |
| 2 | 403 | 17 | 7 |
| 1 | 200 | 17 | 15 |
| 2 | 403 | 17 | 15 |
| 1 | 200 | 19 | 7 |
| 2 | 403 | 19 | 7 |
| 1 | 200 | 19 | 15 |
| 2 | 403 | 19 | 15 |
# try to pass on extra delete (including reshare)
| 1 | 200 | 17 | 25 |
| 2 | 403 | 17 | 25 |
| 1 | 200 | 19 | 27 |
| 2 | 403 | 19 | 27 |
| 1 | 200 | 23 | 31 |
| 2 | 403 | 23 | 31 |
# try to pass on extra delete (but not reshare)
| 1 | 200 | 17 | 9 |
| 2 | 403 | 17 | 9 |
| 1 | 200 | 19 | 11 |
| 2 | 403 | 19 | 11 |
| 1 | 200 | 23 | 15 |
| 2 | 403 | 23 | 15 |
@issue-2214
Scenario Outline: user is allowed to update reshare of a sub-folder with less permissions
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
And user "Brian" has shared folder "/Shares/TMP/SUB" with user "Carol" with permissions "share,create,update,read"
When user "Brian" updates the last share using the sharing API with
| permissions | share,read |
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as "Carol" folder "/Shares/SUB" should exist
But user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "/Shares/SUB/textfile.txt"
And as "Brian" folder "/Shares/TMP/SUB" should exist
And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "/Shares/TMP/SUB/textfile.txt"
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@issue-2214
Scenario Outline: user is allowed to update reshare of a sub-folder to the maximum allowed permissions
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
And user "Brian" has shared folder "/Shares/TMP/SUB" with user "Carol" with permissions "share,read"
When user "Brian" updates the last share using the sharing API with
| permissions | share,create,update,read |
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And as "Carol" folder "/Shares/SUB" should exist
And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "/Shares/SUB/textfile.txt"
And as "Brian" folder "/Shares/TMP/SUB" should exist
And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "/Shares/TMP/SUB/textfile.txt"
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@issue-2214 @skipOnRevaMaster
Scenario Outline: user is not allowed to update reshare of a sub-folder with more permissions
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,read"
And user "Brian" has shared folder "/Shares/TMP/SUB" with user "Carol" with permissions "share,read"
When user "Brian" updates the last share using the sharing API with
| permissions | all |
Then the OCS status code should be "403"
And the HTTP status code should be "<http-status-code>"
And as "Carol" folder "/Shares/SUB" should exist
But user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "/Shares/SUB/textfile.txt"
And as "Brian" folder "/Shares/TMP/SUB" should exist
But user "Brian" should not be able to upload file "filesForUpload/textfile.txt" to "/Shares/TMP/SUB/textfile.txt"
Examples:
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
tests/acceptance/features/coreApiShareReshareToShares2/reShareUpdate.feature
-138
View File
@@ -1,138 +0,0 @@
@issue-1328 @skipOnReva
Feature: sharing
As a user
I want to update share permissions
So that I can decide what resources can be shared with which permission
Background:
Given these users have been created with default attributes and without skeleton files:
| username |
| Alice |
| Brian |
| Carol |
And user "Alice" has created folder "/TMP"
Scenario Outline: update of reshare can reduce permissions
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,create,update,read"
When user "Brian" updates the last share using the sharing API with
| permissions | share,read |
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt"
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: update of reshare can increase permissions to the maximum allowed
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,read"
When user "Brian" updates the last share using the sharing API with
| permissions | share,create,update,read |
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt"
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@skipOnRevaMaster
Scenario Outline: do not allow update of reshare to exceed permissions
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,read"
And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,read"
When user "Brian" updates the last share using the sharing API with
| permissions | all |
Then the OCS status code should be "403"
And the HTTP status code should be "<http-status-code>"
And user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt"
Examples:
| ocs-api-version | http-status-code |
| 1 | 200 |
| 2 | 403 |
Scenario Outline: update of user reshare by the original share owner can increase permissions up to the permissions of the top-level share
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,read"
When user "Alice" updates the last share using the sharing API with
| permissions | share,create,update,read |
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt"
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: update of user reshare by the original share owner can increase permissions to more than the permissions of the top-level share
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,update,read"
And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,read"
When user "Alice" updates the last share using the sharing API with
| permissions | share,create,update,read |
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt"
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: update of group reshare by the original share owner can increase permissions up to permissions of the top-level share
Given using OCS API version "<ocs-api-version>"
And group "grp1" has been created
And user "Carol" has been added to group "grp1"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
And user "Brian" has shared folder "Shares/TMP" with group "grp1" with permissions "share,read"
When user "Alice" updates the last share using the sharing API with
| permissions | share,create,update,read |
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt"
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: update of group reshare by the original share owner can increase permissions to more than the permissions of the top-level share
Given using OCS API version "<ocs-api-version>"
And group "grp1" has been created
And user "Carol" has been added to group "grp1"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,update,read"
And user "Brian" has shared folder "Shares/TMP" with group "grp1" with permissions "share,read"
When user "Alice" updates the last share using the sharing API with
| permissions | share,create,update,read |
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And user "Carol" should be able to upload file "filesForUpload/textfile.txt" to "Shares/TMP/textfile.txt"
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: after losing share permissions user can still delete a previously reshared share
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"
And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,create,update,read"
And user "Alice" has updated the last share of "Alice" with
| permissions | create,update,read |
When user "Brian" deletes the last share using the sharing API
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And user "Carol" should not have any received shares
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
tests/acceptance/features/coreApiShareReshareToShares2/reShareWithExpiryDate.feature
-77
View File
@@ -1,77 +0,0 @@
@issue-1328 @skipOnReva
Feature: resharing a resource with an expiration date
As a user
I want to reshare resources with expiration date
So that other users will have access to the resources only for a limited amount of time
Background:
Given these users have been created with default attributes and without skeleton files:
| username |
| Alice |
| Brian |
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And user "Carol" has been created with default attributes and without skeleton files
Scenario Outline: user should be able to set expiration while resharing a file with user
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share"
When user "Brian" creates a share using the sharing API with settings
| path | /Shares/textfile0.txt |
| shareType | user |
| permissions | change |
| shareWith | Carol |
| expireDate | +3 days |
Then the HTTP status code should be "200"
And the OCS status code should be "<ocs-status-code>"
And the information of the last share of user "Brian" should include
| expiration | +3 days |
And the response when user "Carol" gets the info of the last share should include
| expiration | +3 days |
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@issue-1289
Scenario Outline: user should be able to set expiration while resharing a file with group
Given using OCS API version "<ocs-api-version>"
And group "grp1" has been created
And user "Carol" has been added to group "grp1"
And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share"
When user "Brian" creates a share using the sharing API with settings
| path | /Shares/textfile0.txt |
| shareType | group |
| permissions | change |
| shareWith | grp1 |
| expireDate | +3 days |
Then the HTTP status code should be "200"
And the OCS status code should be "<ocs-status-code>"
And the information of the last share of user "Brian" should include
| expiration | +3 days |
And the response when user "Carol" gets the info of the last share should include
| expiration | +3 days |
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: resharing using the sharing API with default expire date set but not enforced
Given using OCS API version "<ocs-api-version>"
And user "Alice" has shared file "/textfile0.txt" with user "Brian" with permissions "read,update,share"
When user "Brian" creates a share using the sharing API with settings
| path | /Shares/textfile0.txt |
| shareType | user |
| permissions | change |
| shareWith | Carol |
Then the HTTP status code should be "200"
And the OCS status code should be "<ocs-status-code>"
And the information of the last share of user "Brian" should include
| expiration | |
And the response when user "Carol" gets the info of the last share should include
| expiration | |
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
tests/acceptance/features/coreApiShareUpdateToShares/updateShare.feature
+1 -67
View File
@@ -8,26 +8,6 @@ Feature: sharing
Given using OCS API version "1"
And user "Alice" has been created with default attributes and without skeleton files
@smokeTest
Scenario Outline: allow modification of reshare
Given using OCS API version "<ocs-api-version>"
And these users have been created with default attributes and without skeleton files:
| username |
| Brian |
| Carol |
And user "Alice" has created folder "/TMP"
And user "Alice" has shared folder "TMP" with user "Brian"
And user "Brian" has shared folder "/Shares/TMP" with user "Carol"
When user "Brian" updates the last share using the sharing API with
| permissions | read |
Then the OCS status code should be "<ocs-status-code>"
And the HTTP status code should be "200"
And user "Carol" should not be able to upload file "filesForUpload/textfile.txt" to "/Shares/TMP/textfile.txt"
And user "Brian" should be able to upload file "filesForUpload/textfile.txt" to "/Shares/TMP/textfile.txt"
Examples:
| ocs-api-version | ocs-status-code |
| 1 | 100 |
| 2 | 200 |
@issue-1289 @issue-7555
Scenario Outline: keep group permissions in sync when the share is renamed by the receiver and then the permissions are updated by sharer
@@ -120,36 +100,6 @@ Feature: sharing
| 1 | 200 | create,delete |
| 2 | 400 | create,delete |
@issue-2201
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 |
| Brian |
| Carol |
And user "Alice" has created folder "/folder1"
And user "Alice" has created folder "/folder1/folder2"
And user "Brian" has created folder "/moved-out"
And user "Alice" has shared folder "/folder1" with user "Brian" with permissions "all"
And user "Brian" has shared folder "/Shares/folder1/folder2" with user "Carol" with permissions "all"
When user "Brian" moves folder "/Shares/folder1/folder2" to "/moved-out/folder2" using the WebDAV API
Then the HTTP status code should be "201"
And the response when user "Brian" gets the info of the last share should include
| id | A_STRING |
| item_type | folder |
| item_source | A_STRING |
| share_type | user |
| file_source | A_STRING |
| file_target | /Shares/folder2 |
| permissions | all |
| stime | A_NUMBER |
| storage | A_STRING |
| mail_send | 0 |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| mimetype | httpd/unix-directory |
And as "Alice" folder "/Shares/folder1/folder2" should not exist
And as "Carol" folder "/Shares/folder2" should exist
@issue-2442
Scenario: share ownership change after moving a shared file to another share
Given these users have been created with default attributes and without skeleton files:
@@ -162,23 +112,7 @@ Feature: sharing
And user "Alice" has shared folder "/Alice-folder" with user "Brian" with permissions "all"
And user "Carol" has shared folder "/Carol-folder" with user "Brian" with permissions "all"
When user "Brian" moves folder "/Shares/Alice-folder/folder2" to "/Shares/Carol-folder/folder2" using the WebDAV API
Then the HTTP status code should be "201"
And the response when user "Carol" gets the info of the last share should include
| id | A_STRING |
| item_type | folder |
| item_source | A_STRING |
| share_type | user |
| file_source | A_STRING |
| file_target | /Carol-folder |
| permissions | all |
| stime | A_NUMBER |
| storage | A_STRING |
| mail_send | 0 |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| mimetype | httpd/unix-directory |
And as "Alice" folder "/Alice-folder/folder2" should not exist
And as "Carol" folder "/Carol-folder/folder2" should exist
Then the HTTP status code should be "502"
@issue-1253 @issue-1224 @issue-1225
#after fixing all the issues merge this scenario with the one below