-
Notifications
You must be signed in to change notification settings - Fork 199
Fix REPORT response from webdav #4485
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
💥 Acceptance test Core-API-Tests-ocis-storage-9 failed. Further test are cancelled... |
@ScharfViktor could you help me with the failing tests? We updated the REPORT endpoint to be consistent with the PROPFIND webdav endpoint:
It seems any of these three changes break the tests. |
Yes sure. let me switch to your branch and debug it local |
test failed because:
|
PROPFIND request give us: should be results(REPORT and PROPFIND requests) be same? |
@ScharfViktor yes, the goal was to have them consistent. However there is one thing I don't understand. As you said spaceID looks like Second question, whats the usual way to fix such problems? Should I put them on expected failures, then fix the test and then remove them again? Or is there another procedure I should follow? |
No, not exactly. search result returns us 1284d238-aa92-42ce-bdc4-0b0000009157$5ae7fa50-cdf1-43d6-82a5-8f58c65c25f4!5ae7fa50-cdf1-43d6-82a5-8f58c65c25f4 (3 uuid: |
Move please failed tests to expected failures. after merging your PR, I create 2 PRs (fix test in core and deleting tests from expected failures in ocis). |
What about this one? It's just that if I change search tests to new implementation-> propfind tests will be failed |
Yes exactly. That was a bug on my side. When comparing to
Thanks! will do so.
The fields that are in both |
129d6b9
to
856c160
Compare
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.
Commented on some typos, but otherwise looks good from what I can tell.
Signed-off-by: jkoberg <[email protected]>
Signed-off-by: jkoberg <[email protected]>
Signed-off-by: jkoberg <[email protected]>
d01663d
to
d00deb6
Compare
Kudos, SonarCloud Quality Gate passed! |
response := propfind.ResponseXML{ | ||
Href: net.EncodePath(path.Join("/dav/spaces/", match.Entity.Ref.ResourceId.StorageId+"!"+match.Entity.Ref.ResourceId.OpaqueId, match.Entity.Ref.Path)), | ||
Href: net.EncodePath(path.Join("/remote.php/dav/spaces/", ref)), |
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.
why do we have to prefix with the legacy remote.php
?
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.
To be consistent with ocdav PROPFIND endpoint
@kobergj changelog and pull request id is not matching. Can we fix that on master? |
There were multiple issue with REPORT search response from webdav. Also we want it to be consistent with PROPFIND endpoint.
remote.php
prefix was missing from the href (added even though not neccessary)shareroot
(containing the name of the share root) was missingowncloud/web#7557