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.
Installation
If you want to install La Suite Meet you've come to the right place. Here are a bunch of resources to help you install the project.
Kubernetes
La Suite Meet maintainers use only the Kubernetes deployment method in production, so advanced support is available exclusively for this setup. Please follow the instructions provided here.
Docker Compose
We understand that not everyone has a Kubernetes cluster available, please follow the instructions provided here to set up a docker compose instance. We also provide Docker images that can be deployed using Compose.
Scalingo
La Suite Meet can be deployed on Scalingo PaaS using the Suite Numérique buildpack. See the Scalingo deployment guide for detailed instructions.
Other ways to install La Suite Meet
Community members have contributed alternative ways to install La Suite Meet 🙏. While maintainers may not provide direct support, we help keep these instructions up to date, and you can reach out to contributors or the community for assistance.
Here is the list of other methods in alphabetical order:
Tip
Feel free to make a PR to add ones that are not listed above
Cloud providers
Currently, no cloud providers are listed for deploying La Suite Meet.
Tip
Feel free to make a PR to add ones that are not listed above