fix: preserve link shares on ownership transfer

[salmart-dev]

• Resolves: [Bug]: Public shares get deleted after ownership transfer #60223

Summary

This PR fixes an issue on file ownership transfer, which causes link and email shares to be incorrectly dropped.

Link and email shares get their parent database column set when they come from a reshare, this is used to delete them once the parent share is deleted. During transfer, all shares related to the transferred content are collected and are, in some cases, deleted. The delete triggers the cascade-delete of link and email shares, so they are effectively lost. This PR sets the parent column of the affected shares to null before the main share is deleted, so that the subsequent handling of those shares updates the owner to the user receiving the transfer.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[salmart-dev]

/backport to stable35

[salmart-dev]

/backport to stable34

[salmart-dev]

/backport to stable33

[salmart-dev]

/backport to stable32

[salmart-dev]

Test failures are unrelated, both should be caused by #53048, the psalm one has already been addressed, but the issue with the non-cleared cache is not yet.

[provokateurin]

I'm not sure if this is correct. As far as I understand the parent share is not actually deleted, but transferred, so you're changing the share without it being necessary.

Doesn't this mean, we have to change the order in which shares are transferred? The ones that are the most deeply nested first and the root last, so that deleting the "old" shares doesn't unintentionally delete any shares.

[salmart-dev]

I'm not sure if this is correct. As far as I understand the parent share is not actually deleted, but transferred, so you're changing the share without it being necessary.

Shares are not all transferred. The code is dropping the following redundant share rows:

1. user shares created by the user receiving the transfer targeting the source user as share-receiver. In this case links that the source user had created are incorrectly dropped.
2. shares for nodes the receiving user had already access to through other shares. In this case, which share row is removed depends on permissions, and in any case the share entry of the receiver or of the source is deleted. Also here links may be dropped dropped if the deleted share was a parent for those links.
3. shares for nodes the destination user owns. Since the receiving user owns the nodes, it makes no sense to transfer the share, so it is deleted. Link shares that the source had created get deleted as a consequence.

So in all those cases a share entry is being dropped and, due to the fact that link and email oc_share entries can carry a parent ID, results in their removal once the parent share gets deleted. The update query targets only link/email shares and uses the ID of the parent row which is about to be deleted, so nothing that would not be immediately deleted is being modified.

I did miss the fact that we should re-parent links in the case where the user receiving the transfer already has received shares for the same node, is this what you meant? I added a commit to address that.

[provokateurin]

I did miss the fact that we should re-parent links in the case where the user receiving the transfer already has received shares for the same node, is this what you meant?

Yes, that was mostly my concern.