* 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>
This removes custom rendering code an replaces it with the declarative menu actions.
Also adjust the template to allow the Vue UI to mount.
Custom entries still are possible.
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
Carl Schwan
Daniel Kesselberg
Côme Chilliet
Louis Chemineau
Carl Schwan
nfebe
Ferdinand Thiessen
Robin Appelman
skjnldsv
Benjamin Gaussorgues
provokateurin
dependabot[bot]
Christoph Wurst
Andy Scherzinger