When deleting a user, we should only delete the direct remote user
shares or the remote group based subshares.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
When declining a remote group share through the dialog that appears when
notifications are off, the mount point is now correctly saved when
re-accepting.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
Accepting and declining can now be done repeatedly on both the parent
group share and sub-share with the same effects.
Added unit tests to cover these cases, and also when the same operation
is repeated.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
Fix pending shares endpoint to consider user-specific sub-entries
for group shares whenever a share was accepted or declined.
Added unit test for adding remote group shares.
Fixed "removeUserShares" to not send a remote request as we never send
remote requests for group shares.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
Use new scope values in settings page.
Adjust all consumers to use the new constants.
Map old scope values to new ones in account property getter.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
* it was skipped before anyways
* it is covered for example in build/integration/sharing_features/sharing-v1-part3.feature#L517-L548 (see 54f8f75f6f/build/integration/sharing_features/sharing-v1-part3.feature (L517-L548))
* more permission updates are tested in the webdav section, where an OCS API is called and the WebDAV response is checked for the properly changed permission
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
See build/integration/sharing_features/sharing-v1*.features for the exact same tests. Especially part3 that covers most of the different permission setups over webdav.
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
The remote URL of a share is always stored in the database with a
trailing slash. However, when a cloud ID is generated trailing slashes
are removed.
The ID of a remote storage is generated from the cloud ID, but the
"cleanup-remote-storage" command directly used the remote URL stored in
the database. Due to this, even if the remote storage was valid, its ID
did not match the ID of the remote share generated by the command and
ended being removed.
Now the command generates the ID of remote shares using the cloud ID
instead, just like done by the remote storage, so there is no longer a
mismatch.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Reduces calls to DI container by reusing already fetched dependencies.
For status.php it went from 355 to 344.
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
Right now we just delete the shares from the DB. Which is efficient
sure. But doesn't trigger any real cleanup. So no Admin audit entries or
any other post processing is done.
This makes sure we really trigger this.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>