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

copy feature files from core

Browse Source
This commit is contained in:
Saw-jan
2023-01-05 09:22:52 +05:45
committed by Phil Davis
parent 35d4cb53ae
commit c59392bc1e
336 changed files with 52903 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tests/acceptance/features/coreApiShareCreateSpecialToShares1/createShareExpirationDate.feature
+757
View File
@@ -0,0 +1,757 @@
@api @files_sharing-app-required @issue-ocis-1328 @issue-ocis-1250
Feature: a default expiration date can be specified for shares with users or groups
Background:
Given the administrator has set the default folder for received shares to "Shares"
And auto-accept shares has been disabled
And these users have been created with default attributes and without skeleton files:
| username |
| Alice |
| Brian |
Scenario Outline: sharing with default expiration date enabled but not enforced for users, user shares without specifying expireDate
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes"
And user "Alice" has created folder "/FOLDER"
When user "Alice" shares folder "/FOLDER" with user "Brian" using the sharing API
And user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API
Then the OCS status code of responses on all endpoints should be "<ocs_status_code>"
And the HTTP status code of responses on all endpoints should be "<http_status_code>"
And the fields of the last response to user "Alice" should include
| expiration | |
And the response when user "Brian" gets the info of the last share should include
| expiration | |
Examples:
| ocs_api_version | ocs_status_code | http_status_code |
| 1 | 100 | 200 |
| 2 | 200 | 200 |
Scenario Outline: sharing with default expiration date enabled but not enforced for users, user shares with expiration date
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes"
And user "Alice" has created folder "/FOLDER"
And user "Alice" has created a share with settings
| path | /FOLDER |
| shareType | user |
| shareWith | Brian |
| permissions | read,share |
| expireDate | +15 days |
When user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API
Then the info about the last share by user "Alice" with user "Brian" should include
| share_type | user |
| file_target | /Shares/FOLDER |
| uid_owner | %username% |
| expiration | +15 days |
| share_with | %username% |
And the response when user "Brian" gets the info of the last share should include
| expiration | +15 days |
Examples:
| ocs_api_version |
| 1 |
| 2 |
Scenario Outline: sharing with default expiration date not enabled, user shares with expiration date set
Given using OCS API version "<ocs_api_version>"
And user "Alice" has created folder "/FOLDER"
And user "Alice" has created a share with settings
| path | /FOLDER |
| shareType | user |
| shareWith | Brian |
| permissions | read,share |
| expireDate | +15 days |
When user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API
Then the info about the last share by user "Alice" with user "Brian" should include
| share_type | user |
| file_target | /Shares/FOLDER |
| uid_owner | %username% |
| expiration | +15 days |
| share_with | %username% |
And the response when user "Brian" gets the info of the last share should include
| expiration | +15 days |
Examples:
| ocs_api_version |
| 1 |
| 2 |
Scenario Outline: sharing with default expiration date enabled but not enforced for users, user shares with expiration date and then disables
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes"
And user "Alice" has created folder "/FOLDER"
And user "Alice" has created a share with settings
| path | /FOLDER |
| shareType | user |
| shareWith | Brian |
| permissions | read,share |
| expireDate | +15 days |
And user "Brian" has accepted share "/FOLDER" offered by user "Alice"
When the administrator sets parameter "shareapi_default_expire_date_user_share" of app "core" to "no"
Then the info about the last share by user "Alice" with user "Brian" should include
| share_type | user |
| file_target | /Shares/FOLDER |
| uid_owner | %username% |
| expiration | +15 days |
| share_with | %username% |
And the response when user "Brian" gets the info of the last share should include
| expiration | +15 days |
Examples:
| ocs_api_version |
| 1 |
| 2 |
Scenario Outline: sharing with default expiration date enabled and enforced for users, user shares with expiration date and then disables
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes"
And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes"
And user "Alice" has created folder "/FOLDER"
And user "Alice" has created a share with settings
| path | /FOLDER |
| shareType | user |
| shareWith | Brian |
| permissions | read,share |
And user "Brian" has accepted share "/FOLDER" offered by user "Alice"
When the administrator sets parameter "shareapi_default_expire_date_user_share" of app "core" to "no"
Then the info about the last share by user "Alice" with user "Brian" should include
| share_type | user |
| file_target | /Shares/FOLDER |
| uid_owner | %username% |
| share_with | %username% |
| expiration | +7 days |
And the response when user "Brian" gets the info of the last share should include
| expiration | +7 days |
Examples:
| ocs_api_version |
| 1 |
| 2 |
Scenario Outline: sharing with default expiration date enabled but not enforced for groups, user shares without specifying expireDate
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes"
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "/FOLDER"
And user "Alice" has shared folder "/FOLDER" with group "grp1"
When user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API
Then the OCS status code should be "<ocs_status_code>"
And the HTTP status code should be "<http_status_code>"
And the fields of the last response to user "Alice" should include
| expiration | |
And the response when user "Brian" gets the info of the last share should include
| expiration | |
Examples:
| ocs_api_version | ocs_status_code | http_status_code |
| 1 | 100 | 200 |
| 2 | 200 | 200 |
Scenario Outline: sharing with default expiration date enabled but not enforced for groups, user shares with expiration date
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes"
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "/FOLDER"
And user "Alice" has created a share with settings
| path | /FOLDER |
| shareType | group |
| shareWith | grp1 |
| permissions | read,share |
| expireDate | +15 days |
When user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API
Then the info about the last share by user "Alice" with user "Brian" should include
| share_type | group |
| file_target | /Shares/FOLDER |
| uid_owner | %username% |
| expiration | +15 days |
| share_with | grp1 |
And the response when user "Brian" gets the info of the last share should include
| expiration | +15 days |
Examples:
| ocs_api_version |
| 1 |
| 2 |
Scenario Outline: sharing with default expiration date not enabled for groups, user shares with expiration date set
Given using OCS API version "<ocs_api_version>"
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "/FOLDER"
And user "Alice" has created a share with settings
| path | /FOLDER |
| shareType | group |
| shareWith | grp1 |
| permissions | read,share |
| expireDate | +15 days |
When user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API
Then the info about the last share by user "Alice" with user "Brian" should include
| share_type | group |
| file_target | /Shares/FOLDER |
| uid_owner | %username% |
| expiration | +15 days |
| share_with | grp1 |
And the response when user "Brian" gets the info of the last share should include
| expiration | +15 days |
Examples:
| ocs_api_version |
| 1 |
| 2 |
Scenario Outline: sharing with default expiration date enabled but not enforced for groups, user shares with expiration date and then disables
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes"
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "/FOLDER"
And user "Alice" has created a share with settings
| path | /FOLDER |
| shareType | group |
| shareWith | grp1 |
| permissions | read,share |
| expireDate | +15 days |
And user "Brian" has accepted share "/FOLDER" offered by user "Alice"
When the administrator sets parameter "shareapi_default_expire_date_group_share" of app "core" to "no"
Then the info about the last share by user "Alice" with user "Brian" should include
| share_type | group |
| file_target | /Shares/FOLDER |
| uid_owner | %username% |
| share_with | grp1 |
| expiration | +15 days |
And the response when user "Brian" gets the info of the last share should include
| expiration | +15 days |
Examples:
| ocs_api_version |
| 1 |
| 2 |
Scenario Outline: sharing with default expiration date enabled and enforced for groups, user shares with expiration date and then disables
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes"
And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes"
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "/FOLDER"
And user "Alice" has created a share with settings
| path | /FOLDER |
| shareType | group |
| shareWith | grp1 |
| permissions | read,share |
| expireDate | +3 days |
And user "Brian" has accepted share "/FOLDER" offered by user "Alice"
When the administrator sets parameter "shareapi_default_expire_date_group_share" of app "core" to "no"
Then the info about the last share by user "Alice" with user "Brian" should include
| share_type | group |
| file_target | /Shares/FOLDER |
| uid_owner | %username% |
| share_with | grp1 |
| expiration | +3 days |
And the response when user "Brian" gets the info of the last share should include
| expiration | +3 days |
Examples:
| ocs_api_version |
| 1 |
| 2 |
Scenario Outline: sharing with default expiration date enabled and enforced for users, user shares without setting expiration date
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes"
And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And user "Alice" has shared file "/textfile0.txt" with user "Brian"
When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API
Then the info about the last share by user "Alice" with user "Brian" should include
| share_type | user |
| file_target | /Shares/textfile0.txt |
| uid_owner | %username% |
| share_with | %username% |
| expiration | +7 days |
And the response when user "Brian" gets the info of the last share should include
| expiration | +7 days |
Examples:
| ocs_api_version |
| 1 |
| 2 |
Scenario Outline: sharing with default expiration date enabled and enforced for users, user shares with expiration date more than the default
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes"
And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
When user "Alice" creates a share using the sharing API with settings
| path | textfile0.txt |
| shareType | user |
| shareWith | Brian |
| permissions | read,share |
| expireDate | +10 days |
Then the HTTP status code should be "<http_status_code>"
And the OCS status code should be "404"
And the OCS status message should be "Cannot set expiration date more than 7 days in the future"
And the sharing API should report to user "Brian" that no shares are in the pending state
And user "Brian" should not have any received shares
Examples:
| ocs_api_version | http_status_code |
| 1 | 200 |
| 2 | 404 |
Scenario Outline: sharing with default expiration date enabled and enforced for users/max expire date is set, user shares without setting expiration date
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes"
And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes"
And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And user "Alice" has shared file "/textfile0.txt" with user "Brian"
When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API
Then the info about the last share by user "Alice" with user "Brian" should include
| share_type | user |
| file_target | /Shares/textfile0.txt |
| uid_owner | %username% |
| share_with | %username% |
| expiration | +30 days |
And the response when user "Brian" gets the info of the last share should include
| expiration | +30 days |
Examples:
| ocs_api_version |
| 1 |
| 2 |
Scenario Outline: sharing with default expiration date enabled and enforced for users/max expire date set, user shares with expiration date more than the max expire date
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes"
And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes"
And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
When user "Alice" creates a share using the sharing API with settings
| path | textfile0.txt |
| shareType | user |
| shareWith | Brian |
| permissions | read,share |
| expireDate | +40 days |
Then the HTTP status code should be "<http_status_code>"
And the OCS status code should be "404"
And the OCS status message should be "Cannot set expiration date more than 30 days in the future"
And the sharing API should report to user "Brian" that no shares are in the pending state
And user "Brian" should not have any received shares
Examples:
| ocs_api_version | http_status_code |
| 1 | 200 |
| 2 | 404 |
Scenario Outline: sharing with default expiration date enabled and enforced for users/max expire date is set, user shares and changes the max expire date greater than the previous one
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes"
And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes"
And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30"
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,share"
And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
When the administrator sets parameter "shareapi_expire_after_n_days_user_share" of app "core" to "40"
Then the info about the last share by user "Alice" with user "Brian" should include
| expiration | +30 days |
Examples:
| ocs_api_version |
| 1 |
| 2 |
Scenario Outline: sharing with default expiration date enabled for users/max expire date is set, user shares and changes max expire date less than the previous one
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes"
And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes"
And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30"
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,share"
And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
When the administrator sets parameter "shareapi_expire_after_n_days_user_share" of app "core" to "15"
Then the info about the last share by user "Alice" with user "Brian" should include
| expiration | +30 days |
Examples:
| ocs_api_version |
| 1 |
| 2 |
Scenario Outline: sharing with default expiration date enabled and enforced for groups, user shares without setting expiration date
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes"
And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes"
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with group "grp1"
When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API
Then the info about the last share by user "Alice" with user "Brian" should include
| share_type | group |
| file_target | /Shares/textfile0.txt |
| uid_owner | %username% |
| share_with | grp1 |
| expiration | +7 days |
And the response when user "Brian" gets the info of the last share should include
| expiration | +7 days |
Examples:
| ocs_api_version |
| 1 |
| 2 |
Scenario Outline: sharing with default expiration date enabled and enforced for groups, user shares with expiration date more than the default
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes"
And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes"
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
When user "Alice" creates a share using the sharing API with settings
| path | textfile0.txt |
| shareType | group |
| shareWith | grp1 |
| permissions | read,share |
| expireDate | +10 days |
Then the HTTP status code should be "<http_status_code>"
And the OCS status code should be "404"
And the OCS status message should be "Cannot set expiration date more than 7 days in the future"
And the sharing API should report to user "Brian" that no shares are in the pending state
And user "Brian" should not have any received shares
Examples:
| ocs_api_version | http_status_code |
| 1 | 200 |
| 2 | 404 |
Scenario Outline: sharing with default expiration date enabled and enforced for groups/max expire date is set, user shares without setting expiration date
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes"
And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes"
And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30"
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with group "grp1"
When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API
Then the info about the last share by user "Alice" with user "Brian" should include
| share_type | group |
| file_target | /Shares/textfile0.txt |
| uid_owner | %username% |
| share_with | grp1 |
| expiration | +30 days |
And the response when user "Brian" gets the info of the last share should include
| expiration | +30 days |
Examples:
| ocs_api_version |
| 1 |
| 2 |
Scenario Outline: sharing with default expiration date enabled and enforced for groups/max expire date set, user shares with expiration date more than the max expire date
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes"
And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes"
And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30"
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
When user "Alice" creates a share using the sharing API with settings
| path | textfile0.txt |
| shareType | group |
| shareWith | grp1 |
| permissions | read,share |
| expireDate | +40 days |
Then the HTTP status code should be "<http_status_code>"
And the OCS status code should be "404"
And the OCS status message should be "Cannot set expiration date more than 30 days in the future"
And the sharing API should report to user "Brian" that no shares are in the pending state
And user "Brian" should not have any received shares
Examples:
| ocs_api_version | http_status_code |
| 1 | 200 |
| 2 | 404 |
Scenario Outline: sharing with default expiration date enabled for groups/max expire date is set, user shares and changes the max expire date greater than the previous one
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes"
And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes"
And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30"
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with group "grp1" with permissions "read,share"
And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
When the administrator sets parameter "shareapi_expire_after_n_days_group_share" of app "core" to "40"
Then the info about the last share by user "Alice" with user "Brian" should include
| expiration | +30 days |
And the response when user "Brian" gets the info of the last share should include
| expiration | +30 days |
Examples:
| ocs_api_version |
| 1 |
| 2 |
Scenario Outline: sharing with default expiration date enabled for groups/max expire date is set, user shares and changes max expire date less than the previous one
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes"
And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes"
And parameter "shareapi_expire_after_n_days_group_share" of app "core" has been set to "30"
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And user "Alice" has shared file "textfile0.txt" with group "grp1" with permissions "read,share"
And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
When the administrator sets parameter "shareapi_expire_after_n_days_group_share" of app "core" to "15"
Then the info about the last share by user "Alice" with user "Brian" should include
| expiration | +30 days |
And the response when user "Brian" gets the info of the last share should include
| expiration | +30 days |
Examples:
| ocs_api_version |
| 1 |
| 2 |
Scenario Outline: sharing with default expiration date enforced for users, user shares to a group without setting an expiration date
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes"
And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes"
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has created folder "FOLDER"
And user "Alice" has shared folder "FOLDER" with group "grp1" with permissions "read,share"
When user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API
Then the info about the last share by user "Alice" with user "Brian" should include
| expiration | |
And the response when user "Brian" gets the info of the last share should include
| expiration | |
Examples:
| ocs_api_version |
| 1 |
| 2 |
Scenario Outline: sharing with default expiration date enforced for groups, user shares to another user
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_group_share" of app "core" has been set to "yes"
And parameter "shareapi_enforce_expire_date_group_share" of app "core" has been set to "yes"
And user "Alice" has created folder "FOLDER"
And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "read,share"
When user "Brian" accepts share "/FOLDER" offered by user "Alice" using the sharing API
Then the info about the last share by user "Alice" with user "Brian" should include
| expiration | |
And the response when user "Brian" gets the info of the last share should include
| expiration | |
Examples:
| ocs_api_version |
| 1 |
| 2 |
Scenario Outline: sharing with default expiration date enforced for users, user shares with invalid expiration date set
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes"
And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
When user "Alice" creates a share using the sharing API with settings
| path | textfile0.txt |
| shareType | user |
| shareWith | Brian |
| permissions | read,share |
| expireDateAsString | INVALID-DATE |
Then the HTTP status code should be "<http_status_code>"
And the OCS status code should be "<ocs_status_code>"
And the OCS status message should be "Invalid date, date format must be YYYY-MM-DD"
And the sharing API should report to user "Brian" that no shares are in the pending state
And user "Brian" should not have any received shares
Examples:
| ocs_api_version | ocs_status_code | http_status_code |
| 1 | 404 | 200 |
| 2 | 404 | 404 |
Scenario Outline: sharing with default expiration date enforced for users, user shares with different time format
Given using OCS API version "2"
And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And user "Alice" has created a share with settings
| path | textfile0.txt |
| shareType | user |
| shareWith | Brian |
| permissions | read,share |
| expireDateAsString | <date> |
When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API
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" should include
| expiration | 2050-12-11 |
And the response when user "Brian" gets the info of the last share should include
| expiration | 2050-12-11 |
Examples:
| date |
| 2050-12-11 |
| 11-12-2050 |
| 12/11/2050 |
| 11.12.2050 |
| 11.12.2050 12:30:40 |
Scenario Outline: user shares with humanized expiration date format
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "<default>"
And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "<enforce>"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And user "Alice" has created a share with settings
| path | textfile0.txt |
| shareType | user |
| shareWith | Brian |
| permissions | read,share |
| expireDateAsString | <expiration_date> |
When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API
Then the fields of the last response to user "Alice" should include
| expiration | <expiration_date> |
And the response when user "Brian" gets the info of the last share should include
| expiration | <expiration_date> |
Examples:
| ocs_api_version | expiration_date | default | enforce |
| 1 | today | yes | yes |
| 2 | today | yes | yes |
| 1 | tomorrow | yes | yes |
| 2 | tomorrow | yes | yes |
| 1 | today | yes | no |
| 2 | today | yes | no |
| 1 | tomorrow | yes | no |
| 2 | tomorrow | yes | no |
| 1 | today | no | no |
| 2 | today | no | no |
| 1 | tomorrow | no | no |
| 2 | tomorrow | no | no |
Scenario Outline: user shares with humanized expiration date format in past
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "<default>"
And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "<enforce>"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
When user "Alice" creates a share using the sharing API with settings
| path | textfile0.txt |
| shareType | user |
| shareWith | Brian |
| permissions | read,share |
| expireDateAsString | yesterday |
Then the HTTP status code should be "<http_status_code>"
And the OCS status code should be "<ocs_status_code>"
And the OCS status message should be "Expiration date is in the past"
And the sharing API should report to user "Brian" that no shares are in the pending state
And user "Brian" should not have any received shares
Examples:
| ocs_api_version | ocs_status_code | http_status_code | default | enforce |
| 1 | 404 | 200 | yes | yes |
| 2 | 404 | 404 | yes | yes |
| 1 | 404 | 200 | yes | no |
| 2 | 404 | 404 | yes | no |
| 1 | 404 | 200 | no | no |
| 2 | 404 | 404 | no | no |
Scenario Outline: user shares with invalid humanized expiration date
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "<default>"
And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "<enforce>"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
When user "Alice" creates a share using the sharing API with settings
| path | textfile0.txt |
| shareType | user |
| shareWith | Brian |
| permissions | read,share |
| expireDateAsString | 123 |
Then the HTTP status code should be "<http_status_code>"
And the OCS status code should be "<ocs_status_code>"
And the OCS status message should be "Invalid date, date format must be YYYY-MM-DD"
And the sharing API should report to user "Brian" that no shares are in the pending state
And user "Brian" should not have any received shares
Examples:
| ocs_api_version | ocs_status_code | http_status_code | default | enforce |
| 1 | 404 | 200 | yes | yes |
| 2 | 404 | 404 | yes | yes |
| 1 | 404 | 200 | yes | no |
| 2 | 404 | 404 | yes | no |
| 1 | 404 | 200 | no | no |
| 2 | 404 | 404 | no | no |
Scenario Outline: sharing with default expiration date enforced for users, user shares with past expiration date set
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes"
And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
When user "Alice" creates a share using the sharing API with settings
| path | textfile0.txt |
| shareType | user |
| shareWith | Brian |
| permissions | read,share |
| expireDateAsString | -10 days |
Then the HTTP status code should be "<http_status_code>"
And the OCS status code should be "<ocs_status_code>"
And the OCS status message should be "Expiration date is in the past"
And the sharing API should report to user "Brian" that no shares are in the pending state
And user "Brian" should not have any received shares
Examples:
| ocs_api_version | ocs_status_code | http_status_code |
| 1 | 404 | 200 |
| 2 | 404 | 404 |
@issue-36569
Scenario Outline: sharing with default expiration date enforced for users, max expire date is 0, user shares without specifying expiration date
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes"
And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes"
And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "0"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And user "Alice" has created a share with settings
| path | textfile0.txt |
| shareType | user |
| shareWith | Brian |
| permissions | read,share |
When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API
Then the HTTP status code should be "200"
And the OCS status code should be "<ocs_status_code>"
And the fields of the last response to user "Alice" should include
| expiration | today |
And the response when user "Brian" gets the info of the last share should include
| expiration | today |
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: sharing with default expiration date enforced for users, max expire date is 1, user shares without specifying expiration date
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes"
And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "yes"
And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "1"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
And user "Alice" has created a share with settings
| path | textfile0.txt |
| shareType | user |
| shareWith | Brian |
| permissions | read,share |
When user "Brian" accepts share "/textfile0.txt" offered by user "Alice" using the sharing API
Then the HTTP status code should be "200"
And the OCS status code should be "<ocs_status_code>"
And the fields of the last response to user "Alice" should include
| expiration | tomorrow |
And the response when user "Brian" gets the info of the last share should include
| expiration | tomorrow |
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
tests/acceptance/features/coreApiShareCreateSpecialToShares1/createShareResourceCaseSensitiveName.feature
+298
View File
@@ -0,0 +1,298 @@
@api @files_sharing-app-required
Feature: Sharing resources with different case names with the sharee and checking the coexistence of resources on sharee/receivers side
Background:
Given the administrator has set the default folder for received shares to "Shares"
And auto-accept shares has been disabled
And these users have been created with default attributes and without skeleton files:
| username |
| Alice |
| Brian |
Scenario: sharing files with different case names with an internal user
Given user "Alice" has uploaded the following files with content "some data"
| path |
| textfile.txt |
| text_file.txt |
| 123textfile.txt |
| textfile.XYZ.txt |
| TEXTFILE.txt |
| TEXT_FILE.txt |
| 123TEXTFILE.txt |
| TEXTFILE.xyz.txt |
When user "Alice" shares the following files with user "Brian" using the sharing API
| path |
| textfile.txt |
| text_file.txt |
| 123textfile.txt |
| textfile.XYZ.txt |
| TEXTFILE.txt |
| TEXT_FILE.txt |
| 123TEXTFILE.txt |
| TEXTFILE.xyz.txt |
And user "Brian" accepts the following shares offered by user "Alice" using the sharing API
| path |
| /textfile.txt |
| /text_file.txt |
| /123textfile.txt |
| /textfile.XYZ.txt |
| /TEXTFILE.txt |
| /TEXT_FILE.txt |
| /123TEXTFILE.txt |
| /TEXTFILE.xyz.txt |
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 "Brian" the following files should exist
| path |
| /Shares/textfile.txt |
| /Shares/text_file.txt |
| /Shares/123textfile.txt |
| /Shares/textfile.XYZ.txt |
| /Shares/TEXTFILE.txt |
| /Shares/TEXT_FILE.txt |
| /Shares/123TEXTFILE.txt |
| /Shares/TEXTFILE.xyz.txt |
Scenario: sharing folders with different case names with an internal user
Given user "Alice" has created the following folders
| path |
| /FO |
| /F_O |
| /123FO |
| /FO.XYZ |
| /fo |
| /f_o |
| /123fo |
| /fo.xyz |
When user "Alice" shares the following folders with user "Brian" using the sharing API
| path |
| /FO |
| /F_O |
| /123FO |
| /FO.XYZ |
| /fo |
| /f_o |
| /123fo |
| /fo.xyz |
And user "Brian" accepts the following shares offered by user "Alice" using the sharing API
| path |
| /FO |
| /F_O |
| /123FO |
| /FO.XYZ |
| /fo |
| /f_o |
| /123fo |
| /fo.xyz |
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 "Brian" the following folders should exist
| path |
| /Shares/FO |
| /Shares/F_O |
| /Shares/123FO |
| /Shares/FO.XYZ |
| /Shares/fo |
| /Shares/f_o |
| /Shares/123fo |
| /Shares/fo.xyz |
Scenario: sharing files and folders with different case names with an internal user
Given user "Alice" has uploaded the following files with content "some data"
| path |
| casesensitive.txt |
| case_sensitive.txt |
| 123CASE_SENSITIVE.txt |
| casesensitive.xyz.txt |
And user "Alice" has created the following folders
| path |
| /CASESENSITIVE |
| /CASE_SENSITIVE |
| /123case_sensitive |
| /CASESENSITIVE.xyz |
When user "Alice" shares the following files with user "Brian" using the sharing API
| path |
| casesensitive.txt |
| case_sensitive.txt |
| 123CASE_SENSITIVE.txt |
| casesensitive.xyz.txt |
And user "Alice" shares the following folders with user "Brian" using the sharing API
| path |
| /CASESENSITIVE |
| /CASE_SENSITIVE |
| /123case_sensitive |
| /CASESENSITIVE.xyz |
And user "Brian" accepts the following shares offered by user "Alice" using the sharing API
| path |
| /casesensitive.txt |
| /case_sensitive.txt |
| /123CASE_SENSITIVE.txt |
| /casesensitive.xyz.txt |
| /CASESENSITIVE |
| /CASE_SENSITIVE |
| /123case_sensitive |
| /CASESENSITIVE.xyz |
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 "Brian" the following files should exist
| path |
| /Shares/casesensitive.txt |
| /Shares/case_sensitive.txt |
| /Shares/123CASE_SENSITIVE.txt |
| /Shares/casesensitive.xyz.txt |
And as "Brian" the following folders should exist
| path |
| /Shares/CASESENSITIVE |
| /Shares/CASE_SENSITIVE |
| /Shares/123case_sensitive |
| /Shares/CASESENSITIVE.xyz |
Scenario: sharing files with different case names with group members
Given group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded the following files with content "some data"
| path |
| textfile.txt |
| text_file.txt |
| 123textfile.txt |
| textfile.XYZ.txt |
| TEXTFILE.txt |
| TEXT_FILE.txt |
| 123TEXTFILE.txt |
| TEXTFILE.xyz.txt |
When user "Alice" shares the following files with group "grp1" using the sharing API
| path |
| textfile.txt |
| text_file.txt |
| 123textfile.txt |
| textfile.XYZ.txt |
| TEXTFILE.txt |
| TEXT_FILE.txt |
| 123TEXTFILE.txt |
| TEXTFILE.xyz.txt |
And user "Brian" accepts the following shares offered by user "Alice" using the sharing API
| path |
| /textfile.txt |
| /text_file.txt |
| /123textfile.txt |
| /textfile.XYZ.txt |
| /TEXTFILE.txt |
| /TEXT_FILE.txt |
| /123TEXTFILE.txt |
| /TEXTFILE.xyz.txt |
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 "Brian" the following files should exist
| path |
| /Shares/textfile.txt |
| /Shares/text_file.txt |
| /Shares/123textfile.txt |
| /Shares/textfile.XYZ.txt |
| /Shares/TEXTFILE.txt |
| /Shares/TEXT_FILE.txt |
| /Shares/123TEXTFILE.txt |
| /Shares/TEXTFILE.xyz.txt |
Scenario: sharing folders with different case names with group members
Given group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has created the following folders
| path |
| /FO |
| /F_O |
| /123FO |
| /FO.XYZ |
| /fo |
| /f_o |
| /123fo |
| /fo.xyz |
When user "Alice" shares the following folders with group "grp1" using the sharing API
| path |
| /FO |
| /F_O |
| /123FO |
| /FO.XYZ |
| /fo |
| /f_o |
| /123fo |
| /fo.xyz |
And user "Brian" accepts the following shares offered by user "Alice" using the sharing API
| path |
| /FO |
| /F_O |
| /123FO |
| /FO.XYZ |
| /fo |
| /f_o |
| /123fo |
| /fo.xyz |
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 "Brian" the following folders should exist
| path |
| /Shares/FO |
| /Shares/F_O |
| /Shares/123FO |
| /Shares/FO.XYZ |
| /Shares/fo |
| /Shares/f_o |
| /Shares/123fo |
| /Shares/fo.xyz |
Scenario: sharing files and folders with different case names with group members
Given group "grp1" has been created
And user "Brian" has been added to group "grp1"
And user "Alice" has uploaded the following files with content "some data"
| path |
| casesensitive.txt |
| case_sensitive.txt |
| 123CASE_SENSITIVE.txt |
| casesensitive.xyz.txt |
And user "Alice" has created the following folders
| path |
| /CASESENSITIVE |
| /CASE_SENSITIVE |
| /123case_sensitive |
| /CASESENSITIVE.xyz |
When user "Alice" shares the following files with group "grp1" using the sharing API
| path |
| casesensitive.txt |
| case_sensitive.txt |
| 123CASE_SENSITIVE.txt |
| casesensitive.xyz.txt |
And user "Alice" shares the following folders with group "grp1" using the sharing API
| path |
| /CASESENSITIVE |
| /CASE_SENSITIVE |
| /123case_sensitive |
| /CASESENSITIVE.xyz |
And user "Brian" accepts the following shares offered by user "Alice" using the sharing API
| path |
| /casesensitive.txt |
| /case_sensitive.txt |
| /123CASE_SENSITIVE.txt |
| /casesensitive.xyz.txt |
| /CASESENSITIVE |
| /CASE_SENSITIVE |
| /123case_sensitive |
| /CASESENSITIVE.xyz |
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 "Brian" the following files should exist
| path |
| /Shares/casesensitive.txt |
| /Shares/case_sensitive.txt |
| /Shares/123CASE_SENSITIVE.txt |
| /Shares/casesensitive.xyz.txt |
And as "Brian" the following folders should exist
| path |
| /Shares/CASESENSITIVE |
| /Shares/CASE_SENSITIVE |
| /Shares/123case_sensitive |
| /Shares/CASESENSITIVE.xyz |
tests/acceptance/features/coreApiShareCreateSpecialToShares1/createShareUniqueReceivedNames.feature
+34
View File
@@ -0,0 +1,34 @@
@api @files_sharing-app-required
Feature: resources shared with the same name are received with unique names
Background:
Given the administrator has set the default folder for received shares to "Shares"
And auto-accept shares has been disabled
And using OCS API version "1"
And these users have been created with default attributes and without skeleton files:
| username |
| Alice |
| Brian |
| Carol |
@smokeTest @issue-ocis-2131
Scenario Outline: unique target names for incoming shares
Given user "Alice" has created folder "/foo"
And user "Brian" has created folder "/foo"
When user "Alice" shares folder "/foo" with user "Carol" using the sharing API
And user "Carol" accepts share "/foo" offered by user "Alice" using the sharing API
And user "Brian" shares folder "/foo" with user "Carol" using the sharing API
And user "Carol" accepts share "/foo" offered by user "Brian" 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 user "Carol" should see the following elements
| Shares/foo/ |
| <share> |
@skipOnOcis
Examples:
| share |
| /Shares/foo (2)/ |
@skipOnOcV10
Examples:
| share |
| /Shares/foo (1)/ |
tests/acceptance/features/coreApiShareCreateSpecialToShares1/createShareWhenExcludedFromSharing.feature
+83
View File
@@ -0,0 +1,83 @@
@api @files_sharing-app-required @issue-ocis-reva-41 @skipOnOcis
Feature: cannot share resources when in a group that is excluded from sharing
Background:
Given the administrator has set the default folder for received shares to "Shares"
And auto-accept shares has been disabled
And user "Alice" has been created with default attributes and without skeleton files
And user "Brian" has been created with default attributes and without skeleton files
And group "grp1" has been created
And user "Brian" has been added to group "grp1"
Scenario Outline: user who is excluded from sharing tries to share a file with another user
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_exclude_groups" of app "core" has been set to "yes"
And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["grp1"]'
And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/fileToShare.txt"
When user "Brian" shares file "fileToShare.txt" with user "Alice" using the sharing API
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the sharing API should report to user "Alice" that no shares are in the pending state
And as "Alice" file "Shares/fileToShare.txt" should not exist
And as "Alice" file "fileToShare.txt" should not exist
Examples:
| ocs_api_version | http_status_code |
| 1 | 200 |
| 2 | 403 |
Scenario Outline: user who is excluded from sharing tries to share a file with a group
Given using OCS API version "<ocs_api_version>"
And user "Carol" has been created with default attributes and without skeleton files
And group "grp2" has been created
And user "Carol" has been added to group "grp2"
And parameter "shareapi_exclude_groups" of app "core" has been set to "yes"
And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["grp1"]'
And user "Brian" has uploaded file "filesForUpload/textfile.txt" to "/fileToShare.txt"
When user "Brian" shares file "fileToShare.txt" with group "grp2" using the sharing API
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the sharing API should report to user "Carol" that no shares are in the pending state
And as "Carol" file "Shares/fileToShare.txt" should not exist
And as "Carol" file "fileToShare.txt" should not exist
Examples:
| ocs_api_version | http_status_code |
| 1 | 200 |
| 2 | 403 |
Scenario Outline: user who is excluded from sharing tries to share a folder with another user
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_exclude_groups" of app "core" has been set to "yes"
And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["grp1"]'
And user "Brian" has created folder "folderToShare"
When user "Brian" shares folder "folderToShare" with user "Alice" using the sharing API
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the sharing API should report to user "Alice" that no shares are in the pending state
And as "Alice" folder "Shares/folderToShare" should not exist
And as "Alice" folder "folderToShare" should not exist
Examples:
| ocs_api_version | http_status_code |
| 1 | 200 |
| 2 | 403 |
Scenario Outline: user who is excluded from sharing tries to share a folder with a group
Given using OCS API version "<ocs_api_version>"
And group "grp0" has been created
And user "Alice" has been added to group "grp0"
And parameter "shareapi_exclude_groups" of app "core" has been set to "yes"
And parameter "shareapi_exclude_groups_list" of app "core" has been set to '["grp0"]'
And user "Alice" has created folder "folderToShare"
When user "Alice" shares folder "folderToShare" with group "grp1" using the sharing API
Then the OCS status code should be "403"
And the HTTP status code should be "<http_status_code>"
And the sharing API should report to user "Brian" that no shares are in the pending state
And as "Brian" folder "Shares/folderToShare" should not exist
And as "Brian" folder "folderToShare" should not exist
Examples:
| ocs_api_version | http_status_code |
| 1 | 200 |
| 2 | 403 |