mirror/opencloud
1
0
Fork 0
mirror of https://github.com/opencloud-eu/opencloud.git synced 2026-01-27 15:32:15 -05:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #5489 from owncloud/remove-core-bug-demonstration-scenarios-master

Browse Source 
[full-ci] [tests-only] Removed core bug demonstration scenarios
This commit is contained in:
Prarup Gurung
2023-02-01 17:12:05 +05:45
committed by GitHub
parent 486453b4c9 3f2e1ce516
commit 7acaed39d3
27 changed files with 25 additions and 763 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedInMultipleWays.feature
View File

@@ -536,7 +536,7 @@ Feature: share resources where the sharee receives the share in multiple ways
| path |
| /child1 |
@skipOnOcV10 @issue-39347
Scenario Outline: Share receiver renames the received group share and shares same folder through user share again
Given using OCS API version "<ocs_api_version>"
And group "grp" has been created
@@ -567,7 +567,7 @@ Feature: share resources where the sharee receives the share in multiple ways
| 1 | 100 |
| 2 | 200 |
@skipOnOcV10 @issue-39347
Scenario Outline: Share receiver renames a group share and receives same resource through user share with additional permissions
Given using OCS API version "<ocs_api_version>"
And group "grp" has been created
@@ -596,7 +596,7 @@ Feature: share resources where the sharee receives the share in multiple ways
| 1 |
| 2 |
@skipOnOcV10 @issue-39347
Scenario Outline: Share receiver renames a group share and receives same resource through user share with less permissions
Given using OCS API version "<ocs_api_version>"
And group "grp" has been created

130
tests/acceptance/features/coreApiShareCreateSpecialToShares2/createShareReceivedMultipleWaysIssue39347.feature
View File

@@ -1,130 +0,0 @@
@api @files_sharing-app-required @notToImplementOnOCIS
Feature: share resources where the sharee receives the share in multiple ways
# These are the bug demonstration scenarios for https://github.com/owncloud/core/issues/39347
# Once the issue is fixed, delete this file and unskip all the respective tests tagged with @issue-39347
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: Share receiver renames the received group share and shares same folder through user share again
Given using OCS API version "<ocs_api_version>"
And group "grp" has been created
And user "Brian" has been added to group "grp"
And user "Alice" has been added to group "grp"
And user "Alice" has created folder "parent"
And user "Alice" has created folder "parent/child"
And user "Alice" has uploaded file with content "Share content" to "parent/child/lorem.txt"
And user "Alice" has created a share with settings
| path | parent |
| shareType | group |
| shareWith | grp |
| permissions | read |
When user "Brian" accepts share "/parent" 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 user "Brian" should be able to rename folder "/Shares/parent" to "/Shares/sharedParent"
And user "Alice" should be able to share folder "parent" with user "Brian" with permissions "read" using the sharing API
And user "Brian" should be able to accept pending share "/parent" offered by user "Alice"
And as "Brian" folder "Shares/parent" should exist
And as "Brian" folder "Shares/sharedParent" should not exist
And as "Brian" file "Shares/sharedParent/child/lorem.txt" should not exist
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
# Note: after fixing the bug, this scenario is no longer relevant.
# Brian should not get a chance to decline (or accept) the 2nd share of the resource from Alice
Scenario Outline: Share receiver renames the received group share and declines another share of same folder through user share again
Given using OCS API version "<ocs_api_version>"
And group "grp" has been created
And user "Brian" has been added to group "grp"
And user "Alice" has been added to group "grp"
And user "Alice" has created folder "parent"
And user "Alice" has created folder "parent/child"
And user "Alice" has uploaded file with content "Share content" to "parent/child/lorem.txt"
And user "Alice" has created a share with settings
| path | parent |
| shareType | group |
| shareWith | grp |
| permissions | read |
When user "Brian" accepts share "/parent" 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 user "Brian" should be able to rename folder "/Shares/parent" to "/Shares/sharedParent"
And user "Alice" should be able to share folder "parent" with user "Brian" with permissions "read" using the sharing API
And user "Brian" should be able to decline pending share "/parent" offered by user "Alice"
And as "Brian" folder "Shares/parent" should not exist
And as "Brian" folder "Shares/sharedParent" should not exist
And as "Brian" file "Shares/sharedParent/child/lorem.txt" should not exist
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: Share receiver renames a group share and receives same resource through user share with additional permissions
Given using OCS API version "<ocs_api_version>"
And group "grp" has been created
And user "Brian" has been added to group "grp"
And user "Alice" has been added to group "grp"
And user "Alice" has created folder "parent"
And user "Alice" has created folder "parent/child"
And user "Alice" has uploaded file with content "Share content" to "parent/child/lorem.txt"
And user "Alice" has created a share with settings
| path | parent |
| shareType | group |
| shareWith | grp |
| permissions | read |
When user "Brian" accepts share "/parent" 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 user "Brian" should be able to rename folder "/Shares/parent" to "/Shares/sharedParent"
And user "Alice" should be able to share folder "parent" with user "Brian" with permissions "all" using the sharing API
And user "Brian" should be able to accept pending share "/parent" offered by user "Alice"
And as "Brian" folder "Shares/parent" should exist
And as "Brian" folder "Shares/sharedParent" should not exist
And as "Brian" file "Shares/sharedParent/child/lorem.txt" should not exist
And as "Brian" file "Shares/parent/child/lorem.txt" should exist
And user "Brian" should be able to delete file "Shares/parent/child/lorem.txt"
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |
Scenario Outline: Share receiver renames a group share and receives same resource through user share with less permissions
Given using OCS API version "<ocs_api_version> "
And group "grp" has been created
And user "Brian" has been added to group "grp"
And user "Alice" has been added to group "grp"
And user "Alice" has created folder "parent"
And user "Alice" has created folder "parent/child"
And user "Alice" has uploaded file with content "Share content" to "parent/child/lorem.txt"
And user "Alice" has created a share with settings
| path | parent |
| shareType | group |
| shareWith | grp |
| permissions | all |
When user "Brian" accepts share "/parent" 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 user "Brian" should be able to rename folder "/Shares/parent" to "/Shares/sharedParent"
And user "Alice" should be able to share folder "parent" with user "Brian" with permissions "read" using the sharing API
And user "Brian" should be able to accept pending share "/parent" offered by user "Alice"
And as "Brian" folder "Shares/parent" should exist
And as "Brian" folder "Shares/sharedParent" should not exist
And as "Brian" file "Shares/sharedParent/child/lorem.txt" should not exist
And as "Brian" file "Shares/parent/child/lorem.txt" should exist
And user "Brian" should be able to delete file "Shares/parent/child/lorem.txt"
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |

4
tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShare.feature
View File

@@ -587,7 +587,7 @@ Feature: create a public link share
| old |
| new |
@issue-37605 @skipOnOcV10
Scenario: Get the mtime of a file inside a folder shared by public link using new webDAV version
Given user "Alice" has created folder "testFolder"
And user "Alice" has created a public link share with settings
@@ -599,7 +599,7 @@ Feature: create a public link share
And as "Alice" the mtime of the file "testFolder/file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT"
And the mtime of file "file.txt" in the last shared public link using the WebDAV API should be "Thu, 08 Aug 2019 04:18:13 GMT"
@issue-37605 @skipOnOcV10
Scenario: overwriting a file changes its mtime (new public webDAV API)
Given user "Alice" has created folder "testFolder"
When user "Alice" uploads file with content "uploaded content for file name ending with a dot" to "testFolder/file.txt" using the WebDAV API

31
tests/acceptance/features/coreApiSharePublicLink1/createPublicLinkShareOc10Issue37605.feature
View File

@@ -1,31 +0,0 @@
@api @files_sharing-app-required @public_link_share-feature-required @notToImplementOnOCIS
Feature: create a public link share
Background:
Given user "Alice" has been created with default attributes and without skeleton files
And user "Alice" has created folder "testFolder"
And user "Alice" has created a public link share with settings
| path | /testFolder |
| permissions | read,update,create,delete |
@issue-37605
Scenario: Get the mtime of a file inside a folder shared by public link using new webDAV version
When the public uploads file "file.txt" to the last public link shared folder with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the new public WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "testFolder/file.txt" should exist
And as "Alice" the mtime of the file "testFolder/file.txt" should not be "Thu, 08 Aug 2019 04:18:13 GMT"
# And as "Alice" the mtime of the file "testFolder/file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT"
And the mtime of file "file.txt" in the last shared public link using the WebDAV API should not be "Thu, 08 Aug 2019 04:18:13 GMT"
# And the mtime of file "file.txt" in the last shared public link using the WebDAV API should be "Thu, 08 Aug 2019 04:18:13 GMT"
@issue-37605
Scenario: overwriting a file changes its mtime (new public webDAV API)
Given user "Alice" has uploaded file with content "uploaded content for file name ending with a dot" to "testFolder/file.txt"
When the public uploads file "file.txt" to the last public link shared folder with mtime "Thu, 08 Aug 2019 04:18:13 GMT" using the new public WebDAV API
Then the HTTP status code should be "204"
And as "Alice" file "/testFolder/file.txt" should exist
And as "Alice" the mtime of the file "testFolder/file.txt" should not be "Thu, 08 Aug 2019 04:18:13 GMT"
# And as "Alice" the mtime of the file "testFolder/file.txt" should be "Thu, 08 Aug 2019 04:18:13 GMT"
And the mtime of file "file.txt" in the last shared public link using the WebDAV API should not be "Thu, 08 Aug 2019 04:18:13 GMT"
# And the mtime of file "file.txt" in the last shared public link using the WebDAV API should be "Thu, 08 Aug 2019 04:18:13 GMT"

4
tests/acceptance/features/coreApiSharePublicLink2/copyFromPublicLink.feature
View File

@@ -59,7 +59,7 @@ Feature: copying from public link share
And as "Alice" file "/PARENT/copy1.txt" should exist
And the content of file "/PARENT/copy1.txt" for user "Alice" should be "some data 0"
@skipOnOcV10 @issue-ocis-reva-373 @issue-37683
@issue-ocis-reva-373
Scenario: Copy folder within a public link folder to the same folder name as an already existing file
Given user "Alice" has created folder "/PARENT/testFolder"
And user "Alice" has uploaded file with content "some data" to "/PARENT/testFolder/testfile.txt"
@@ -85,7 +85,7 @@ Feature: copying from public link share
Then the HTTP status code should be "204"
And as "Alice" file "/PARENT/copy1.txt" should not exist
@skipOnOcV10 @issue-ocis-reva-373 @issue-37683
@issue-ocis-reva-373
Scenario: Copy file within a public link folder to a file with name same as an existing folder
Given user "Alice" has uploaded file with content "some data" to "/PARENT/testfile.txt"
And user "Alice" has created folder "/PARENT/new-folder"

37
tests/acceptance/features/coreApiSharePublicLink2/copyFromPublicLinkOc10Issue37683.feature
View File

@@ -1,37 +0,0 @@
@api @files_sharing-app-required @public_link_share-feature-required @issue-ocis-reva-310 @notToImplementOnOCIS
Feature: copying from public link share
Background:
Given user "Alice" has been created with default attributes and without skeleton files
And user "Alice" has created folder "/PARENT"
@issue-ocis-reva-373 @issue-37683 @skipOnLDAP @issue-user_ldap-702
Scenario: Copy folder within a public link folder to the same folder name as an already existing file
Given user "Alice" has created folder "/PARENT/testFolder"
And user "Alice" has uploaded file with content "some data" to "/PARENT/testFolder/testfile.txt"
And user "Alice" has uploaded file with content "some data 1" to "/PARENT/copy1.txt"
And user "Alice" has created a public link share with settings
| path | /PARENT |
| permissions | read,update,create,delete |
When the public copies folder "/testFolder" to "/copy1.txt" using the new public WebDAV API
Then the HTTP status code should be "204"
And as "Alice" folder "/PARENT/testFolder" should exist
And as "Alice" folder "/PARENT/copy1.txt" should exist
And as "Alice" file "/PARENT/copy1.txt/testfile.txt" should exist
And the content of file "/PARENT/copy1.txt/testfile.txt" for user "Alice" should be "some data"
And the content of file "/PARENT/testFolder/testfile.txt" for user "Alice" should be "some data"
@issue-ocis-reva-373 @issue-37683
Scenario: Copy file within a public link folder to a file with name same as an existing folder
Given user "Alice" has uploaded file with content "some data" to "/PARENT/testfile.txt"
And user "Alice" has created folder "/PARENT/new-folder"
And user "Alice" has uploaded file with content "some data 1" to "/PARENT/new-folder/testfile1.txt"
And user "Alice" has created a public link share with settings
| path | /PARENT |
| permissions | read,update,create,delete |
When the public copies file "/testfile.txt" to "/new-folder" using the new public WebDAV API
Then the HTTP status code should be "204"
And as "Alice" file "/PARENT/testfile.txt" should exist
And as "Alice" file "/PARENT/new-folder" should exist
And the content of file "/PARENT/testfile.txt" for user "Alice" should be "some data"
And the content of file "/PARENT/new-folder" for user "Alice" should be "some data"

89
tests/acceptance/features/coreApiSharePublicLink3/updatePublicLinkShare.feature
View File

@@ -5,7 +5,7 @@ Feature: update a public link share
Given using OCS API version "1"
And user "Alice" has been created with default attributes and without skeleton files
@issue-37653 @skipOnOcV10
Scenario Outline: API responds with a full set of parameters when owner changes the expireDate of a public share
Given using OCS API version "<ocs_api_version>"
And user "Alice" has created folder "FOLDER"
@@ -78,50 +78,6 @@ Feature: update a public link share
| 1 | 100 |
| 2 | 200 |
@notToImplementOnOCIS @issue-39820
Scenario Outline: API responds with a full set of parameters when owner renames the folder with a public link (bug demonstration)
Given using OCS API version "<ocs_api_version>"
And using <dav-path> DAV path
And user "Alice" has created folder "FOLDER"
And user "Alice" has created a public link share with settings
| path | FOLDER |
And user "Alice" has moved folder "/FOLDER" to "/RENAMED_FOLDER"
When user "Alice" gets the info of the last public link share 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 "Alice" should include
| id | A_STRING |
| share_type | public_link |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| permissions | read |
| stime | A_NUMBER |
| parent | |
| expiration | |
| token | A_STRING |
| uid_file_owner | %username% |
| displayname_file_owner | %displayname% |
| additional_info_owner | |
| additional_info_file_owner | |
| item_type | folder |
| item_source | A_STRING |
| path | /RENAMED_FOLDER |
| mimetype | httpd/unix-directory |
| storage_id | A_STRING |
| storage | A_STRING |
| file_source | A_STRING |
# uncomment the following line and remove the next one after the issue has been fixed
# | file_target | /RENAMED_FOLDER |
| file_target | /FOLDER |
| mail_send | 0 |
| name | |
Examples:
| dav-path | ocs_api_version | ocs_status_code |
| old | 1 | 100 |
| old | 2 | 200 |
| new | 1 | 100 |
| new | 2 | 200 |
Scenario Outline: Creating a new public link share with password and adding an expiration date using public API
Given using OCS API version "<ocs_api_version>"
@@ -521,49 +477,6 @@ Feature: update a public link share
| spaces | 1 | 100 |
| spaces | 2 | 200 |
@notToImplementOnOCIS @issue-39820
Scenario Outline: API responds with a full set of parameters when owner renames the file with a public link (bug demonstration)
Given using OCS API version "<ocs_api_version>"
And using <dav-path> DAV path
And user "Alice" has uploaded file with content "some content" to "/lorem.txt"
And user "Alice" has created a public link share with settings
| path | lorem.txt |
And user "Alice" has moved file "/lorem.txt" to "/new-lorem.txt"
When user "Alice" gets the info of the last public link share 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 "Alice" should include
| id | A_STRING |
| share_type | public_link |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| permissions | read |
| stime | A_NUMBER |
| parent | |
| expiration | |
| token | A_STRING |
| uid_file_owner | %username% |
| displayname_file_owner | %displayname% |
| additional_info_owner | |
| additional_info_file_owner | |
| item_type | file |
| item_source | A_STRING |
| path | /new-lorem.txt |
| mimetype | text/plain |
| storage_id | A_STRING |
| storage | A_STRING |
| file_source | A_STRING |
# uncomment the following line and remove the next one after the issue has been fixed
# | file_target | /new-lorem.txt |
| file_target | /lorem.txt |
| mail_send | 0 |
| name | |
Examples:
| dav-path | ocs_api_version | ocs_status_code |
| old | 1 | 100 |
| old | 2 | 200 |
| new | 1 | 100 |
| new | 2 | 200 |
@skipOnOcV10
Scenario Outline: API responds with a full set of parameters when owner renames the file with a public link in ocis

47
tests/acceptance/features/coreApiSharePublicLink3/updatePublicLinkShareOc10Issue37653.feature
View File

@@ -1,47 +0,0 @@
@api @files_sharing-app-required @public_link_share-feature-required @notToImplementOnOCIS
Feature: update a public link share
Background:
Given using OCS API version "1"
And user "Alice" has been created with default attributes and without skeleton files
@issue-37653
Scenario Outline: API responds with a full set of parameters when owner changes the expireDate of a public share
Given using OCS API version "<ocs_api_version>"
And user "Alice" has created folder "FOLDER"
And user "Alice" has created a public link share with settings
| path | FOLDER |
When user "Alice" updates the last public link share using the sharing API with
| expireDate | 2040-01-01T23:59:59+0100 |
Then the OCS status code should be "<ocs_status_code>"
And the OCS status message should be ""
#And the OCS status message should be "Ok"
And the HTTP status code should be "200"
And the fields of the last response to user "Alice" should include
| id | A_STRING |
| share_type | public_link |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| permissions | read |
| stime | A_NUMBER |
| parent | |
| expiration | A_STRING |
| token | A_STRING |
| uid_file_owner | %username% |
| displayname_file_owner | %displayname% |
| additional_info_owner | |
| additional_info_file_owner | |
| item_type | folder |
| item_source | A_STRING |
| path | /FOLDER |
| mimetype | httpd/unix-directory |
| storage_id | A_STRING |
| storage | A_NUMBER |
| file_source | A_STRING |
| file_target | /FOLDER |
| mail_send | 0 |
| name | |
Examples:
| ocs_api_version | ocs_status_code |
| 1 | 100 |
| 2 | 200 |

6
tests/acceptance/features/coreApiShareReshareToShares3/reShareWithExpiryDate.feature
View File

@@ -348,7 +348,7 @@ Feature: resharing a resource with an expiration date
| 1 | no | 100 |
| 2 | no | 200 |
@skipOnOcV10 @issue-37013
Scenario Outline: reshare extends the received expiry date up to the default by default
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "<default-expire-date>"
@@ -383,7 +383,7 @@ Feature: resharing a resource with an expiration date
| 1 | no | no | 100 |
| 2 | no | no | 200 |
@skipOnOcV10 @issue-37013
Scenario Outline: reshare cannot extend the received expiry date further into the future
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "<default-expire-date>"
@@ -415,7 +415,7 @@ Feature: resharing a resource with an expiration date
| 1 | no |
| 2 | no |
@skipOnOcV10 @issue-37013
Scenario Outline: reshare cannot extend the received expiry date past the default when the default is enforced
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "yes"

110
tests/acceptance/features/coreApiShareReshareToShares3/reShareWithExpiryDateOc10Issue37013.feature
View File

@@ -1,110 +0,0 @@
@api @files_sharing-app-required @issue-ocis-1250 @notToImplementOnOCIS
Feature: resharing a resource with an expiration date
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 |
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "/textfile0.txt"
@issue-37013
Scenario Outline: reshare extends the received expiry date up to the default by default
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "<default-expire-date>"
And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "<enforce-expire-date>"
And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30"
And user "Carol" has been created with default attributes and without skeleton files
And user "Alice" has created a share with settings
| path | textfile0.txt |
| shareType | user |
| permissions | all |
| shareWith | Brian |
| expireDate | +20 days |
And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
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 user "Carol" should be able to accept pending share "/textfile0.txt" offered by user "Brian"
And the information of the last share of user "Alice" should include
| expiration | +20 days |
And the response when user "Carol" gets the info of the last share should include
| expiration | <actual-expire-date> |
Examples:
| ocs_api_version | default-expire-date | enforce-expire-date | actual-expire-date | ocs_status_code |
| 1 | yes | yes | +30 days | 100 |
| 2 | yes | yes | +30 days | 200 |
| 1 | yes | no | | 100 |
| 2 | yes | no | | 200 |
| 1 | no | no | | 100 |
| 2 | no | no | | 200 |
@issue-37013
Scenario Outline: reshare can extend the received expiry date further into the future
Given using OCS API version "<ocs_api_version>"
And parameter "shareapi_default_expire_date_user_share" of app "core" has been set to "<default-expire-date>"
And parameter "shareapi_enforce_expire_date_user_share" of app "core" has been set to "no"
And parameter "shareapi_expire_after_n_days_user_share" of app "core" has been set to "30"
And user "Carol" has been created with default attributes and without skeleton files
And user "Alice" has created a share with settings
| path | textfile0.txt |
| shareType | user |
| permissions | all |
| shareWith | Brian |
| expireDate | +20 days |
And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
When user "Brian" creates a share using the sharing API with settings
| path | /Shares/textfile0.txt |
| shareType | user |
| permissions | change |
| shareWith | Carol |
| expireDate | +40 days |
Then the HTTP status code should be "200"
And the OCS status code should be "<ocs_status_code>"
And user "Carol" should be able to accept pending share "/textfile0.txt" offered by user "Brian"
And the information of the last share of user "Alice" should include
| expiration | +20 days |
And the response when user "Carol" gets the info of the last share should include
| expiration | +40 days |
Examples:
| ocs_api_version | default-expire-date | ocs_status_code |
| 1 | yes | 100 |
| 2 | yes | 200 |
| 1 | no | 100 |
| 2 | no | 200 |
@issue-37013
Scenario Outline: reshare cannot extend the received expiry date past the default when the default is enforced
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 "Carol" has been created with default attributes and without skeleton files
And user "Alice" has created a share with settings
| path | textfile0.txt |
| shareType | user |
| permissions | all |
| shareWith | Brian |
| expireDate | +20 days |
And user "Brian" has accepted share "/textfile0.txt" offered by user "Alice"
When user "Brian" creates a share using the sharing API with settings
| path | /Shares/textfile0.txt |
| shareType | user |
| permissions | change |
| shareWith | Carol |
| expireDate | +40 days |
Then the HTTP status code should be "<http_status_code>"
And the OCS status code should be "404"
And the sharing API should report to user "Carol" that no shares are in the pending state
And the information of the last share of user "Alice" should include
| expiration | +20 days |
Examples:
| ocs_api_version | http_status_code |
| 1 | 200 |
| 2 | 404 |

2
tests/acceptance/features/coreApiTrashbin/trashbinFilesFolders.feature
View File

@@ -99,7 +99,7 @@ Feature: files and folders exist in the trashbin after being deleted
| dav-path |
| spaces |
@skipOnOcV10 @issue-23151
# This scenario deletes many files as close together in time as the test can run.
# On a very slow system, the file deletes might all happen in different seconds.
# But on "reasonable" systems, some of the files will be deleted in the same second,

43
tests/acceptance/features/coreApiTrashbin/trashbinFilesFoldersOc10Issue23151.feature
View File

@@ -1,43 +0,0 @@
@api @files_trashbin-app-required @issue-ocis-reva-52 @notToImplementOnOCIS
Feature: files and folders exist in the trashbin after being deleted
As a user
I want deleted files and folders to be available in the trashbin
So that I can recover data easily
Background:
Given user "Alice" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "to delete" to "/textfile0.txt"
# This scenario deletes many files as close together in time as the test can run.
# On a very slow system, the file deletes might all happen in different seconds.
# But on "reasonable" systems, some of the files will be deleted in the same second,
# thus testing the required behavior.
# Note: skipOnDbOracle because Oracle is slow and so "close together in time" does not really happen
@issue-23151 @skipOnDbOracle
Scenario Outline: trashbin can store two files with the same name but different origins when the files are deleted close together in time
Given using <dav-path> DAV path
And user "Alice" has created folder "/folderA"
And user "Alice" has created folder "/folderB"
And user "Alice" has created folder "/folderC"
And user "Alice" has created folder "/folderD"
And user "Alice" has copied file "/textfile0.txt" to "/folderA/textfile0.txt"
And user "Alice" has copied file "/textfile0.txt" to "/folderB/textfile0.txt"
And user "Alice" has copied file "/textfile0.txt" to "/folderC/textfile0.txt"
And user "Alice" has copied file "/textfile0.txt" to "/folderD/textfile0.txt"
When user "Alice" deletes these files without delays using the WebDAV API
| /textfile0.txt |
| /folderA/textfile0.txt |
| /folderB/textfile0.txt |
| /folderC/textfile0.txt |
| /folderD/textfile0.txt |
Then the HTTP status code of responses on all endpoints should be "204"
# When issue-23151 is fixed, uncomment these lines. They should pass reliably.
# These files may or may not exist in the trashbin
# Then as "Alice" the folder with original path "/folderA/textfile0.txt" should not exist in the trashbin
# And as "Alice" the folder with original path "/folderB/textfile0.txt" should not exist in the trashbin
# And as "Alice" the folder with original path "/folderC/textfile0.txt" should not exist in the trashbin
# And as "Alice" the folder with original path "/folderD/textfile0.txt" should not exist in the trashbin
And as "Alice" the folder with original path "/textfile0.txt" should exist in the trashbin
Examples:
| dav-path |
| new |

2
tests/acceptance/features/coreApiTrashbinRestore/trashbinRestore.feature
View File

@@ -92,7 +92,7 @@ Feature: Restore deleted files/folders
| old | /textfile0.txt | PARENT/textfile0.txt |
| new | /textfile0.txt | PARENT/textfile0.txt |
@skipOnOcV10 @issue-35974
Scenario Outline: restoring a file to an already existing path overrides the file
Given user "Alice" has uploaded file with content "file to delete" to "/.hiddenfile0.txt"
And using <dav-path> DAV path

34
tests/acceptance/features/coreApiTrashbinRestore/trashbinRestoreOc10Issue35974.feature
View File

@@ -1,34 +0,0 @@
@api @files_trashbin-app-required @issue-ocis-reva-52 @notToImplementOnOCIS
Feature: Restore deleted files/folders
As a user
I would like to restore files/folders
So that I can recover accidentally deleted files/folders in ownCloud
@issue-35974
Scenario Outline: restoring a file to an already existing path overrides the file
Given user "Alice" has been created with default attributes and without skeleton files
And user "Alice" has uploaded file with content "file to delete" to "/textfile0.txt"
And user "Alice" has uploaded file with content "file to delete" to "/.hiddenfile0.txt"
And using <dav-path> DAV path
And user "Alice" has created folder "/PARENT"
And user "Alice" has uploaded file with content "PARENT file content" to <upload-path>
And user "Alice" has deleted file <delete-path>
When user "Alice" restores the file with original path <delete-path> to <upload-path> using the trashbin API
Then the HTTP status code should be "204"
# Sometimes <upload-path> is found in the trashbin. Should it? Or not?
# That seems to be what happens when the restore-overwrite happens properly,
# The original <upload-path> seems to be "deleted" and so goes to the trashbin
#And as "Alice" the file with original path <upload-path> should not exist in the trashbin
And as "Alice" file <upload-path> should exist
# sometimes the restore from trashbin does overwrite the existing file, but sometimes it does not. That is also surprising.
# the current observed behavior is that if the original <upload-path> ended up in the trashbin,
# then the new <upload-path> has the "file to delete" content.
# otherwise <upload-path> has its old content
And the content of file <upload-path> for user "Alice" if the file is also in the trashbin should be "file to delete" otherwise "PARENT file content"
#And the content of file <upload-path> for user "Alice" should be "file to delete"
Examples:
| dav-path | upload-path | delete-path |
| old | "/PARENT/textfile0.txt" | "/textfile0.txt" |
| new | "/PARENT/textfile0.txt" | "/textfile0.txt" |
| old | "/PARENT/.hiddenfile0.txt" | ".hiddenfile0.txt" |
| new | "/PARENT/.hiddenfile0.txt" | ".hiddenfile0.txt" |

2
tests/acceptance/features/coreApiWebdavLocks/exclusiveLocks.feature
View File

@@ -66,7 +66,7 @@ Feature: there can be only one exclusive lock on a resource
| new | shared |
| new | exclusive |
@skipOnOcV10 @issue-34358 @notToImplementOnOCIS
@notToImplementOnOCIS
Scenario Outline: if a child resource is exclusively locked a parent resource cannot be locked again
Given using <dav-path> DAV path
And user "Alice" has created folder "PARENT"

22
tests/acceptance/features/coreApiWebdavLocks/exclusiveLocksOc10Issue34358.feature
View File

@@ -1,22 +0,0 @@
@api @notToImplementOnOCIS @issue-ocis-reva-172
Feature: there can be only one exclusive lock on a resource
@issue-34358
Scenario Outline: if a child resource is exclusively locked a parent resource cannot be locked again
Given user "Alice" has been created with default attributes and without skeleton files
And user "Alice" has created folder "PARENT"
And user "Alice" has created folder "PARENT/CHILD"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/CHILD/child.txt"
And using <dav-path> DAV path
And user "Alice" has locked folder "PARENT/CHILD" setting the following properties
| lockscope | exclusive |
When user "Alice" locks folder "PARENT" using the WebDAV API setting the following properties
| lockscope | <lock-scope> |
Then the HTTP status code should be "200"
And 2 locks should be reported for file "PARENT/CHILD/child.txt" of user "Alice" by the WebDAV API
Examples:
| dav-path | lock-scope |
| old | shared |
| old | exclusive |
| new | shared |
| new | exclusive |

4
tests/acceptance/features/coreApiWebdavLocks/requestsWithToken.feature
View File

@@ -63,7 +63,7 @@ Feature: actions on a locked item are possible if the token is sent with the req
| new | shared |
| new | exclusive |
@skipOnOcV10 @issue-34338 @files_sharing-app-required @notToImplementOnOCIS
@files_sharing-app-required @notToImplementOnOCIS
Scenario Outline: share receiver cannot rename a file in a folder locked by the owner even when sending the locktoken
Given using <dav-path> DAV path
And user "Alice" has created folder "PARENT"
@@ -101,7 +101,7 @@ Feature: actions on a locked item are possible if the token is sent with the req
| shared | new | 423 |
| exclusive | new | 423 |
@skipOnOcV10 @issue-34360 @files_sharing-app-required
@files_sharing-app-required
Scenario Outline: two users having both a shared lock can use the resource
Given using <dav-path> DAV path
And user "Brian" has been created with default attributes and without skeleton files

25
tests/acceptance/features/coreApiWebdavLocks/requestsWithTokenOc10Issue34338.feature
View File

@@ -1,25 +0,0 @@
@api @notToImplementOnOCIS @issue-ocis-reva-172
Feature: actions on a locked item are possible if the token is sent with the request
@issue-34338 @files_sharing-app-required
Scenario Outline: share receiver cannot rename a file in a folder locked by the owner even when sending the locktoken
Given these users have been created with default attributes and without skeleton files:
| username |
| Alice |
| Brian |
And using <dav-path> DAV path
And user "Alice" has created folder "PARENT"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt"
And user "Alice" has shared folder "PARENT" with user "Brian"
And user "Alice" has locked folder "PARENT" setting the following properties
| lockscope | <lock-scope> |
When user "Brian" moves file "PARENT/parent.txt" to "PARENT/renamed-file.txt" sending the locktoken of file "PARENT" of user "Alice" using the WebDAV API
Then the HTTP status code should be "201"
And as "Alice" file "/PARENT/parent.txt" should not exist
But as "Alice" file "/PARENT/renamed-file.txt" should exist
Examples:
| dav-path | lock-scope |
| old | shared |
| old | exclusive |
| new | shared |
| new | exclusive |

29
tests/acceptance/features/coreApiWebdavLocks/requestsWithTokenOc10Issue34360.feature
View File

@@ -1,29 +0,0 @@
@api @notToImplementOnOCIS @issue-ocis-reva-172
Feature: actions on a locked item are possible if the token is sent with the request
@issue-34360 @files_sharing-app-required
Scenario Outline: two users having both a shared lock can use the resource
Given these users have been created with default attributes and without skeleton files:
| username |
| Alice |
| Brian |
And using <dav-path> DAV path
And user "Alice" has uploaded file with content "ownCloud test text file 0" to "textfile0.txt"
And user "Brian" 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 "Alice" has locked file "textfile0.txt" setting the following properties
| lockscope | shared |
And user "Brian" has locked file "textfile0 (2).txt" setting the following properties
| lockscope | shared |
When user "Alice" uploads file with content "from user 0" to "textfile0.txt" sending the locktoken of file "textfile0.txt" using the WebDAV API
Then the HTTP status code should be "423"
And the content of file "textfile0.txt" for user "Alice" should be "ownCloud test text file 0"
And the content of file "textfile0 (2).txt" for user "Brian" should be "ownCloud test text file 0"
When user "Brian" uploads file with content "from user 1" to "textfile0 (2).txt" sending the locktoken of file "textfile0 (2).txt" using the WebDAV API
Then the HTTP status code should be "423"
And the content of file "textfile0.txt" for user "Alice" should be "ownCloud test text file 0"
And the content of file "textfile0 (2).txt" for user "Brian" should be "ownCloud test text file 0"
Examples:
| dav-path |
| old |
| new |

2
tests/acceptance/features/coreApiWebdavLocksUnlock/unlock.feature
View File

@@ -64,7 +64,7 @@ Feature: UNLOCK locked items
| new | shared |
| new | exclusive |
@skipOnOcV10 @issue-34302 @files_sharing-app-required
@files_sharing-app-required
Scenario Outline: as public unlocking a file in a share that was locked by the file owner is not possible. To unlock use the owners locktoken
Given user "Alice" has created folder "PARENT"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt"

19
tests/acceptance/features/coreApiWebdavLocksUnlock/unlockOc10Issue34302.feature
View File

@@ -1,19 +0,0 @@
@api @notToImplementOnOCIS @issue-ocis-reva-172
Feature: UNLOCK locked items
@issue-34302 @files_sharing-app-required
Scenario Outline: as public unlocking a file in a share that was locked by the file owner is not possible. To unlock use the owners locktoken
Given user "Alice" has been created with default attributes and without skeleton files
And user "Alice" has created folder "PARENT"
And user "Alice" has uploaded file "filesForUpload/textfile.txt" to "PARENT/parent.txt"
And user "Alice" has created a public link share of folder "PARENT" with change permission
And user "Alice" has locked file "PARENT/parent.txt" setting the following properties
| lockscope | <lock-scope> |
When the public unlocks file "/parent.txt" with the last created lock of file "PARENT/parent.txt" of user "Alice" using the WebDAV API
Then the HTTP status code should be "405"
#Then the HTTP status code should be "403"
And 1 locks should be reported for file "PARENT/parent.txt" of user "Alice" by the WebDAV API
Examples:
| lock-scope |
| shared |
| exclusive |

6
tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunking.feature
View File

@@ -9,20 +9,20 @@ Feature: users cannot upload a file to a blacklisted name using old chunking
And using old DAV path
And user "Alice" has been created with default attributes and without skeleton files
@skipOnOcV10 @issue-36645 @notToImplementOnOCIS
@notToImplementOnOCIS
Scenario: Upload a file to a filename that is banned by default using old chunking
When user "Alice" uploads file "filesForUpload/textfile.txt" to "/.htaccess" in 3 chunks using the WebDAV API
Then the HTTP status code should be "403"
And as "Alice" file ".htaccess" should not exist
@skipOnOcV10 @issue-36645
Scenario: Upload a file to a banned filename using old chunking
Given the administrator has updated system config key "blacklisted_files" with value '["blacklisted-file.txt",".htaccess"]' and type "json"
When user "Alice" uploads file "filesForUpload/textfile.txt" to "blacklisted-file.txt" in 3 chunks using the WebDAV API
Then the HTTP status code should be "403"
And as "Alice" file "blacklisted-file.txt" should not exist
@skipOnOcV10 @issue-36645
Scenario Outline: upload a file to a filename that matches blacklisted_files_regex using old chunking
# Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it
# The actual regular expressions end up being .*\.ext$ and ^bannedfilename\..+

39
tests/acceptance/features/coreApiWebdavUpload2/uploadFileToBlacklistedNameUsingOldChunkingOc10Issue36645.feature
View File

@@ -1,39 +0,0 @@
@notToImplementOnOCIS @api @issue-ocis-reva-15
Feature: users cannot upload a file to a blacklisted name using old chunking
As an administrator
I want to be able to prevent users from uploading files to specified file names
So that I can prevent unwanted file names existing in the cloud storage
Background:
Given using OCS API version "1"
And using old DAV path
And user "Alice" has been created with default attributes and without skeleton files
@issue-36645
Scenario: Upload a file to a filename that is banned by default using old chunking
When user "Alice" uploads file "filesForUpload/textfile.txt" to "/.htaccess" in 3 chunks using the WebDAV API
Then the HTTP status code should be "507"
# Then the HTTP status code should be "403"
And as "Alice" file ".htaccess" should not exist
@issue-36645
Scenario: Upload a file to a banned filename using old chunking
Given the administrator has updated system config key "blacklisted_files" with value '["blacklisted-file.txt",".htaccess"]' and type "json"
When user "Alice" uploads file "filesForUpload/textfile.txt" to "blacklisted-file.txt" in 3 chunks using the WebDAV API
Then the HTTP status code should be "507"
# Then the HTTP status code should be "403"
And as "Alice" file "blacklisted-file.txt" should not exist
@issue-36645
Scenario Outline: upload a file to a filename that matches blacklisted_files_regex using old chunking
# Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it
# The actual regular expressions end up being .*\.ext$ and ^bannedfilename\..+
Given the administrator has updated system config key "blacklisted_files_regex" with value '[".*\\.ext$","^bannedfilename\\..+","containsbannedstring"]' and type "json"
When user "Alice" uploads file "filesForUpload/textfile.txt" to "<filename>" in 3 chunks using the WebDAV API
Then the HTTP status code should be "<http-status>"
And as "Alice" file "<filename>" should not exist
Examples:
| filename | http-status | comment |
| filename.ext | 507 | issue-36645 |
| bannedfilename.txt | 403 | ok |
| this-ContainsBannedString.txt | 403 | ok |

6
tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingOldChunking.feature
View File

@@ -9,14 +9,14 @@ Feature: users cannot upload a file to or into an excluded directory using old c
And using old DAV path
And user "Alice" has been created with default attributes and without skeleton files
@skipOnOcV10 @issue-36645
Scenario: Upload a file to an excluded directory name using old chunking
Given the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json"
When user "Alice" uploads file "filesForUpload/textfile.txt" to "/.github" in 3 chunks using the WebDAV API
Then the HTTP status code should be "403"
And as "Alice" file ".github" should not exist
@skipOnOcV10 @issue-36645
Scenario: Upload a file to an excluded directory name inside a parent directory using old chunking
Given user "Alice" has created folder "FOLDER"
And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json"
@@ -25,7 +25,7 @@ Feature: users cannot upload a file to or into an excluded directory using old c
And as "Alice" folder "/FOLDER" should exist
But as "Alice" file "/FOLDER/.github" should not exist
@skipOnOcV10 @issue-36645
Scenario Outline: upload a file to a filename that matches excluded_directories_regex using old chunking
# Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it
# The actual regular expressions end up being endswith\.bad$ and ^\.git

42
tests/acceptance/features/coreApiWebdavUpload2/uploadFileToExcludedDirectoryUsingOldChunkingOc10Issue36645.feature
View File

@@ -1,42 +0,0 @@
@notToImplementOnOCIS @api @issue-ocis-reva-15
Feature: users cannot upload a file to or into an excluded directory using old chunking
As an administrator
I want to be able to exclude directories (folders) from being processed. Any attempt to upload a file to one of those names should be refused.
So that I can have directories on my cloud server storage that are not available for syncing.
Background:
Given using OCS API version "1"
And using old DAV path
And user "Alice" has been created with default attributes and without skeleton files
@issue-36645
Scenario: Upload a file to an excluded directory name using old chunking
Given the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json"
When user "Alice" uploads file "filesForUpload/textfile.txt" to "/.github" in 3 chunks using the WebDAV API
Then the HTTP status code should be "507"
# Then the HTTP status code should be "403"
And as "Alice" file ".github" should not exist
@issue-36645
Scenario: Upload a file to an excluded directory name inside a parent directory using old chunking
Given user "Alice" has created folder "FOLDER"
And the administrator has updated system config key "excluded_directories" with value '[".github"]' and type "json"
When user "Alice" uploads file "filesForUpload/textfile.txt" to "/FOLDER/.github" in 3 chunks using the WebDAV API
Then the HTTP status code should be "507"
# Then the HTTP status code should be "403"
And as "Alice" folder "/FOLDER" should exist
But as "Alice" file "/FOLDER/.github" should not exist
@issue-36645
Scenario Outline: upload a file to a filename that matches excluded_directories_regex using old chunking
# Note: we have to write JSON for the value, and to get a backslash in the double-quotes we have to escape it
# The actual regular expressions end up being endswith\.bad$ and ^\.git
Given the administrator has updated system config key "excluded_directories_regex" with value '["endswith\\.bad$","^\\.git","containsvirusinthename"]' and type "json"
When user "Alice" uploads file "filesForUpload/textfile.txt" to "<filename>" in 3 chunks using the WebDAV API
Then the HTTP status code should be "<http-status>"
And as "Alice" file "<filename>" should not exist
Examples:
| filename | http-status | comment |
| thisendswith.bad | 507 | issue-36645 |
| .github | 403 | ok |
| this-containsvirusinthename.txt | 403 | ok |

4
tests/acceptance/features/coreApiWebdavUpload2/uploadFileUsingOldChunking.feature
View File

@@ -8,7 +8,7 @@ Feature: upload file using old chunking
Given using OCS API version "1"
And user "Alice" has been created with default attributes and without skeleton files
@skipOnOcV10 @issue-36115
Scenario Outline: Upload chunked file asc
Given using <dav_version> DAV path
When user "Alice" uploads the following "3" chunks to "/myChunkedFile.txt" with old chunking and using the WebDAV API
@@ -162,7 +162,7 @@ Feature: upload file using old chunking
| spaces | @a#8a=b?c=d |
| spaces | ?abc=oc # |
@skipOnOcV10 @issue-36115
Scenario Outline: Upload chunked file with old chunking with lengthy filenames
Given using <dav_version> DAV path
Given the owncloud log level has been set to debug

43
tests/acceptance/features/coreApiWebdavUpload2/uploadFileUsingOldChunkingOc10Issue36115.feature
View File

@@ -1,43 +0,0 @@
@notToImplementOnOCIS @api @issue-ocis-reva-17
Feature: upload file using old chunking
As a user
I want to be able to upload "large" files in chunks
So that the upload can be completed in less elapsed time
@issue-36115
Scenario: Upload chunked file asc
Given using OCS API version "1"
And using old DAV path
And user "Alice" has been created with default attributes and without skeleton files
When user "Alice" uploads the following "3" chunks to "/myChunkedFile.txt" with old chunking and using the WebDAV API
| number | content |
| 1 | AAAAA |
| 2 | BBBBB |
| 3 | CCCCC |
Then the HTTP status code should be "201"
And the following headers should match these regular expressions for user "Alice"
| ETag | /^[a-f0-9:\.]{1,32}$/ |
# | ETag | /^"[a-f0-9:\.]{1,32}"$/ |
And as "Alice" file "/myChunkedFile.txt" should exist
And the content of file "/myChunkedFile.txt" for user "Alice" should be "AAAAABBBBBCCCCC"
Scenario: Upload chunked file with old chunking with lengthy filenames
Given using OCS API version "1"
And using old DAV path
And user "Alice" has been created with default attributes and without skeleton files
And the owncloud log level has been set to debug
And the owncloud log has been cleared
When user "Alice" uploads the following chunks to "नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-12345678910.txt" with old chunking and using the WebDAV API
| number | content |
| 1 | AAAAAAAAAAAAAAAAAAAAAAAAA |
| 2 | BBBBBBBBBBBBBBBBBBBBBBBBB |
| 3 | CCCCCCCCCCCCCCCCCCCCCCCCC |
Then the HTTP status code should be "201"
And the following headers should match these regular expressions for user "Alice"
| ETag | /^[a-f0-9:\.]{1,32}$/ |
And as "Alice" file "नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-12345678910.txt" should exist
And the content of file "नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-नेपालि-file-नाम-12345678910.txt" for user "Alice" should be "AAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCCCCCCCCCCC"
And the log file should not contain any log-entries containing these attributes:
| app |
| dav |