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
If we do not allow public upload we should limit the permissions on
links shares upon retrieval.
* Added unit test
* Allow fetching federated shares by token as well
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
Fixes#23536
The new sharing code is much stricter in checking permissions. However
for non moveable mounts the permissions UPDATE+DELETE are not reported
on the mount point.
This is just a quick fix.
* Updated unit tests
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
Sharing of the users root folder should not be allowed as it is very
weird UX. Also many of our clients have no proper way of displaying
this.
Added unit test
Also added intergration tests to make sure we won't allow it in the
future.
Incomming federated shares are a special kind. We mount them as normal
webdav shares but we do supply owner info with the federated cloud id of
the share owner.
Since we do not yet have the new resharing behaviour on federated shares
we need to set the correct owner. Which will allow sharing and proper
mounting for other users.
fixes#22500
Fixes#19685
The default expiration date should only be set when we create a new
share. So if a share is created and the expiration date is unset. And
after that the password is updated the expiration date should remain
unset.
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.
