Skip to main content

Auth and Access

Right Events uses Convex Auth as the core identity layer and extends it with platform-specific roles, workspaces, organizations, and capability checks.

Supported sign-in methods​

The current auth configuration in convex/auth.ts supports:

  • email OTP
  • email magic links
  • Google OAuth when Google credentials are configured
  • Apple OAuth when Apple credentials are configured

Email auth behavior​

The auth layer does more than send a code:

  • sign-in checks that an account already exists
  • sign-up checks that an account does not already exist
  • suspended accounts are blocked from email sign-in

This reduces the usual ambiguity around OTP flows and keeps account state aligned with the platform user model.

User model extensions​

The users table extends auth state with:

  • name and profile fields
  • organization and workspace links
  • badges and verification fields
  • country, currency, and timezone
  • role and status metadata

Authorization patterns​

There are two major authorization styles in the repo:

Role or ownership checks​

Used in feature-specific flows where access is tightly scoped to an organization, event, or resource owner.

Capability checks​

Used for platform-level admin and privileged workflows through requireCapability() from convex/permissions.ts.

Team and workspace access​

Right Events supports:

  • organizations
  • workspaces
  • organization team members
  • workspace members
  • ownership transfer flows

This means user access is not just global role based. A user can be invited into specific operational contexts and receive narrower permissions.

Practical guidance for new code​

  • Use the existing current-user helpers from convex/users.ts.
  • Prefer capability checks for admin or system-level privileges.
  • Use typed IDs and explicit ownership checks for event or organization-specific resources.
  • Do not hardcode new role strings without understanding whether the flow should be capability based instead.