Hariom BalharaandGitHub
a056c3217e
## What does this PR do? Adds infrastructure to track impersonation context in booking audit records and displays it in the UI. When an admin impersonates another user and performs booking actions, the audit system now: - Records the **admin** as the actor (who actually performed the action) - Stores the **impersonated user's UUID** in a separate `context` field - Displays **"Impersonated By"** in the booking logs UI when viewing audit details This separation ensures audit trail integrity (the admin is accountable) while preserving full context about whose account was being used. ### Changes - Added `uuid` to `impersonatedBy` session object for actor identification - Added `uuid` to top-level `User` type in next-auth types for session enrichment - Added `context Json?` field to `BookingAudit` Prisma model - Added `BookingAuditContextSchema` for type-safe context handling with `actingAsUserUuid` field - Updated producer service interface and implementation to pass context through all queue methods - Updated consumer service to persist context to database - Updated repository to store and fetch context in BookingAudit records - Added `impersonatedBy` field to `EnrichedAuditLog` type in `BookingAuditViewerService` - Added `enrichImpersonationContext` method to resolve impersonated user details - Updated booking logs UI to display "Impersonated By" in expanded details - Added `impersonated_by` translation key Link to Devin run: https://app.devin.ai/sessions/3f1252527aef4ead9401bdf055c0817b Requested by: hariom@cal.com (@hariombalhara) ## Mandatory Tasks (DO NOT REMOVE) - [x] I have self-reviewed the code (A decent size PR without self-review might be rejected). - [x] I have updated the developer docs in /docs if this PR makes changes that would require a [documentation change](https://cal.com/docs). N/A - internal infrastructure change - [ ] I confirm automated tests are in place that prove my fix is effective or that my feature works. ## How should this be tested? 1. Verify type checks pass: `yarn type-check:ci --force` 2. Verify existing audit tests still pass: `TZ=UTC yarn test` 3. To fully test impersonation context display: - Have an admin impersonate a user - Perform a booking action (create, cancel, reschedule) - Navigate to the booking's audit logs - Expand the details for the action - Verify "Impersonated By" row appears showing the impersonated user's name - Verify the BookingAudit record has: - `actorId` pointing to the admin's AuditActor - `context` containing `{ actingAsUserUuid: "<impersonated-user-uuid>" }` ## Human Review Checklist - [ ] Verify the `context` field schema design is appropriate for future extensibility - [ ] Confirm the `uuid` addition to User type in next-auth doesn't break existing auth flows - [ ] Check that the optional `context` parameter doesn't break existing queue method callers - [ ] Verify no migration file is needed (or if squashing is handled separately) - [ ] Verify the UI displays "Impersonated By" correctly when impersonation context is present - [ ] Confirm `enrichImpersonationContext` handles edge cases (null context, invalid context, deleted user) ## Checklist - [x] My code follows the style guidelines of this project - [x] I have commented my code, particularly in hard-to-understand areas - [x] I have checked if my changes generate no new warnings
Enterprise Edition
Welcome to the Enterprise Edition ("/ee") of Cal.com.
The /ee subfolder is the place for all the Enterprise Edition features from our hosted plan and enterprise-grade features for Enterprise such as SSO, SAML, OIDC, SCIM, SIEM and much more or Platform plan to build a marketplace.
❗ WARNING: This repository is copyrighted (unlike our main repo). You are not allowed to use this code to host your own version of app.cal.com without obtaining a proper license first❗
Setting up Stripe
- Create a stripe account or use an existing one. For testing, you should use all stripe dashboard functions with the Test-Mode toggle in the top right activated.
- Open Stripe ApiKeys save the token starting with
pk_...toNEXT_PUBLIC_STRIPE_PUBLIC_KEYandsk_...toSTRIPE_PRIVATE_KEYin the .env file. - Open Stripe Connect Settings and activate OAuth for Standard Accounts
- Add
<CALENDSO URL>/api/integrations/stripepayment/callbackas redirect URL. - Copy your client*id (
ca*...) toSTRIPE_CLIENT_IDin the .env file. - Open Stripe Webhooks and add
<CALENDSO URL>/api/integrations/stripepayment/webhookas webhook for connected applications. - Select all
payment_intentevents for the webhook. - Copy the webhook secret (
whsec_...) toSTRIPE_WEBHOOK_SECRETin the .env file.
Setting up SAML login
- Set SAML_DATABASE_URL to a postgres database. Please use a different database than the main Cal instance since the migrations are separate for this database. For example
postgresql://postgres:@localhost:5450/cal-saml - Set SAML_ADMINS to a comma separated list of admin emails from where the SAML metadata can be uploaded and configured.
- Create a SAML application with your Identity Provider (IdP) using the instructions here - SAML Setup
- Remember to configure access to the IdP SAML app for all your users (who need access to Cal).
- You will need the XML metadata from your IdP later, so keep it accessible.
- Log in to one of the admin accounts configured in SAML_ADMINS and then navigate to Settings -> Security.
- You should see a SAML configuration section, copy and paste the XML metadata from step 5 and click on Save.
- Your provisioned users can now log into Cal using SAML.