webdav does't return oc:remote-item-id oc:shareroot properties

[AlexAndBear]

Describe the bug

oc:remote-item-id oc:shareroot are not returned in propfind

Steps to reproduce

1. Make a webdav request on a shared resource, request oc:remote-item-id/ oc:shareroot/ as Dav props
2. See you don't get requested props returned

Setup

Please describe how you started the server and provide a list of relevant environment variables or configuration files.

OCIS_XXX=somevalue
OCIS_YYY=somevalue
PROXY_XXX=somevalue

Additional context

Add any other context about the problem here.

[butonic]

Hm, they are only returned in the search report:

	if match.Entity.Ref.ResourceId.StorageId == utils.ShareStorageProviderID {
		propstatOK.Prop = append(propstatOK.Prop, prop.Escaped("oc:shareid", match.Entity.Ref.ResourceId.OpaqueId))
		propstatOK.Prop = append(propstatOK.Prop, prop.Escaped("oc:shareroot", match.Entity.ShareRootName))
		propstatOK.Prop = append(propstatOK.Prop, prop.Escaped("oc:remote-item-id", storagespace.FormatResourceID(&provider.ResourceId{
			StorageId: match.Entity.GetRemoteItemId().GetStorageId(),
			SpaceId:   match.Entity.GetRemoteItemId().GetSpaceId(),
			OpaqueId:  match.Entity.GetRemoteItemId().GetOpaqueId(),
		})))
	}

AFAICT they are only available on mount points in the share jail. We should be able to add them in the sharejail as well.

[butonic]

Hm ... I take that back. When navigating into a shared folder the resource id will use the actual resource id, causing the request to never pass the sharesstorageprovider that could enrich the response with the shareid or mountpoint. This is by design, as constructing the sharejail is slow.

When navigating a space clients should maintain the working directory in a context, similar to what the CLI does. You typically navigate from the root of a space and can append the directory name to the working directory whenever nevigationg into it.

With the spaces concept clients need to learn that multiple spaces/roots exist.

The challenge is constructing a PWD when following a url that only contains a file id like https://cloud.ocis.test/f/storage-users-1$some-admin-user-id-0000-000000000000%216c9941a4-4343-4978-acd7-1fced616c5c9

A client can get a list of all known roots accessible to the user at the graph/v1.0/me/drives endpoint. Then he can use the parentid of a resource to walk up the tree until ho finds a parentid that matches a spaceid.

Clients should never ask the server about full paths, because a resource can actually have multiple roots when a user has received multiple shares for it. Leaving out shares, the space for a resource can be extracted from the resourceid (don't start parsing the id) or as part of a propfind response. Again, the full path has to be reconstructed again by walking to the top via the parentid. This is deterministic.

Sharing makes this non deterministic, because every share in effect creates a new space root: a resource without a parentid. We can use the registry to organize all the resources without a parent into a tree. Currently, that is what the drives endpoint and the spaceAlias is used for.

Sorry, long winded answer for 'won't fix' / 'works as designed'. Let me know if anything is unclear.