You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When trying to resolve URLs like https://cloud.ocis.test/f/<spacealias>/relative/path?id=b78c2044-5b51-446f-82f6-907a664d089c:194b4a97-597c-4461-ab56-afd4f5a21607 the web may need to rely on the id if the <spacealias> is not unique or if a segment in the relative path was renamed.
The gateway will route requests to the correct storageprovider, the storageprovider can look up the resouce and return a ResourceInfo.
But currently the path is either
absolute in the global namespace (when an absolute reference was used) or
relative to the reference in the request -> always just the basename
What we do NOT get is the id of the space and where in the space the the resource is located. But that is what the web ui would need in the response to correctly show the space and the relative path to the resource with id b78c2044-5b51-446f-82f6-907a664d089c:194b4a97-597c-4461-ab56-afd4f5a21607.
This was why I initially proposed using a Reference for the type of Path in the ResourceInfo.
I propose to add a new SpaceRef property of type Reference to ResourceInfo. When a relative Reference was used ResourceInfo can then contain the SpaceRef which might differ on who is accessing the resource: for the owner it would be the root of the personal space. For a share recipient it would be the root of the closest share when walking up the tree.
Why not return the complete relative path instead of the basename when a relative Reference was used in the request? The Reference:ResourceId may not have been a storage space root, but any node. The web UI would still not know which storage space to show.
An alternative would be to have a ParentReference property in the ResourceInfo. Absolute path References would return a path, absolute id References would return the parent ResourceID. And relative references could return a Reference for the parent with the root of the Space as id and a relative path. Then it would however make sense to rename ResourceID:Path to Name because we split parent and name anyway.
I think a dedicated SpaceRef is semantically cleaner because it always points to the root of the closest space the current user has acces to with a relative path.
An alternative would be to have a Parent Reference property in the ResourceInfo. Absolute path References would return a path, absolute id References would return the parent ResourceID. And relative references could return a Reference for the parent with the root of the Space as id and a relative path. Then it would however make sense to rename ResourceID:Path to Name because we split parent and name anyway.
This also makes sense for wopi which is trying to find out if it can access the parent of a resource.
Furthermore, GetPath() should return a path and a root resourceid for the relative path. The root might not always be a space root. It can also be any shared node.
A ParentID on the ResourceInfo should cover our needs in edge. A full Reference is not needed. To look up the full path the GetPath() is still needed.
When trying to resolve URLs like
https://cloud.ocis.test/f/<spacealias>/relative/path?id=b78c2044-5b51-446f-82f6-907a664d089c:194b4a97-597c-4461-ab56-afd4f5a21607
the web may need to rely on the id if the<spacealias>
is not unique or if a segment in the relative path was renamed.The gateway will route requests to the correct storageprovider, the storageprovider can look up the resouce and return a ResourceInfo.
But currently the path is either
What we do NOT get is the id of the space and where in the space the the resource is located. But that is what the web ui would need in the response to correctly show the space and the relative path to the resource with id
b78c2044-5b51-446f-82f6-907a664d089c:194b4a97-597c-4461-ab56-afd4f5a21607
.This was why I initially proposed using a
Reference
for the type ofPath
in theResourceInfo
.I propose to add a new
SpaceRef
property of typeReference
toResourceInfo
. When a relativeReference
was usedResourceInfo
can then contain theSpaceRef
which might differ on who is accessing the resource: for the owner it would be the root of the personal space. For a share recipient it would be the root of the closest share when walking up the tree.Why not return the complete relative path instead of the basename when a relative
Reference
was used in the request? TheReference:ResourceId
may not have been a storage space root, but any node. The web UI would still not know which storage space to show.An alternative would be to have a
Parent
Reference
property in theResourceInfo
. Absolute path References would return a path, absolute id References would return the parentResourceID
. And relative references could return a Reference for the parent with the root of the Space as id and a relative path. Then it would however make sense to renameResourceID:Path
toName
because we split parent and name anyway.I think a dedicated
SpaceRef
is semantically cleaner because it always points to the root of the closest space the current user has acces to with a relative path.Related: owncloud/ocis#1876
cc @C0rby @pmaier1 @tbsbdr
The text was updated successfully, but these errors were encountered: