Due to a misplaced "||" instead of "===" the condition was always met,
so every share type in the conditional chain after the remote and remote
group shares was formatted as a remote/remote group share.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the receiver of a group share modifies it (for example, by moving
it to a different folder) the original share is not modified, but a
"ghost" share that keeps track of the changes made by that specific user
is used instead.
By default, the method "getShareById" in the share provider returns the
share from the point of view of the sharer, but it can be used too to
get the share from the point of view of a sharee by providing the
"recipient" parameter (and if the sharee is not found then the share is
returned from the point of view of the sharer).
The "ShareAPIController" always formats the share from the point of view
of the current user, but when getting the information of a specific
share the "recipient" parameter was not given, so it was always returned
from the point of view of the sharer, even if the current user was a
sharee. Now the "recipient" parameter is set to the current user, and
thus the information of the share is returned from the point of view of
the current user, be it the sharer or a sharee.
Note that this special behaviour of "getShareById" happens only with
group shares; with other types of shares the share is the same for the
sharer and the sharee, and thus the parameter is ignored; it was added
for them too just for consistency.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
* 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>
Fixes the following:
1. user0 shares folder with user1 (RO but with sharing permissions)
2. user1 shares by link
3. user1 send 'publicUpload=true' OCS request to the link share
before this increased the permissions of the link share. Which should
not happen.
now: API reponds with an error that the permissions can't be increased.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
It was already a controller just still residing in its old location.
* Moved ShareAPIController to user plain userID instead of user object
* Moved Share20OCS to ShareAPIController
* Removed initisation of class from Application.php and leave it to the
AppFramework
* Fixed tests
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
2016-10-24 09:52:34 +02:00
Renamed from apps/files_sharing/tests/API/Share20OCSTest.php (Browse further)
