Due to legacy reasons the password of link shares was returned in the
"share_with" and "share_with_displayname" parameters of the response
data. Now a proper "password" parameter is returned too; the old
"share_with" and "share_with_displayname" parameters are kept, although
deprecated, and they will be removed in a future version of Nextcloud.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the "hide download" property of a share is set the public share
page will not show the download button nor the menu with the download,
direct link and "Add to your Nextcloud" actions; the "downloadURL"
hidden field will not be included either in the generated HTML.
Despite that, note that the "downloadURL" parameter is still set and
passed to the template, as this could be needed anyway to generate
previews (for example, of audio files).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Now that we actually check thepermissions properly we have to update the
tests.
* We checked an invalid path
* We checked from wrong permissions (files never have CREATE permissions
for example)
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
The MountProvider for shares creates mount points for the files shared
with the user, which makes possible to use the received shared files and
folders as regular files and folders.
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>
