To continue this formatting madness, here's a tiny patch that adds
unified formatting for control structures like if and loops as well as
classes, their methods and anonymous functions. This basically forces
the constructs to start on the same line. This is not exactly what PSR2
wants, but I think we can have a few exceptions with "our" style. The
starting of braces on the same line is pracrically standard for our
code.
This also removes and empty lines from method/function bodies at the
beginning and end.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
* Order the imports
* No leading slash on imports
* Empty line before namespace
* One line per import
* Empty after imports
* Emmpty line at bottom of file
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Getting the shares of a file no longer returns shares with the current
user for consistency with the results when getting the shares including
subfiles.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"ShareManager::getSharesBy()" already checks if the share provider
exists before returning the shares and, if the provider does not exist,
it returns an empty array. Therefore it is not needed to explicitly
check if the provider exists or not.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This provides a better context for apps using the event, for example to
load one script or another depending on whether the share is a file or a
folder.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
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>
Julius Härtl
Joas Schilling
Christoph Wurst
Christoph Wurst
Roeland Jago Douma
Maxence Lange
John Molakvoæ (skjnldsv)
Roeland Jago Douma
Daniel Kesselberg
Daniel Calviño Sánchez
Morris Jobke
Michael Weimann
Bjoern Schiessle
Jan-Christoph Borchardt