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>
- global color functions are now deprecated - use color namespace
- `@import` is deprecated and will be removed (will be native CSS import
in future)
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
Prevent silent addition of expiration date to shares.
Prevent silent addition for password to shares.
Both now have a `shareRequiresReview` check
Resolves : https://github.com/nextcloud/server/issues/48860
Signed-off-by: fenn-cs <fenn25.fn@gmail.com>
Currently new shares are added to beginning of the share list in the UI
messing up the ordering with the original (first) looking like the most
recent and the most recent looking like the original share. This error
disappears on refresh.
Resolves : https://github.com/nextcloud/server/issues/48415
Signed-off-by: fenn-cs <fenn25.fn@gmail.com>
If there is already a password, there is no need to require the password
in the setting ('newPassword'). It is only required for new shares.
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>
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>
