* Skip null groups in group manager (#26871)
* Skip null groups in group manager
* Also skip null groups in group manager's search function
* Add more group null checks in sharing code
* Add unit tests for null group safety in group manager
* Add unit tests for sharing code null group checks
* Added tests for null groups handling in sharing code
* Ignore moveShare optional repair in mount provider
In some cases, data is inconsistent in the oc_share table due to legacy
data. The mount provider might attempt to make it consistent but if the
target group does not exist any more it cannot work. In such case we
simply ignore the exception as it is not critical. Keeping the
exception would break user accounts as they would be unable to use
their filesystem.
* Adjust null group handing + tests
* Fix new group manager tests
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
While using the object store, the shares, that are moved to trashbin were still detected as accessible and cause broken shares to be shown in file/folder listing.
Otherwise disabling sharing does prevent access to the view controllers but one can still access the shares using the public preview route or the public WebDAV endpoint.
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
If the sharebymail app (or the federatedshareprovider app) are disabled
this kills a lot of stuff. So we should handle a share provider not
begin available a bit more graceful.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
When resolving a group share to the user group share we used to do this
on a per share basis. Now we try to do this for all group shares at
once. Of course still chunked.
Before: N incomming group shares this would mean 1 + N queries
Now: N incomming roups shares this would mean 1 + 1 queries
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
The DefaultShareProvider now does a DB-level check to find out whether
file_source is accessible at all (deleted file) or whether it's in the
trashbin of a home storage.
One small corner case where the home storage id is in md5 form cannot
be covered properly with this approach.
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
Link shares always allowed deletion, however internally the permissions
were stored as 7 which lacked delete permissions. This created an
inconsistency in the Webdav permissions.
This fix makes sure we include delete permissions in the share
permissions, which now become 15.
In case a client is still passing 7 for legacy reasons, it gets
converted automatically to 15.
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
