* feat: add backend validation for conflicting team slugs during org onboarding - Added findOwnedTeamsByUserId method to TeamRepository - Created buildTeamsAndInvites method in BaseOnboardingService that automatically: - Detects teams with same slug as organization - Marks conflicting teams for migration (isBeingMigrated: true) - Filters empty team names and invite emails - Updated BillingEnabledOrgOnboardingService to use new method - Updated SelfHostedOnboardingService to use new method - Added comprehensive tests for slug conflict scenarios This ensures backend validation even if frontend is bypassed, preventing slug conflicts during organization creation. All inheriting classes automatically get this validation without code changes. * refactor: use TeamRepository in listOwnedTeamsHandler Refactored listOwnedTeamsHandler to use TeamRepository.findOwnedTeamsByUserId instead of direct Prisma queries. This: - Reduces code duplication - Ensures consistency across the codebase - Follows repository pattern - Makes the handler more maintainable * fix: update tests to use renamed buildTeamsAndInvites method - Renamed testFilterTeamsAndInvites to testBuildTeamsAndInvites - Made test wrapper method async to match the async buildTeamsAndInvites - Added orgSlug parameter to all test calls - Updated all 9 test cases to use await with the new method signature - Fixed lint warnings by using proper types instead of 'any' - Imported OnboardingIntentResult and User types - Used Pick<User> for mockUser type - Removed all 'as any' type casts Fixes test failures where filterTeamsAndInvites was renamed to buildTeamsAndInvites in the base service. Co-Authored-By: hariom@cal.com <hariombalhara@gmail.com> * fix: mock TeamRepository in tests to prevent database calls Added vi.mock for TeamRepository to avoid database calls in unit tests. The buildTeamsAndInvites method now calls ensureConflictingSlugTeamIsMigrated which uses TeamRepository.findOwnedTeamsByUserId(). Mocking this prevents Prisma errors in CI while keeping the tests focused on filtering logic. The mock returns an empty array so no teams are found for migration, allowing the tests to verify the filtering behavior without database access. Co-Authored-By: hariom@cal.com <hariombalhara@gmail.com> * refactor: improve readability of ensureConflictingSlugTeamIsMigrated Refactored the conditional logic in ensureConflictingSlugTeamIsMigrated for better readability while preserving exact behavior. Changed from manual array manipulation to using .map() for updating team migration status. This is a cosmetic change with no functional differences. Co-Authored-By: hariom@cal.com <hariombalhara@gmail.com> --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Co-authored-by: Udit Takkar <53316345+Udit-takkar@users.noreply.github.com>
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.