A user with reshare permissions on a file is now able to get any share
of that file (just like the owner).
Signed-off-by: John Molakvoæ (skjnldsv) <skjnldsv@protonmail.com>
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>
When a constructor is spied using Sinon it is wrapped by a proxy
function, which calls the original constructor when invoked. When "new
Foo()" is executed a "Foo" object is created, "Foo" is invoked with the
object as "this", and the object is returned as the result of the whole
"new" expression.
Before Sinon 4.1.3 the proxy called the original constructor directly
using the "thisValue" of the spied call; "thisValue" was the object
created by the "new" operator that called the proxy. The proxy assigned
"thisValue" to "returnValue", so it was also the value returned by the
proxy and, in turn, the value returned by the whole "new" expression.
Since Sinon 4.1.3 (see pull request 1626) the proxy calls the original
constructor using "new" instead of directly. The "thisValue" created by
the outermost "new" (the one that called the proxy) is no longer used by
the original constructor; the internal "new" creates a new object, which
is the one passed to the original constructor and returned by the
internal "new" expression. This object is also the value returned by the
proxy ("returnValue") and, in turn, the value returned by the whole
outermost "new" expression.
Thus, now "returnValue" should be used instead of "thisValue" to get the
object created by the spied constructor.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
* introduce a Controller for requests
* introduce result sorting mechanism
* extend Comments to retrieve commentors (actors) in a tree
* add commenters sorter
* add share recipients sorter
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
Julius Härtl
John Molakvoæ (skjnldsv)
Joas Schilling
Roeland Jago Douma
Christoph Wurst
Morris Jobke
Michael Weimann
Daniel Calviño Sánchez
Bjoern Schiessle
Jan-Christoph Borchardt
Maxence Lange
Tobia De Koninck
Arthur Schiwon
Robin Appelman