mirror of
https://github.com/suitenumerique/meet.git
synced 2026-10-15 17:32:59 +00:00
lebaudantoine
ab6e58ecae
Any authenticated participant can now start a recording on trusted and public rooms. This is essential, requested by many users, and should encourage people to authenticate on public rooms. It also means the starter may hold no role on the room, so who gets access to the recording has to be decided explicitly. The part open to discussion is the recording access: who should be owner/admin on the recording. This commit picks the simplest design: * The room's owners and administrators get an `OWNER` `RecordingAccess`: they can retrieve, download, stop and delete the recording. * The starter gets a `MEMBER` `RecordingAccess`, unless they already own or administer the room, in which case they get `OWNER`. A member can retrieve and download the recording but cannot delete it: deletion is irreversible and affects everyone with access, so it stays with the people responsible for the room. * Everyone with an access, members included, receives the "recording ready" email. * Room roles are copied when the recording starts: later changes to the room's accesses do not affect existing recordings. The people responsible for a meeting should control its recording and transcript, and whoever initiated it should be able to access it on their own. The starter owns the output and is responsible for sharing it with their colleagues. Recording members could not retrieve a recording before this commit. No code path created such accesses until now, but one added manually through the admin now grants read access. One constraint is respected: the summary service creates a doc, and the docs API can only attribute it to a single owner. The summary therefore goes to the oldest access, and the starter's access is created before the room owners/admins ones, so the starter receives it. The lookup does not filter on role, since the starter may only be a member. The previous lookup took `.first()` with the default newest-first ordering, which with several owners would have picked a room admin. Alternatives considered: * Granting access to every participant allowed to record, or to those present when the recording starts: it requires listing participants from LiveKit and creating an access for each, and widens access by default, for a need no user has expressed. * A `creator` attribute on the recording row: it only adds a migration without adding value to access control, so it was dropped. * Restricting access to the link owner even when someone else starts the recording: some organizations may want this for security reasons, but it is YAGNI until a few large clients ask for it. I think we should contribute to Docs' api to allow sharing the transcription document with several users.