fix(sharing): set STATUS_ACCEPTED when creating USERGROUP subshare on…

[miaulalala]

Root cause

When an ownCloud-migrated group share (which has no per-user USERGROUP subshare) is renamed for the first time, DefaultShareProvider::move() inserts a new USERGROUP row without setting accepted. The column defaults to 0 (STATUS_PENDING), causing MountProvider to skip the share on the next request — the file disappears for the recipient.

Native Nextcloud group shares are unaffected because the accept flow always creates the USERGROUP subshare and immediately sets accepted = STATUS_ACCEPTED before the user can rename.

A second bug compounded this: SharedMount::moveMount() was catching exceptions from updateFileTarget() (e.g. Manager::moveShare() rejecting an orphaned group share because the original group no longer exists in Nextcloud) but always returning true. This caused View::rename() to believe the rename succeeded, update \$this->path to the new location, and then fail with HTTP 500 on refreshInfo() — making the file appear to vanish with no clean error.

Fixes

1. DefaultShareProvider::move() — set accepted = STATUS_ACCEPTED when inserting a new USERGROUP subshare on first rename, so MountProvider does not skip it on the next load.

2. SharedMount::moveMount() — set \$result = false in the catch block so rename failures propagate cleanly instead of corrupting virtual filesystem state. updateFileTarget() widened from private to protected to allow unit testing.

3. occ sharing:fix-owncloud-group-shares — opt-in repair command for instances that already hit the bug before this fix was deployed. Finds USERGROUP subshares stuck at STATUS_PENDING with non-zero permissions and restores them to STATUS_ACCEPTED. Supports --dry-run. Deliberately not an automatic repair step — admins should run this consciously, as shares that have been invisible for some time will reappear for recipients.

Tests

• DefaultShareProviderTest::testMoveGroupShare() — asserts STATUS_ACCEPTED after both first and second move (INSERT and UPDATE paths).
• SharedMountTest::testMoveOwncloudMigratedGroupShareRemainsVisibleAfterRename() — integration test simulating the full OC migration state: GROUP share with accepted = STATUS_ACCEPTED and no USERGROUP subshare; verifies the share is still visible after rename and re-login.
• SharedMountTest::testMoveMountReturnsFalseWhenUpdateFileTargetThrows() — unit test verifying moveMount() returns false when updateFileTarget() throws.
• FixOwncloudGroupSubshareStatusTest — covers fix, dry-run, declined shares (permissions=0), already-accepted shares, non-USERGROUP shares, and multiple rows.

Fixes: #59791

AI-Assisted-By: Claude Sonnet 4.6 noreply@anthropic.com

[provokateurin]

This should only be part of the migration and not available outside.

[provokateurin]

Are you sure this will only match those broken shares? There must not be any false positives.

[miaulalala]

I wanted to give admins the option to restore already broken shares. Some admins may not want to have that.

And yes, any oC share will have a permission other than 0 if it wasn't rejected. So only oC shares that were accepted but haven't had the update for the new column will be in that state.

[miaulalala]

@provokateurin re: "This should only be part of the migration and not available outside" - an automatic repair step would silently restore shares that recipients may not have seen for weeks or months. From their perspective, files would suddenly reappear with no explanation, which seems like the wrong default for instances that have been running in the broken state for a while.

The opt-in occ command means the admin consciously decides to restore the shares and can communicate the change to affected users beforehand. The --dry-run flag also lets them audit the scope before committing.

The actual root cause (missing accepted = STATUS_ACCEPTED on INSERT in DefaultShareProvider::move()) is fixed unconditionally, so new renames on already-migrated instances work correctly going forward without any manual intervention.