Pending and deleted shares are not mounted into the user's filesystem, so
generic file operations like delete or download produced a misleading
"file is not available" error.
These shares now carry no permissions, so every permission-aware action
hides itself automatically, without the files app having to special-case
each view. Conversion additionally requires read permission, matching the
server-side readability check.
Signed-off-by: nfebe <fenn25.fn@gmail.com>
We will keep these legacy ones for now. We can search for the
ImpureStaticProperty suppression and add special treatement for them in
the frankenphp PR if needed.
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
The diff can be checked using: git diff --ignore-all-space --ignore-blank-lines
To see only the changes not related to blank lines.
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
When an ownCloud-migrated group share (which has no per-user USERGROUP
subshare) is renamed for the first time, DefaultShareProvider::move()
inserted a new USERGROUP row without setting `accepted`. The column
defaulted to 0 (STATUS_PENDING), causing MountProvider to skip the
share on the next login — the shared file disappeared for the recipient.
Fix: set accepted = STATUS_ACCEPTED explicitly on the INSERT in
DefaultShareProvider::move() for the TYPE_GROUP branch.
Secondary fix: SharedMount::moveMount() silently returned true when
updateFileTarget() threw (e.g. group no longer exists on an OC-migrated
instance). Set $result = false in the catch block so View::rename()
propagates the failure instead of silently corrupting VFS state.
An opt-in occ command (sharing:fix-owncloud-group-shares) with --dry-run
support is included to repair existing broken instances. It targets only
TYPE_USERGROUP subshares with accepted=STATUS_PENDING and permissions!=0
(shares that were accepted but broken by the missing column default),
leaving explicitly declined shares (permissions=0) untouched.
AI-Assisted-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Anna Larch <anna@nextcloud.com>
When a new share is saved it is first created in the backend and then
updated with some additional attributes set in the frontend. If custom
tokens are enabled the attributes to update also include the token.
However, for new shares the token is set by the backend when it is
created, it is not defined by the frontend, so the token returned by the
backend needs to be copied to the share data in the frontend. Otherwise
the update would fail because an empty token is sent.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Pre-declare newPassword on the share state so Vue 2's reactivity covers
it from the start. Without this, $set later relies on a
property-addition notification path that races with the toggle's async
setter and intermittently drops the password in certain build
environments.
Fixes: #57011
-e
Signed-off-by: Peter Ringelmann <peter.ringelmann@nextcloud.com>
Git'Fellow
Ferdinand Thiessen
Salvatore Martire
Kent Delante
Robin Appelman
Nextcloud bot
Joas Schilling
Micke Nordin
nfebe
Enrique Pérez Arnaud
Côme Chilliet
Benjamin Gaussorgues
Carl Schwan
Carl Schwan
Anna Larch
Andy Scherzinger
Stephan Orbaugh
Daniel Calviño Sánchez
provokateurin
Peter Ringelmann