enabling sync of share gives empty filename as response

[S-Panta]

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

• moodle-repository_ocis minium requirement is ocis-5.0

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.

[saw-jan]

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

[rhafer]

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]

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]

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]

cc @fschade see #8961 (comment)

[tbsbdr]

backport not planned; will be fixed with next release

[rhafer]

backport not planned; will be fixed with next release

Actually as noted in #8961 (comment) this is a severe bug in master as well (the error behavior is just slightly different).

[micbar]

correct. Thanks.

[fschade]

WIP: cs3org/reva#4714

[micbar]

Needs reva bump to close that.

[micbar]

Bump has been merged.

[S-Panta]

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