Fixes#22675
Since we only get a share id we do not know the path for the sharer.
Now if we edit a share we start searching for shares for that user of
that node. And deduce the permissions that way.
* Intergration test added
* Fix unit tests
An incomming federated share is just a mount point. Therefor if we
request the permissions on the mountpoint DELETE permissions will be
returned (among others). Since we can always remove a mountpoint, update
a mount point.
However now when trying to reshare we will try to reshare with DELETE
permissions. Which is false.
This PR removes the delete permissions if it is a shared storage.
Basically a quick hack.
Fixes#22587
Since we have lazy shares it can happen that a share is actually
invalid. See https://github.com/owncloud/core/issues/20908
This add checks for the get methods to handle the NotFound exception.
It can happen that the share initiator is deleted. Because of the new
resharing behaviour this share then still exists. We just can fetch the
displayname properly.
This allows all clients to quickly get the share info for a given path.
Instead of returning everything and filtering it then manually on the
client side.
If a user deletes a group share we create a special share entry. To the
API this is just a normal group share for that user with permissions 0.
But we should not return this.
Now that we support multiple managers we communicate shares to the
outside as 'providerId:shareId'. This makes sures that id's are unique
when references from the OCS API.
However, since we do not want to break the OCS API v1 we need to
somewhat hack around this.
When we switch to OCS API v2 (which we should when we support more
custom providers). We will change the id to always be the fullShareId.
Roeland Jago Douma
Thomas Müller