Feature/pro user role

[ferdinandl007]

Description

Adds the new pro_user role (aligned with Sportradar naming) and wires it through backend and frontend:

• Backend
  • Introduces UserRole.PRO_USER = "pro_user".
  • New env var DEFAULT_NEW_USER_ROLE to choose the default role for newly created users (basic or pro_user). Falls back to basic when unset/invalid.
  • Applies default role on both password signup and OAuth creation paths while preserving existing elevation rules:
    • First user or users in get_default_admin_user_emails() are still created as admin.
• Frontend
  • Adds PRO_USER to UserRole and labels.
  • Gates model selection (LLM picker and default-model user setting) to admin and pro_user. basic remains restricted.

Notes:

• No DB migration needed (role is stored as string; native enums already removed).
• No admin capabilities granted to pro_user; it only unlocks premium features (e.g., model selection).

How Has This Been Tested?

• Config defaults
  • Without DEFAULT_NEW_USER_ROLE set, created users default to basic (unless first/seeded admin).
• Default to pro user
  • Set DEFAULT_NEW_USER_ROLE=pro_user.
  • Signed up a new user: role was pro_user.
  • Confirmed first-ever user and any email in default-admin list are still created as admin.
• Frontend gating
  • Logged in as basic: LLM popover and default-model selector are hidden.
  • Logged in as pro_user: LLM popover and default-model selector are visible and functional.
  • Logged in as admin: unchanged behavior; controls visible and functional.
• Regression
  • Existing users retained their roles; no change to admin/curator flows.
  • Admin/user management endpoints continue to return/accept roles including pro_user.

Backporting (check the box to trigger backport action)

• This PR should be backported (make sure to check that the backport attempt succeeds)
• [Optional] Override Linear Check

---

Summary by cubic

Adds a new pro_user role and connects it across backend and frontend. Lets you default new signups to pro_user and unlock model selection for admin and pro_user.

• New Features

  • Backend: adds UserRole.PRO_USER and DEFAULT_NEW_USER_ROLE env var (basic or pro_user; falls back to basic). Applied on both password and OAuth signup. First user and whitelisted emails still become admin.
  • Frontend: model picker (LLM popover) and default-model setting are visible only to admin and pro_user; basic stays restricted.
  • Types/labels updated for the new role. Existing users keep their roles.

• Migration

  • Optional: set DEFAULT_NEW_USER_ROLE=pro_user to make new users pro by default.
  • No database migration required.

[vercel]

Someone is attempting to deploy a commit to the Danswer Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

Greptile Summary

This PR introduces a new PRO_USER role to implement a tiered user system with role-based access control for premium features. The changes span both backend and frontend components to create a middle tier between basic users and administrators.

Backend Changes:

• Adds UserRole.PRO_USER = "pro_user" to the authentication schemas and user management system
• Introduces a new environment variable DEFAULT_NEW_USER_ROLE that allows administrators to configure whether new users default to basic or pro_user roles
• Modifies user creation logic in both password signup and OAuth flows to use the configured default role while preserving existing admin elevation rules (first user and users in get_default_admin_user_emails() still become admins)
• Implements proper fallback handling that defaults to BASIC role when the environment variable is unset or contains invalid values

Frontend Changes:

• Adds PRO_USER to the UserRole enum and corresponding display labels in the type definitions
• Implements role-based gating for premium features, specifically restricting LLM model selection capabilities to users with ADMIN or PRO_USER roles
• Updates multiple UI components including ChatInputBar, RegenerateOption, and UserSettingsModal to conditionally render model selection features based on user role
• Uses conditional rendering to completely hide restricted features from basic users rather than just disabling them

The implementation follows the existing codebase patterns for role-based access control and maintains backward compatibility. The PRO_USER role provides access to premium features like model selection without granting administrative capabilities, creating a clear value differentiation between user tiers. No database migration is required since roles are stored as strings and native enums were already removed from the system.

Confidence score: 4/5

• This PR introduces new functionality with proper role-based gating but has some areas that could be refined
• Score reflects well-structured implementation with comprehensive testing coverage but includes broad exception handling that could be more specific
• Pay close attention to exception handling in app_configs.py and ensure OAuth flow role assignment logic is thoroughly tested

_{8 files reviewed, 1 comment}

_{Edit Code Review Bot Settings | Greptile}

[cubic-dev-ai]

2 issues found across 8 files

_{React with 👍 or 👎 to teach cubic. You can also tag @cubic-dev-ai to give feedback, ask questions, or re-run the review.}