The hook now calls the share manager that will call the responsible
shareProvider to do the proper cleanup.
* Unit tests added
Again nothing should change it is just to cleanup old code
This makes the post_userDelete hook call the sharemanager. This will
cleanup to and from this user.
* All shares owned by this user
* All shares with this user (user)
* All custom group shares
* All link share initiated by this user (to avoid invisible link shares)
Unit tests are added for the defaultshare provider as well as the
federated share provider
In 9.0 we converted the old shares to the new shares. So for 9.1 we can
savely remove the fallback code.
This code was required when there was no initiator set.
* Fixed unit tests
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.
For group shares we can have children. Those are custom shares when a
user has moved or deleted a group share. Those also have to be deleted
if the group share is removed.
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.
This allows recipient to delete a share. For user shares this is the
same as deleting (at least for now).
But for group shares this means creating a new share with type 2. With
permissions set to 0.
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.
