Add integration tests for deleting a file copied from a share #52970
Conversation
This file contains hidden or 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
Note that the delete permission is implicitly disabled in the first test because the delete permission is automatically removed for single file shares. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
danxuliu
added
help wanted
2. developing
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
See #51846
After 199b0bd if a received share was copied, or if a file was copied from a received shared folder without delete permissions, the copied file could not be deleted. The problem seems to be that the cache of the files copied from a storage (like a share) is also copied, so the permissions of the copied file are the same as the permissions of the original file. The regression appeared only for files copied to a local storage; files copied to an object store retained their permissions already before that commit, unless it was explicitly disabled by setting
handleCopiesAsOwned.Note that single file shares do not have the delete permission, so it happened even without explicitly disabling it (and, in fact, it is not even possible to explicitly enable it, it is always disabled).
For reference, both when copying a received share and when copying a file from a received shared folder if the file is copied in a local storage the permissions can be fixed by rescanning it with
occ files:scan(orocc groupfolders:scanif it is copied into a group folder). On the other hand, this has no effect when using an object store.In the case of single file shares the bug was fixed (or, at least, the first test passes, maybe there are other cases) with 88c685f when using an object store, and with 6419de7 when using local storage, but it is still present in both cases when copying files from a received shared folder without delete permissions (second test).
As the scenarios were added to dav_features/webdav-related.feature they are also run with an object store as primary storage in CI. Note that
handleCopiesAsOwnedis not set), but as mentioned the first test passes nevertheless after 88c685f.