This needs to be able to directly download files if specified to only
download a single file and not a folder.
Also it was possible to either pass a files array json encoded or a
single file not encoded at all.
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
This removes all the read after write and we don't need to queries all
the time the same share in the same request anymore.
Signed-off-by: Carl Schwan <carl.schwan@nextcloud.com>
When creating public links from federated shares, users should be able to set
the 'Hide download' option independently as long as they are more restrictive
than the original share permissions.
Previously, the `checkInheritedAttributes` method was ignoring user preferences
and always overriding the hideDownload setting based solely on inherited
permissions, preventing users from disabling downloads even when the parent
share allowed them.
This fix implements some sort of inheritance logic:
- Users can only be MORE restrictive than parent shares, never LESS restrictive
- If parent hides downloads -> child MUST hide downloads (enforced)
- If parent allows downloads -> child can CHOOSE to hide or allow downloads
- If parent forbids downloads entirely -> child cannot enable downloads
Signed-off-by: nfebe <fenn25.fn@gmail.com>
* Remove old IProvider interface, it's been deprecated since 17.0.0 (8
years)
* Add type hinting to the IPreview interface and mark it as consumeable
only
* Remove unused arguments from GeneratorHelper
Signed-off-by: Carl Schwan <carl.schwan@nextcloud.com>
If encryption got disabled, copying should set encrypted to 0 for the
new unencrypted copy. For instance when using encryption:decrypt-all
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
Signed-off-by: Louis Chemineau <louis@chmn.me>
This allows the admin to control the behavior whether link shares with
READ permissions should be extended to also gain SHARE permissions,
allowing users (public share receivers) to add the share to their cloud.
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
- split the test into individual test cases
- fix invalid call to `onConsecutiveCalls` (it was called more than
defined values and is deprecated in v10 anyways).
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
Classes need to exist to be mocked (reflection), thus unknown classes
only can be mocked as `stdClass`.
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
This was missing from the Vue migration of the public share view:
- Show the note as the description of the file drop
- Show the label as the heading of the file drop if available
- Show list of uploaded files for verification
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
When a user receives a share with share-permissions but also with
download restrictions (hide download or the modern download permission attribute),
then re-shares of that share must always also include those restrictions.
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
Given:
User creates a link or email share with permissions=4 (create only = file drop).
Problem:
Currently the permissions are automatically extended to permissions = 5
(READ + CREATE). Work around was to create the share and directly update
it.
Solution:
Respect what the user is requesting, create a file drop share.
Co-authored-by: Ferdinand Thiessen <opensource@fthiessen.de>
Co-authored-by: Côme Chilliet <91878298+come-nc@users.noreply.github.com>
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
Previously there was a different behavior for public shares (link-shares) and internal shares,
if the user disabled the view permission.
The legacy UI for public shares simply "disabled" the context menu and hided all download actions.
With Nextcloud 31 all share types use the consistent permissions attributes,
which simplifies code, but caused a regression: Images can no longer been viewed.
Because on 30 and before the attribute was not set, previews for view-only files
were still allowed. Now with 31 we need a new way to allow "viewing" shares.
So this is allowing previews for those files, but only for internal usage.
This is done by settin a special header, which only works with custom requests,
and not by opening the URL directly.
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
