[full-ci] bump reva to c33c803283ee #10172
Conversation
Signed-off-by: Jörn Friedrich Dreyer <[email protected]>
|
Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes. |
|
ok, this fails: @issue-4421
Scenario Outline: sharee PROPFIND same name shares shared by multiple users using new dav path # /dronesrc/tests/acceptance/features/apiSharingNg1/propfindShares.feature:53
Given using <dav-path-version> DAV path #FeatureContext::usingOldOrNewDavPath()
And user "Alice" has uploaded file with content "to share" to "textfile.txt" #FeatureContext::userHasUploadedAFileWithContentTo()
And user "Alice" has created folder "folderToShare" #FeatureContext::userHasCreatedFolder()
And user "Carol" has uploaded file with content "to share" to "textfile.txt" #FeatureContext::userHasUploadedAFileWithContentTo()
And user "Carol" has created folder "folderToShare" #FeatureContext::userHasCreatedFolder()
And user "Alice" has sent the following resource share invitation: #SharingNgContext::userHasSentTheFollowingResourceShareInvitation()
| resource | <resource> |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Viewer |
And user "Brian" has a share "<resource>" synced #SharingNgContext::userHasShareSynced()
And user "Carol" has sent the following resource share invitation: #SharingNgContext::userHasSentTheFollowingResourceShareInvitation()
| resource | <resource> |
| space | Personal |
| sharee | Brian |
| shareType | user |
| permissionsRole | Viewer |
And user "Brian" has a share "<resource-2>" synced #SharingNgContext::userHasShareSynced()
When user "Brian" sends PROPFIND request from the space "Shares" to the resource "Shares" using the WebDAV API #SpacesContext::userSendsPropfindRequestFromTheSpaceToTheResourceWithDepthUsingTheWebdavApi()
Then the HTTP status code should be "207" #FeatureContext::thenTheHTTPStatusCodeShouldBe()
And the "PROPFIND" response to user "Brian" should contain a space "Shares" with these key and value pairs: #SpacesContext::theResponseShouldContainMountPoint()
| key | value |
| oc:fileid | UUIDof:Shares |
| oc:name | Shares |
And the "PROPFIND" response to user "Brian" should contain a mountpoint "Shares" with these key and value pairs: #SpacesContext::theResponseShouldContainMountPoint()
| key | value |
| oc:fileid | UUIDof:<resource> |
| oc:name | <resource> |
| oc:permissions | S |
And the "PROPFIND" response to user "Brian" should contain a mountpoint "Shares" with these key and value pairs: #SpacesContext::theResponseShouldContainMountPoint()
| key | value |
| oc:fileid | UUIDof:<resource-2> |
| oc:name | <resource-2> |
| oc:permissions | S |
Examples:
| dav-path-version | resource | resource-2 |
| old | textfile.txt | textfile (1).txt |
Failed step: And the "PROPFIND" response to user "Brian" should contain a mountpoint "Shares" with these key and valuepairs:
wrong fileId in the response
Failed asserting that an array contains 'a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668!a4fd2951-56cf-4bd4-88b7-d05f299384d0:9ddc3a0-055d-46f3-b47a-222cf50f01d0:526c46a9-7ded-4e54-ae6d-b57433a9a419'.
| old | folderToShare | folderToShare (1) |
Failed step: And the "PROPFIND" response to user "Brian" should contain a mountpoint "Shares" with these key and valuepairs:
wrong fileId in the response
Failed asserting that an array contains 'a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668!a4fd2951-56cf-4bd4-88b7-d05f299384d0:38e0f3d-1bbf-4964-92e0-ea5d4cdc8fd5:b13cdcfa-5eb8-44bb-ba08-ac763e52f3ae'.
| new | textfile.txt | textfile (1).txt |
Failed step: And the "PROPFIND" response to user "Brian" should contain a mountpoint "Shares" with these key and valuepairs:
wrong fileId in the response
Failed asserting that an array contains 'a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668!a4fd2951-56cf-4bd4-88b7-d05f299384d0:40676d9-9256-4b21-9c4d-aceeede012e4:e0f82b48-8997-4e0d-b18c-3ef16ca57983'.
| new | folderToShare | folderToShare (1) |
Failed step: And the "PROPFIND" response to user "Brian" should contain a mountpoint "Shares" with these key and valuepairs:
wrong fileId in the response
Failed asserting that an array contains 'a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668!a4fd2951-56cf-4bd4-88b7-d05f299384d0:d39f88a-f1f2-4792-93b3-688a4b1d049b:fc5efc5d-94d4-4b53-be5e-d83f352ab56f'.🤔 ok ... the test is wrong, it assumes the resource id of the shared resource is the same as the mountpoint. unfortunately that is no longer a valid assumption. |
|
That leaves Scenario Outline: recipient of the shared resource tries to remove a tag # /drone/src/tests/acceptance/features/apiSpaces/tag.feature:153
Given user "Alice" has sent the following resource share invitation: # SharingNgContext::userHasSentTheFollowingResourceShareInvitation()
| resource | folderMain |
| space | use-tag |
| sharee | Brian |
| shareType | user |
| permissionsRole | <permissions-role> |
And user "Brian" has a share "folderMain" synced # SharingNgContext::userHasShareSynced()
And user "Alice" has created the following tags for <resource-type> "<resource>" of the space "use-tag": # TagContext::theUserHasCreatedFollowingTags()
| tag in a shared resource |
| second tag |
When user "Brian" removes the following tags for <resource-type> "<resource>" of space "Shares": # TagContext::userRemovesTagsFromResourceOfTheSpace()
| tag in a shared resource |
| second tag |
Then the HTTP status code should be "<http-status-code>" # FeatureContext::thenTheHTTPStatusCodeShouldBe()
When user "Alice" lists all available tags via the Graph API # TagContext::theUserGetsAllAvailableTags()
Then the HTTP status code should be "200" # FeatureContext::thenTheHTTPStatusCodeShouldBe()
And the response <should-or-not> contain following tags: # TagContext::theFollowingTagsShouldExistForUser()
| tag in a shared resource |
| second tag |
Examples:
| permissions-role | resource-type | resource | http-status-code | should-or-not |
| Viewer | file | folderMain/insideTheFolder.txt | 403 | should |
| Editor | file | folderMain/insideTheFolder.txt | 200 | should not |
| Viewer | folder | folderMain | 403 | should |
| Editor | folder | folderMain | 200 | should not | Failed step: And the response should not contain following tags: the response should not contain the tag tag in a shared resource. Response Array (
[0] => second tag
[1] => tag in a shared resource ) Failed asserting that true is false. |
after debugging I see that:
but in the same case when folder wasn't renamed (prefics (1)) -> that works fine In the process, I honestly got confused with these tons of uuid and what should be there and what should not. here is my screens: 
|
|
Correct. #9933 is about a mountpoint having different ids, depending on which href you use: When listing the space root the PROPFIND https://cloud.ocis.test/dav/spaces/a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668/
<oc:id>a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668!166d1210-cdb9-50ab-9f1e-ecb9ef12a304:4c510ada-c86b-4815-8820-42cdf82c3d51:3ef59385-34ba-4055-b705-f4f05f1388a4</oc:id>But when using a PROPFIND against the same resource, but directly referencing it it shows the id from the shared resource: PROPFIND https://cloud.ocis.test/dav/spaces/a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668/Universe/
<oc:id>166d1210-cdb9-50ab-9f1e-ecb9ef12a304$4c510ada-c86b-4815-8820-42cdf82c3d51!17634536-719e-47c4-bf8b-e8b97188259a</oc:id>That confuses clients who remember the fileid: Android, iOS and deskop as well, but I cannot find an issue right now. @TheOneRing might be able to provide a link. In your screenshots, the PROPFIND https://ocis-server:9200/remote.php/dav/spaces/a0ca6a90-a365-4782-871e-d44447bbc668$a0ca6a90-a365-4782-871e-d44447bbc668/folderToShare (1)response contains multiple resource ids:
That is how it should be, because the The share jail of Brian should only contain resource ids from the share jail when listing the root: the root directory in the share jail always has the id When listing these sub directories, the child id should become the root id and the children will have the resource id from the actual space. Before this PR, the root id would also wrongly change to the resource id from the actual space. I hope this clarifies the expectations. |
|
regarding
|
Signed-off-by: Jörn Friedrich Dreyer <[email protected]>
|
we were using the resource id from the share jail instead of the actual resource id. fixed with 0f525e9 there might be other code paths were the share jail id is used. all clients should try to look up the actual resource id and not rely on the id returned by the sharejail. |
Signed-off-by: Jörn Friedrich Dreyer <[email protected]>
butonic
changed the title
|
I merged the reva PR as @ScharfViktor and fixed the remaining bug and added the enabling auto merge |
|
[full-ci] bump reva to 02af5a266
pull in cs3org/reva#4835 to test a fix for #9933