ocis icon indicating copy to clipboard operation
ocis copied to clipboard

[stable] enabling sync of share gives empty filename as response

Open S-Panta opened this issue 10 months ago • 1 comments

Describe the bug

Enabling sync of share using the new graph API works but the response has . as it's filename for stable branch. In master, this bug has been fixed but fix pr has not been backported to stable which causes moodle-repository-ocis to evolve issues.

Reason to report this issue

Steps to reproduce

1.user einstein share resource test.txt with admin. 2. admin disable sync of resource 3.admin send request to enable sync using graph API.

curl -X POST 'https://host.docker.internal:9200/graph/v1beta1/drives/{share-Space-Id}/root/children'  
-d '{
    "remoteItem": {
        "id":"'remote-item-id"
    }
}'

Expected behavior

"@client.synchronize": true,
"@UI.Hidden": false,
"eTag": "\"b3bd3355452b980042d3fc2f27bd2624\"",
"name": "test.txt",

Actual behavior

"@client.synchronize": true,
"@UI.Hidden": false,
"name": ".",

Setup

ocis 5.0.2

OCIS_XXX=somevalue
OCIS_YYY=somevalue
PROXY_XXX=somevalue

Additional context

Add any other context about the problem here.

S-Panta avatar Apr 25 '24 07:04 S-Panta

@rhafer any chance that this will get fixed in stable-5 branch? If not then maybe we can close the issue

saw-jan avatar Apr 25 '24 07:04 saw-jan

In master, this bug has been fixed but fix pr has not been backported to stable which causes moodle-repository-ocis to evolve issues.

Actually in master the accepted driveItem does not have a name at all (unless the recevied share already has a mount point set).

rhafer avatar May 16 '24 08:05 rhafer

It seems the whole logic for figuring out a default MountPath (i.e. name of the driveitem) when accepting/mounting a share is missing in sharing-ng. AFAICS we need something like: https://github.com/cs3org/reva/blob/348c76a4ec2ad33fdc25fe5f783d378149ab7c5b/internal/http/services/owncloud/ocs/handlers/apps/sharing/shares/pending.go#L123 in graph.

rhafer avatar May 16 '24 08:05 rhafer

Regarding a stable backport: With all the changes that happend in master I rather not backport the resulting fix. (Unless REALLY needed, AFAIK all the exiting users of sharing ng in stable have auto accepting enabled, so there it shouldn't be an issue)

rhafer avatar May 16 '24 08:05 rhafer

cc @fschade see https://github.com/owncloud/ocis/issues/8961#issuecomment-2114475218

rhafer avatar May 16 '24 08:05 rhafer

backport not planned; will be fixed with next release

tbsbdr avatar May 27 '24 09:05 tbsbdr

backport not planned; will be fixed with next release

Actually as noted in https://github.com/owncloud/ocis/issues/8961#issuecomment-2114475218 this is a severe bug in master as well (the error behavior is just slightly different).

rhafer avatar May 27 '24 09:05 rhafer

correct. Thanks.

micbar avatar May 27 '24 12:05 micbar

WIP: https://github.com/cs3org/reva/pull/4714

fschade avatar Jun 06 '24 15:06 fschade

Needs reva bump to close that.

micbar avatar Jun 11 '24 17:06 micbar

Bump has been merged.

micbar avatar Jun 19 '24 20:06 micbar

On the master , there is no need to send the item name in body However, on stable 5, such should be done.

{
  "name": "test.txt",
  "remoteItem": {
    "id": "remote- item-id"
  }
}

If if name is not given and user tries to enable share via API, the output looks like this image

S-Panta avatar Jun 20 '24 08:06 S-Panta