This is important especially for local development, as certificate are
self-signed.
Signed-off-by: Salvatore Martire <4652631+salmart-dev@users.noreply.github.com>
First check which users have a shares and for which providers and then
only load these shares.
Avoid doing at most 5 SQL queries for each users a share was shared with if
there are no shares.
Signed-off-by: Carl Schwan <carlschwan@kde.org>
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>
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>
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 commits addresses an annoyance where the share input placeholder would
suggest sharing via federated cloud ID even if federation was disabled.
Signed-off-by: nfebe <fenn25.fn@gmail.com>
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>
