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>
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 now sets `isDefaultEnabled` to false. This makes email notifications for file uploads
to public links disabled by default (opt-in) for users.
This addresses concerns about new notifications being enabled by
default for existing users, leading to unexpected emails.
Related: https://github.com/nextcloud/server/pull/46945
Signed-off-by: nfebe <fenn25.fn@gmail.com>
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>
- Fix autoloading for new `ConfigLexicon`
- Ensure that sharing input in sharing tab respect `show-federated-shares-as-internal`:
This is important, because when federated shares are shown as internal the users should add them from the internal shares section
Signed-off-by: nfebe <fenn25.fn@gmail.com>
If several people are watching and seeking the same video file we do not
want the cache key to be the same or it would flood activity again.
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
Remove duplicate activity publishing from share controller download,
listen to BeforeZipCreatedEvent to publish activity for folders, and
cache folders activity to avoid sending activity for each file in the
folder.
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.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>
Co-authored-by: Ferdinand Thiessen <opensource@fthiessen.de>
Co-authored-by: Kate <26026535+provokateurin@users.noreply.github.com>
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>
