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>
This can happen in various scenarios, we should allow the user to delete
the share in this situation.
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
The password param should never be sent if the intention is not
remove it or update it.
This commit adapts the frontend and backend to this rule to avoid weird bugs
especially around updating new shares.
Signed-off-by: nfebe <fenn25.fn@gmail.com>
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>
Exceptions thrown from password_policy may bubble up in share creation
or update when a password is used. Their message is meant to be shown
to the user. This always the case for HintException so we catch that
instead of the subclass GenericShareException.
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
It looks like, the frontend it needs to provide the `sendMail` param
for the backend to decide wether mails would be sent.
Our UI does not have that at the moment so it should default to sending
emails always for mail shares.
Not exactly sure how this was handled earlier but this is a good starting point.
Resolves : https://github.com/nextcloud/server/issues/48012
Signed-off-by: fenn-cs <fenn25.fn@gmail.com>
