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 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>
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>
Because of timezones, not saving time can lead to unexpected behaviour
when sharing an item sooner than timezone offset
Example: sharing a file before 9am when in UTC+9
Signed-off-by: Benjamin Gaussorgues <benjamin.gaussorgues@nextcloud.com>
If an user in UTC+1 try to create a share at 00:00, it's day D for him, but
D-1 for the server (UTC).
This fix aims to apply the correct offset
Signed-off-by: Benjamin Gaussorgues <benjamin.gaussorgues@nextcloud.com>
The API currently overrides the supplied permissions with "read only"
when a file is shared via link. It allows to update the permissions
later, however.
This keeps the default to "read only" but honors the permissions
supplied by API call if any.
Signed-off-by: Jan-Philipp Litza <jpl@plutex.de>
- Fix tests
- Use non deprecated event stuff
- Add a bit of type hinting to the new stuff
- More safe handling of instanceOfStorage (share might not be the first
wrapper)
- Fix resharing
Signed-off-by: Carl Schwan <carl@carlschwan.eu>
of type TYPE_EMAIL, when the "video verification" checkbox isn't checked. Users accessing
non-anonymous public shares (TYPE_EMAIL shares) can now request a temporary password themselves.
- Creates a migration step for the files_sharing app to add the 'password_expiration_time'
attribute to the oc_shares table.
- Makes share temporary passwords' expiration time configurable via a system value.
- Adds a system config value to allow permanent share passwords
-Fixes a typo in a comment in apps/files_sharing/src/components/SharingEntryLink.vue
See https://github.com/nextcloud/server/issues/31005
Signed-off-by: Cyrille Bollu <cyrpub@bollu.be>
