[tests-only] [full-ci] Enhance share copy-overwrite test scenarios to demonstrate current behaviour #40308
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,51 @@ | ||
| @api | ||
| Feature: copy file | ||
| As a user | ||
| I want to be able to copy files | ||
| So that I can manage my files | ||
|
|
||
| # When fixing this issue, delete this bug-demo feature file. | ||
| # And unskip the corresponding scenario in copyFile.feature and make it pass. | ||
| Background: | ||
| Given using OCS API version "1" | ||
| And 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 "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" | ||
| And user "Alice" has uploaded file with content "ownCloud test text file 1" to "/textfile1.txt" | ||
|
|
||
| @issue-40787 @files_sharing-app-required | ||
| Scenario Outline: copy a file over the top of an existing file received as a user share | ||
| Given using <dav_version> DAV path | ||
| And user "Brian" has been created with default attributes and without skeleton files | ||
| And user "Brian" has uploaded file with content "file to share" to "/sharedfile1.txt" | ||
| And user "Brian" has shared file "/sharedfile1.txt" with user "Alice" | ||
| And user "Alice" has accepted share "/sharedfile1.txt" offered by user "Brian" | ||
| When user "Alice" copies file "/textfile1.txt" to "/Shares/sharedfile1.txt" using the WebDAV API | ||
| Then the HTTP status code should be "204" | ||
| # Alice now sees the content of "her" file in /Shares/sharedfile1.txt | ||
| # The share that she received from Brian has "automatically" gone into the "declined" state | ||
| And as "Alice" file "/Shares/sharedfile1.txt" should exist | ||
| And the content of file "/Shares/sharedfile1.txt" for user "Alice" should be "ownCloud test text file 1" | ||
| And as "Alice" file "/textfile1.txt" should exist | ||
| And user "Alice" should not have any received shares | ||
| And the sharing API should report to user "Alice" that these shares are in the declined state | ||
| | path | | ||
| | /Shares/sharedfile1.txt | | ||
| # Brian still has his original "/sharedfile1.txt" and can see that it is shared with Alice | ||
| And as "Brian" file "/sharedfile1.txt" should exist | ||
| And the content of file "/sharedfile1.txt" for user "Brian" should be "file to share" | ||
| # Alice can accept the share from Brian again | ||
| When user "Alice" accepts share "/sharedfile1.txt" offered by user "Brian" using the sharing API | ||
| Then the OCS status code should be "100" | ||
| And the HTTP status code should be "200" | ||
| # now Alice has "her" text file as "/Shares/sharedfile1.txt" | ||
| # and has the shared folder from Brian as "/Shares/sharedfile1 (2).txt" | ||
| And as "Alice" file "/Shares/sharedfile1.txt" should exist | ||
| And the content of file "/Shares/sharedfile1.txt" for user "Alice" should be "ownCloud test text file 1" | ||
| And as "Alice" file "/Shares/sharedfile1 (2).txt" should exist | ||
| And the content of file "/Shares/sharedfile1 (2).txt" for user "Alice" should be "file to share" | ||
| Examples: | ||
| | dav_version | | ||
| | old | | ||
| | new | |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,64 @@ | ||
| @api | ||
| Feature: copy file | ||
| As a user | ||
| I want to be able to copy files | ||
| So that I can manage my files | ||
|
|
||
| # When fixing this issue, delete this bug-demo feature file. | ||
| # And unskip the corresponding scenario in copyFile.feature and make it pass. | ||
| Background: | ||
| Given using OCS API version "1" | ||
| And 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 "Alice" has uploaded file with content "ownCloud test text file 0" to "/textfile0.txt" | ||
| And user "Alice" has uploaded file with content "ownCloud test text file 1" to "/textfile1.txt" | ||
| And user "Alice" has created folder "/FOLDER" | ||
|
|
||
| Scenario Outline: copy a folder over the top of an existing folder received as a user share | ||
| Given using <dav_version> DAV path | ||
| And user "Brian" has been created with default attributes and without skeleton files | ||
| And user "Brian" has created folder "/BRIAN-Folder" | ||
| And user "Brian" has created folder "BRIAN-Folder/sample-folder" | ||
| And user "Brian" has shared folder "BRIAN-Folder" with user "Alice" | ||
| And user "Alice" has accepted share "/BRIAN-Folder" offered by user "Brian" | ||
| And user "Alice" has created folder "FOLDER/ALICE-folder" | ||
| When user "Alice" copies folder "/FOLDER" to "/Shares/BRIAN-Folder" using the WebDAV API | ||
| Then the HTTP status code should be "204" | ||
| # Alice now sees the content of "her" folder as folder "/Shares/BRIAN-Folder" | ||
| # The share that she received from Brian has "automatically" gone into the "declined" state | ||
| And as "Alice" folder "/FOLDER/ALICE-folder" should exist | ||
| And as "Alice" folder "/Shares/BRIAN-Folder/ALICE-folder" should exist | ||
| And user "Alice" should not have any received shares | ||
| And the sharing API should report to user "Alice" that these shares are in the declined state | ||
| | path | | ||
| | /Shares/BRIAN-Folder | | ||
| # Brian still has his original BRIAN-Folder and can see that it is shared with Alice | ||
| And as "Brian" folder "BRIAN-Folder" should exist | ||
| And as "Brian" folder "BRIAN-Folder/sample-folder" should exist | ||
| When user "Brian" gets all shares shared by him using the sharing API | ||
| Then the OCS status code should be "100" | ||
| And the HTTP status code should be "200" | ||
| And file "/Shares/BRIAN-Folder" should be included in the response | ||
| When user "Alice" accepts share "/BRIAN-Folder" offered by user "Brian" using the sharing API | ||
| Then the OCS status code should be "100" | ||
| And the HTTP status code should be "200" | ||
| # now Alice has "her" folder as "/Shares/BRIAN-Folder" | ||
| # and has the shared file from Brian as "/Shares/BRIAN-Folder (2)" | ||
| And as "Alice" folder "/Shares/BRIAN-Folder" should exist | ||
| And as "Alice" folder "/Shares/BRIAN-Folder/ALICE-folder" should exist | ||
| And as "Alice" folder "/Shares/BRIAN-Folder (2)" should exist | ||
| And as "Alice" folder "/Shares/BRIAN-Folder (2)/sample-folder" should exist | ||
| # Alice can add content to both folders | ||
| # Brian sees what Alice puts into "/Shares/BRIAN-Folder (2)" | ||
| And user "Alice" has created folder "/Shares/BRIAN-Folder/new-folder1" | ||
| And user "Alice" has created folder "/Shares/BRIAN-Folder (2)/new-folder2" | ||
| And user "Alice" has uploaded file with content "new content 1" to "/Shares/BRIAN-Folder/new-folder1/file1.txt" | ||
| And user "Alice" has uploaded file with content "new content 2" to "/Shares/BRIAN-Folder (2)/new-folder2/file2.txt" | ||
| And the content of file "/Shares/BRIAN-Folder/new-folder1/file1.txt" for user "Alice" should be "new content 1" | ||
| And the content of file "/Shares/BRIAN-Folder (2)/new-folder2/file2.txt" for user "Alice" should be "new content 2" | ||
| And the content of file "/BRIAN-Folder/new-folder2/file2.txt" for user "Brian" should be "new content 2" | ||
| Examples: | ||
| | dav_version | | ||
| | old | | ||
| | new | |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current behavior is sort-of-reasonable. If the file really did replace the shared folder, then Brian would be surprised to see that the folder that he shared with Alice has "suddenly" turned into a file.
For Alice, it seems a bit odd to me that the shared folder received from Brian has now "disappeared" and she has to accept the share again.
So perhaps the server should reject this copy request and return something like 409 Conflict.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And in real-life this sort of thing is almost never going to happen - most "real users" have files that have file-types (*.doc *.txt *.odt etc.), and the have folders that do not have a "dot something" type on the end of the name. So they would never call a folder "name.txt", and never have a file without a file-type at the end, and so the file-folder name conflict never happens. (Computer geeks have executable code and scripts that do not have a file-type at the end - so the file-folder-name conflict does happen sometimes for them)