Skip to content

Commit

Permalink
fix share path when listing a specific share
Browse files Browse the repository at this point in the history
  • Loading branch information
David Christofas committed Aug 2, 2021
1 parent adceeb2 commit 155b344
Show file tree
Hide file tree
Showing 3 changed files with 12 additions and 38 deletions.
5 changes: 5 additions & 0 deletions changelog/unreleased/fix-share-path.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
Bugfix: Fix share path when listing a specific share

The file path and target of shares where missing the share jail path when a specific share was listed.

https://github.com/cs3org/reva/pull/1918
Original file line number Diff line number Diff line change
Expand Up @@ -52,6 +52,7 @@ import (
"github.com/cs3org/reva/pkg/rhttp/router"
"github.com/cs3org/reva/pkg/share/cache"
"github.com/cs3org/reva/pkg/share/cache/registry"
"github.com/cs3org/reva/pkg/user"
"github.com/cs3org/reva/pkg/utils"
"github.com/pkg/errors"
)
Expand Down Expand Up @@ -438,6 +439,12 @@ func (h *Handler) getShare(w http.ResponseWriter, r *http.Request, shareID strin
response.WriteOCSError(w, r, response.MetaServerError.StatusCode, "error mapping share data", err)
}
h.mapUserIds(ctx, client, share)
currentUser := user.ContextMustGetUser(ctx)
if share.State == ocsStateAccepted && share.ShareType != conversions.ShareTypePublicLink && currentUser.Username != share.UIDOwner {
// Needed because received shares can be jailed in a folder in the users home
share.FileTarget = path.Join(h.sharePrefix, path.Base(info.Path))
share.Path = path.Join(h.sharePrefix, path.Base(info.Path))
}

response.WriteOCSSuccess(w, r, []*conversions.ShareData{share})
}
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -5,44 +5,6 @@ Feature: sharing
Given using OCS API version "1"
And user "Alice" has been created with default attributes and without skeleton files

@skipOnOcis-EOS-Storage @toFixOnOCIS @issue-ocis-reva-243 @skipOnOcis-OCIS-Storage
# after fixing all issues delete this Scenario and use the one from oC10 core
Scenario: Share ownership change after moving a shared file to another share
Given these users have been created with default attributes and without skeleton files:
| username |
| Brian |
| Carol |
And user "Alice" has created folder "/Alice-folder"
And user "Alice" has created folder "/Alice-folder/folder2"
And user "Carol" has created folder "/Carol-folder"
And user "Alice" has shared folder "/Alice-folder" with user "Brian" with permissions "all"
And user "Carol" has shared folder "/Carol-folder" with user "Brian" with permissions "all"
When user "Brian" moves folder "/Alice-folder/folder2" to "/Carol-folder/folder2" using the WebDAV API
And user "Carol" gets the info of the last share using the sharing API
# Note: in the following fields, file_parent has been removed because OCIS does not report that
Then the fields of the last response to user "Carol" sharing with user "Brian" should include
| id | A_STRING |
| item_type | folder |
| item_source | A_STRING |
| share_type | user |
| file_source | A_STRING |
| file_target | /Carol-folder |
| permissions | all |
| stime | A_NUMBER |
| storage | A_STRING |
| mail_send | 0 |
| uid_owner | %username% |
| displayname_owner | %displayname% |
| mimetype | httpd/unix-directory |
# Really folder2 should be gone from Alice-folder and be found in Carol-folder
# like in these 2 suggested steps:
# And as "Alice" folder "/Alice-folder/folder2" should not exist
# And as "Carol" folder "/Carol-folder/folder2" should exist
#
# But this happens on OCIS:
And as "Alice" folder "/Alice-folder/folder2" should exist
And as "Carol" folder "/Carol-folder/folder2" should not exist

@skipOnOcis-OC-Storage @toFixOnOCIS @issue-ocis-reva-243 @skipOnOcis-OCIS-Storage
# same as oC10 core Scenario but without displayname_owner because EOS does not report it
# after fixing all issues delete this Scenario and use the one from oC10 core
Expand Down

0 comments on commit 155b344

Please sign in to comment.