Enable recycle bin for arbitrary paths

[ishank011]

Currently, all recycle bin operations in oCIS are made available via the /remote.php/dav/trash-bin/$username/$key/$path endpoints. These are restricted to only the logged-in user's home, but access for shared spaces is not yet available.

Considering a user case, in CERNBox, we have service accounts associated with project spaces and users having access to a specific project space should be able to list and restore deleted entries. This is supported by the ListRecycleRequest message in CS3APIs, so now, it needs to be added to clients.

Similar to the /remote.php/webdav/$path and /remote.php/dav/$user/$path parallel,
I propose to add a new API /remote.php/webdav/trash-bin/$base-path/$key/$path,
which will allow access to the recycle spin associated with other accounts, given that the user has access to $base-path.
For example, /remote.php/webdav/trash-bin/projects/physics-simulations

Both the implementations can share the same code, as is the case with the old and new files endpoints.

Please let me know your thoughts about this @labkode @butonic @refs @C0rby @dragotin

[butonic]

Try not to think af paths first. Let me explain: /remote.php/webdav/trash-bin would overshadow /remote.php/webdav and collide with any existing folder called trash-bin in a users home. Maybe not in your deployment, but in classic oc10 /remote.php/webdav lists the users home, not a global namespace.

We introduced the /dav endpoint in oc10 as the new endpoint that is supposed to make every resource adressable by a unique path. That is why /dav/files/$user contains the username. We failed to fully carry that through: you still cannot access another users tree. Access to a shared file has to happen through your endpoint. The spaces concept aims to finally solve that properly using the /dav/spaces/$spaceid endpoint.

Anyway, the /dav endpoint also has a /dav/trash-bin/$username/$key/$path endpoint as you already mentioned. We might extend this endpoint to include the base path, eg: /dav/trash-bin/$username/$base-path/$key/$path although that would require checking the number of path segments.

Spaces to the rescue: the /graph/v1.0/me/drives endpoint is intended to give clients a single endpoint to list all the drives (aka spaces / the root nodes of trees) the user has access to. That includes the users personal space (aka home drive), projects and shares.

Every space has special folders endpoint, which in msgraph contains documents, photos, cameraroll, approot, music.

Listing childern in the special folder is done with /me/drive/special/{special-folder-name}/children or /drives/{id}/special/{special-folder-name}/children

IMO we should add trash as a special folder.

Listing the trash for a specific space or 'project' could then be done with GET /graph/v1.0/drives/{id}/special/trash/children

The id here would be the spaceid that the ListSpaces API calls return. For decomposedfs we use the nodeid of the root as the spaceid and it is concatenated with storageid + "!" + nodeid you could do the same for eos: list all user homes and project roots as spaces.

Try to think of the global namespace in the CS3 API as a tree that organizes multiple spaces into a human readable tree. The challenge in the global namespace is that users can mount shares in their Shares folder, which may create naming collisions. But that is just naming problem. Technically, all resources still have an id and could be distinguished. The spaces concept assigns a spaceid for every tree, so that clients can always identify all resources. They may have better ways of resolving naming collisions then the CS3 global namespace, which has to prevent share name collisions.

The global namespace and the spaces concept complement each other. They are different ways of navigating to a resource. While it would be possible to expose something like /spaces/{spaceid} in the CS3 namespace these ids would be meaningless to end users. Furthermore, a federated storage has to deal with spaces in different instances where admins may have completely different global namespaces set up to better match their organizations terminology.

To make a long story short: I would prefer to use /graph/v1.0/drives/{id}/special/trash to manage the trash of different storage spaces.

[butonic]

@ishank011 we could allow sending a $base-path in the header of a PROPFIND /dav/trash-bin/$username/$key/$path, eg. CS3-BASE-PATH: /projects/physics-simulations. the ocdav implementation can then look up the storage provider and send a ListRecycleRequest that has a reference for that base?

The web ui would have to learn sending that base path. cc @micbar @kulmann @tbsbdr but how should the ui look for multiple trash bins anyway?

[butonic]

Regarding a spaces implementation for eos: that can be done incrementally. The easiest step is to list spaces, which is what we started with for the decomposedfs: glob all user homes, stat them and fetch the eos fileid, use it as the spaceid.

For projects I assume you have a dedicated storageprovider per project? no homeenabled flag, so the eos fileid of it can be the storage spaceid. Or you use a layout to define where roots are.

This does lead to a storage space registry instead of a storage registry, but that is a different topic.

[ishank011]

@butonic yes, that is what I'm aiming for as well. Instead of a header, would it make more sense to have a query parameter?

Currently, the default path that we use is the user home

reva/internal/http/services/owncloud/ocdav/trashbin.go

Lines 198 to 211 in 19f83bd

	getHomeRes, err := gc.GetHome(ctx, &provider.GetHomeRequest{})
	if err != nil {
	sublog.Error().Err(err).Msg("error calling GetHome")
	w.WriteHeader(http.StatusInternalServerError)
	return
	}
	if getHomeRes.Status.Code != rpc.Code_CODE_OK {
	HandleErrorStatus(&sublog, w, getHomeRes.Status)
	return
	}
	// ask gateway for recycle items
	getRecycleRes, err := gc.ListRecycle(ctx, &gateway.ListRecycleRequest{Ref: &provider.Reference{Path: path.Join(getHomeRes.Path, key, itemPath)}})

I can add a check that if a base_path parameter is passed, that is to be used as the path.

I also split the ref and key into two separate arguments cs3org/cs3apis#152, because joining the base, key and relative path and passing it as one string seemed like a workaround.

Regarding the UI changes, we have an ocis extension that we use to display projects https://github.com/cernbox/ocis-eosprojects. What we had in mind was that in addition to displaying the list of projects, we'll add a link to their respective trash bins as well. @diocas would be better able to explain the design @kulmann @tbsbdr

[ishank011]

Regarding a spaces implementation for eos: that can be done incrementally. The easiest step is to list spaces, which is what we started with for the decomposedfs: glob all user homes, stat them and fetch the eos fileid, use it as the spaceid.

Yes, I would be very interested in taking this up for EOS but I'm afraid we don't have the bandwidth at the moment. Once we're done with our rollouts, I'd be happy to get started with this, but it won't be possible for the next 2-3 months at least.