Add Sentry observability to the `agents`. Introduce a dedicated
`observability.py` module. Refactor both agents to use the shared
observability layer and extract task helpers into a new `tasks.py` module,
making task execution easier to instrument and maintain.
This commit introduces the compatibility with summary v2.
It tecnically doesn't break the compatibility with v1 as
v1 params are still sent. But we advise people using the
transcribe feature in their own deployments to adapt to the
new v2 API, as this compatibility will be removed in a
future major version.
* RecordingStatusChoices now has
EXTERNAL_PROCESS_SUCCESSFUL
& EXTERNAL_PROCESS_FAILED
Values, which are changed by a new webhook that
can be called by the transcribe service.
This webhook is protected by its own bearer token.
* Title for the document is computed in visio,
* Tests are added / updated accordingly
This commit cleans up most of the code related to v1 route that
is used only by visio.
This is first step before introducing an update to the v2 route.
Passing a list of hosts in the ingress was broken: the template
helpers were called with the current loop context (`.`) instead of
the root context (`$`), so the service name was rendered incorrectly
inside the hosts loop.
Updates the help chart to be able to run a list of CronJobs.
By defaults it runs the clean_pending_files
and purge_deleted_files commands during the night.
A previous CSP change suggested by CodeRabbit was not properly
tested and broke inline styling as well as the loading of the
ProConnect image.
Adjust the CSP directives to allow these resources again.
The CSP was missing a default-src directive (flagged by CodeRabbit).
Without it, styles, images, fonts, and media are completely
unrestricted, which undercuts the otherwise strict policy.
Set default-src to 'self' and add an explicit style-src directive
since we rely on inline styles (e.g. #close-msg and the view
toggling use inline style attributes), so style-src needs to allow
'self' and 'unsafe-inline'.
Mount the nginx configuration used by the frontend image as a volume
so the default one can be overridden by a custom configuration at
deployment time.
Based on suggestions from @rouja to help parametrize the
configuration at deployment time.
Add the possibility to display a feedback form link in the footer to
help collect feedback from the first users of the plugin.
Once the plugin is in production at scale, this will be replaced
with a link to the support page.
Offer the possibility to append a query parameter at the end of the
meeting URL to flag links created from the Outlook plugin, inspired
by Zoom.
The behavior is toggled via an environment variable.
Refactor the plugin to support internationalization and ship it in
three languages.
Internationalizing requires updating the manifest, which involves
touching the Helm chart and releasing a new version. Ship a beta
version of the plugin once the i18n work is done to bundle these
changes together.
In the ribbon, the "create a meeting link" action was displayed with
the generic add icon, which is fitting in the context of a menu but
not explicit enough on its own.
Following feedback from the social ministries, replace the add icon
with the app logo to make it clear that this button creates a
videoconference link.
Introduce a Kubernetes job to run the `merge_duplicate_users`
management command on the backend, as suggested by @rouja.
This provides a standard and reproducible way to execute the user merge
process in deployed environments without requiring manual access to
application containers.
The job can be used alongside the command's dry-run mode to validate
the impact of a merge operation before applying changes.
Align enabled/disabled mature features across the dev environments.
Also reorganize backend env variables with a clearer scope and add
comments that help understand the responsibility of each setting and
why it exists.
Maintaining the two dev stacks is a nightmare. Start factorizing them
to make sure they stay updated easily, and to highlight differences
between the two at a glance.
The securityContext and podSecurityContext were harming hot reloading
on the dev stack. The file permission system prevented source updates
because the user running the image was not root.
Udate the helm chart to support multiple transcribe worker in
the summary service.
This is useful when using multiple WhisperX instances to have one deployment
for each endpoint. This enables some kind of horizontal scaling (we still
keep one call per WhisperX endpoint but can have multiple WhisperX endpoints)
Provide the minimal components required to support an Outlook
add-in: user authentication, JWT retrieval, and API calls to
generate meeting links.
This implementation is an early alpha: developer experience is
limited, documentation is incomplete, and the solution is not
white-labeled.
It's too early to consider these parts ready to ship into
production.
As a result, it is currently only available within the DINUM
frontend image.
This commit aim at adding a securityContext for
pod and container in Deployment and Job,
it include livekit pods as well
It adds 2 values :
- podSecurityContext : for pods
- securityContext : for containers
Please note that `celeryBackend` Deployment does
not have any values defined in `values.meet.yaml` at the moment.
Updated taskV2 API contract to be closer to the target gateway contract.
GET operations return the same things as the webhook payload.
Also store the summary on S3 to be iso with transcript.
Add multitenancy support to Summary sub-app. The V1 routes / tasks
behave like before, with the default tenant being "meet".
V2 routes / tasks support being called frm any tenant, and don't have
meet related logic.
V2 tasks are created in separate queues to avoid mix / match,i
Reduce duplication by introducing YAML anchors for configurations
shared across multiple services.
Most settings were nearly identical across the three summary
services, making them easier to maintain and update.
The dev values are no longer in use and have not been used for over a year.
We primarily rely on the dev-keycloak values, and occasionally
the dev-dinum ones for testing on the Dinum-labeled frontend.
As a result, the unused dev values should be removed to reduce clutter
and simplify maintenance.
InitialDelaySeconds was set to 30s which caused the tilt stack
startup to be very slow. In this commit I split the initial delay
and the period arg.
5s seems to be relevant given the nature of the app.
With the introduction of file background uploads, only trigger the
webhook for files related to recordings.
Avoid firing the "recording saved" event for other file uploads,
preventing unnecessary queries and false triggers.
Migrate main meet app to use UV for dependancy management.
Also optimized the backend image build sequence for faster rebuilds
when dependencies don't change.
Also removed compiled django translations files are they are done in the build
process now.
Changes inspired by drive repo.
The wrong port was configured, causing CORS issues
when uploading files directly to the MinIO bucket.
Port 9001 is reserved for the MinIO console;
use the correct API port instead.
* Add a simple celery-backend deployment to helm chart, which
uses the same docker image as the backend, and runs a single
worker.
* Update dev keycloack values accordingly
* Update Tiltfile to properly set service dependencies
* Update minio deployment to increase the default max body size limit
(relevant to uploading files)
Add media_files_svc and ingress_media_files to helm chart
for serving medias related to the new files.
This setup is more straightforward than merging the
existing recording related media ones.
Also updated values to enable file upload by default in dev.
Mostly done by @lebaudantoine.
For the coming features we will need to store files on the meet side.
(for instance user backgrounds).
This commits adds a new Model to manage files, and the associated
serializers & viewsets. All are tested.
This work was heavily inspired by the work done by our friends at
https://github.com/suitenumerique/drive
It build on the same architecture design (upload directly to S3 but
download goes through our proxy), but model is much much simplier
(no folders, no file sharing, etc.).
Create a separate Ingress resource to isolate traffic targeting the
webhook-livekit endpoint and allow applying specific NGINX
annotations to this route.
Use an exact path match to take precedence over the default /api
regex rule defined in the base Ingress.
No similar change is made for the S3 webhook endpoint, as this
dependency will be removed from the project.
leo