[tests-only] [full-ci] Enhance share copy-overwrite test scenarios to demonstrate current behaviour

[phil-davis]

Description

A share receiver can do a COPY webDAV API request to COPY a resource of theirs "over the top" of a received share. That results in some interesting behavior. This PR expands the existing acceptance tests so that they demonstrate all the "interesting" behavior that I could notice.

1. Brian shares a folder with Alice. Alice copies a file directly over the received folder.
2. Brian shares a file with Alice. Alice copies a folder directly over the received file.
3. Brian shares a file with Alice. Alice copies a file directly over the received file.
4. Brian shares a folder with Alice. Alice copies a folder directly over the received folder.

Let's say that the file or folder is called "resource".

In each case, the share from Brian to Alice switches into the "declined" state. Alice can accept the share again, and the shared resource from Brian is now called "/Shares/resource (2)" The original name "/Shares/resource" is the thing that Alice copied.

For item (3) (file copied to existing shared file) probably the system should copy the content into "/Shares/resource" and Brian will see new content in the file called "resource" that he shared to Alice.

For item (4) (folder copied to existing shared folder) there could be some rules for merging the folder structure from Alice into the folder structure that was shared from Brian. (Some algorithm for that would also apply to when Alice copies a folder "over the top" of one of her own personal folders) Or that sort of COPY could be rejected, probably 409 - Conflict would be a suitable HTTP status

For items (1) and (2), probably the COPY request should be rejected with 409 - Conflict. If Brian shares a file or folder to Alice, giving Alice write access, then I don't think that Brian would be wanting Alice to change the resource from file to folder, or folder to file.

How Has This Been Tested?

CI

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Database schema changes (next release will require increase of minor version instead of patch)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:
• Changelog item, see TEMPLATE

[phil-davis]

@pmaier1 this demonstrates what happens in oC10. The desired behavior needs to be decided. And then sort out if the decided behavior will be implemented in oC10, reva and/or oCIS.

There might be similar for if Alice does a MOVE rather than a COPY - but whatever oC10 currently does, I suspect that the desired behavior will be consistent/similar for MOVE and for COPY.

Your thoughts please.

[phil-davis]

@pmaier1 ping - what do you think the behavior should be?

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[phil-davis]

For this scenario (copying a file over an existing file) it would probably be reasonable that the content of the target file gets updated, and the target file still stays as Brian's file that is shared with Alice, and Brian will get to see the updated file content that Alice just copied there.

The "copy" by Alice is really a lot like Alice doing an update request for the target file.

Both Alice and Brian will probably be surprised by the current behavior. Alice will probably expect that Brian can see the updated content that she thinks that she has copied to the file.

[phil-davis]

The current behavior is sort-of-reasonable. If the folder really did replace the shared file, then Brian would be surprised to see that the file that he shared with Alice has "suddenly" turned into a folder.

For Alice, it seems a bit odd to me that the shared file 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.

[phil-davis]

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 so the file-folder name conflict never happens.

[phil-davis]

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.

[phil-davis]

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)

[phil-davis]

I am not sure what to say about this scenario - copying a folder over the top of an existing folder. There could be some attempt to merge the content of both folders together, but that becomes complex.

Probably in real life Alice does not quite know what she wants to happen for this case anyway, and it would be OK to return 409 Conflict for this sort of copy request. If Alice wants to add new content to the received share from Brian, she can copy individual files and folders there (rather than trying to do a whole copy-overwrite).

[phil-davis]

@pako81 @jnweiger your opinion please. There was discussion about this "cpoy overwrite" behavior last year, and the desired behavior did not get defined.

We could merge this PR - it just "documents" the current oC10 behavior.

And make issue(s) for anything where the required behavior is different to the current behavior.

[pako81]

My 2 cents.

Brian shares a folder with Alice. Alice copies a file directly over the received folder.

I do agree to return a 409 Conflict here. Brian would be surprised to see that the folder that he shared with Alice has "suddenly" turned into a file.--> agreed

Brian shares a file with Alice. Alice copies a folder directly over the received file.

I do agree to return a 409 Conflict here. Brian would be surprised to see that the file that he shared with Alice has "suddenly" turned into a folder. --> agreed

Brian shares a file with Alice. Alice copies a file directly over the received file.

I do agree to update the target here. It would probably be reasonable that the content of the target file gets updated, and the target file still stays as Brian's file that is shared with Alice, and Brian will get to see the updated file content that Alice just copied there. --> agreed

Brian shares a folder with Alice. Alice copies a folder directly over the received folder.

In an ideal world I would probably try to have both folders merged. Not sure how complex it would be, though. I guess if this turns out to be too complex, returning a 409 Conflict would be ok as well.

[phil-davis]

I adjusted the test scenarios for issue #40787 and #40788

• copy a file to a received shared file - the content should be copied into the received shared file
• copy a folder into a received shared folder - 409 "conflict" response should be given

[phil-davis]

@pako81 @jnweiger please review. I raised issues for the 2 things that I think need changes - #40787 and #40788

If you agree with the scenarios, then we can merge this. And then any work to adjust the system behavior gets scheduled according to priority/need/etc

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[pako81]

Agreed with the test scenarios.