The DeletedShareAPIController and ShareAPIController helpers for room
shares are defined in Talk, so the classes do not exist when Talk is not
installed. Due to this when the object returned by "getRoomShareHelper"
is used Phan complains that the class is not declared.
This is not a problem, though, because when the class is not available
"getRoomShareHelper" throws an exception, which is then caught where
that method was called. Therefore now those warnings from Phan are
suppressed (it would be better to use "@phan-suppress-next-line"
instead, but it is not yet available in our Phan version).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In some cases, the ShareAPIController requires explicit handling of each
type of share (for example, to format a share for a DataResponse). Room
shares are implemented in an external app (Nextcloud Talk), so in order
to keep the controller as isolated as possible from room share specifics
all that explicit handling is done in a helper class provided by the
Talk app.
In other cases it is just enough to call the share manager specifying a
room share type; note that the share manager is guarded against share
types for which there is no provider, so it is not necessary to
explicitly check that before passing room shares to the share manager.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
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>
Fixes#9028
For federated shares the share table holds no target information (since
it is on the other server). So when a node is actually invalid and not
found we should not display it anymore in the shared with sections etc
and thus throw the proper exceptions.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
When a share is shared with a circle the "share_with" field returned by
the API endpoint was always set to the name of the circle. However, the
name is not enough to identify a circle. The Circles app now provides
the ID of the circle in the "shared with" field of a Share, so this
commit modifies the API endpoint to set the "share_with" field to the ID
of the circle when provided by the Circles app.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The helper funtion did not handle the response correctly and basically
only returned the last share with tags.
This is a simple rewrite. That is still understandable. Loops maybe more
than strictly required. But preformance is not the issue here.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
If you set the permissions on a public share the SHARE permission makes
no sense. So instead of throwing a warning. Just filter out the share
permission.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
* 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>
Daniel Calviño Sánchez
Bjoern Schiessle
Morris Jobke
John Molakvoæ (skjnldsv)
Maxence Lange
Roeland Jago Douma
blizzz
Lukas Reschke
Michael Jobst
Joas Schilling
Vincent Petry