fix(recording): store recordings and transcripts as the owning user

[bakiburakogun]

Fixes #19077

Summary

Call recordings are stored through POST /ocs/v2.php/apps/spreed/api/v1/recording/{token}/store, which is a #[PublicPage] endpoint authenticated with the recording shared secret only. There is no active user during that request, so when RecordingService::store() writes the file the activity subsystem cannot resolve an actor and falls back to an empty one. The Files activity provider renders that as "remote account", so users see

"remote account" created Recording 2026-08-23 23-23-09.mp4

instead of their own name, even though the file is in their own recording folder.

This sets the owner as active user while the file is created and restores the previous user afterwards, so the file events and the resulting activity are attributed to them. The same helper is used for the transcript and summary files written in storeTranscript(), which have the same problem.

Notes

• The owner parameter that the recording backend sends is already validated in store() (getParticipant() throws owner_participant for an unknown owner), the helper additionally falls back to the previous behaviour if the user cannot be loaded.
• The active user is restored in a finally block, so a failing write cannot leak the session user into the rest of the request.
• Sharing the recording to the chat is unaffected, that path already posts with the participant actor.

Testing

Reproduced on Nextcloud 34.0.3 with Talk 24.0.4 and nextcloud-talk-recording 0.2.1 (four node signaling cluster). The patch is being rolled out on that instance now and I will confirm here once a recording has been stored with it.

[bakiburakogun]

Deployed on the instance from the report (Nextcloud 34.0.3, Talk 24.0.4, nextcloud-talk-recording 0.2.1) and recorded a call with it.

The activity entry for the new recording now reads You created Recording 2026-08-24 00-02-34.mp4, while the recordings stored before the patch still show "remote account" created .... The file, the "recording available" notification and sharing it to the chat behave as before.

[bakiburakogun]

Pushed a follow-up commit.

After running the first version on the instance from the report, the recordings themselves are attributed correctly, but the activity stream still shows an entry like

"remote account" created Recording 2026-08-24 13-55-16.mp4 and <conversation token>

for the first recording of a conversation. The reason is that getRecordingFolder() creates the attachment folder and the per-conversation folder with newFolder() outside of the user context that newFileAsUser() sets up, so the folder creation is still attributed to nobody.

The new commit moves the user switch into a small runAsUser() helper and uses it for the folder lookup as well, so the folder and the file end up with the same actor. No behaviour changes beyond the attribution.

[bakiburakogun]

Verified on the instance from the report (Nextcloud 34.0.3, Talk 24.0.4, nextcloud-talk-recording 0.2.1, four signaling servers, seven application servers).

Recorded a call in a conversation that had never been recorded before, so the per-conversation folder was created as part of storing the recording. The activity stream now attributes both the folder and the .mp4 to the user who started the recording. Before this commit the same case produced a single entry reading "remote account" created Recording ....mp4 and <conversation token>, with the file and the folder both unattributed.

Recording, the "recording available" notification and sharing it into the chat behave as before.

[nickvergessen]

I'm not sure it's the best idea to overwrite the session user like this.
Also it's not going to work on the new chunked-uploading of recordings we implemented recently.

I think instead we need work in the activity app to allow defining different actors:
https://github.com/nextcloud/activity/blob/f95186c14cb89cb8e9f7f367e9ac394b2c398c50/lib/CurrentUser.php#L35

The activity manager has code for this already: https://github.com/nextcloud/server/blob/1ab09ec753f106661beadee1794b390ebec455dd/lib/private/Activity/Manager.php#L346-L354
but it's not used in the activity app itself. I think CurrentUser should first check IManager::getCurrentUserId() that would allow Talk to overwrite the user for the action

[nickvergessen]

As per comment