Skip to content

Feature-Flag: feature toggle system for controlled rollout #790

@vprashrex

Description

@vprashrex

Is your feature request related to a problem?
Currently, Assessment endpoints are accessible without a centralized feature toggle that is aware of tenants. This inconsistency complicates the process of enabling or disabling features for specific organizations or projects.

Describe the solution you'd like

  • Implement a persistent feature-flag system scoped by organization_id and optional project_id.
  • Choose a DB-based approach to include CRUD APIs for feature flag management, or expose management APIs with a /features endpoint if using a context-manager/provider approach.
  • Introduce a reusable require_feature(...) dependency for route gating.
  • Protect Assessment routes with an ASSESSMENT flag using dependency injection from fastapi that requires permission.
  • Return enabled features in /users/me for frontend access at the auth context level.
    Constraint: The solution must be open-source and free, preferably using a DB-native/Postgres approach.

Why is this enhancement needed?
This enhancement facilitates controlled, tenant-aware feature rollouts without global releases, enhances usability for admins managing feature access, improves maintainability with a single gating pattern, and supports scalability for phased rollouts and future expansion across multiple organizations and projects.

Original issue

Describe the current behavior
A clear description of how it currently works and what the limitations are.
Assessment endpoints are available without a centralized, tenant-aware feature toggle. There is no consistent way to enable/disable Assessment per organization or project, and rollout control is limited. This makes controlled access difficult.

Describe the enhancement you'd like
A clear and concise description of the improvement you want to see.

  1. Add a persistent feature-flag system scoped by organization_id and optional project_id.
  2. we choose the DB-based approach, include CRUD APIs for feature flag management; if we choose a context-manager/provider approach, expose equivalent management APIs and a /features endpoint that returns resolved flags for the client context.
  3. Add reusable require_feature(...) dependency for route gating.
  4. Protect Assessment routes with ASSESSMENT flag using dependency injection from fastapi that requires permission.
  5. Return enabled features in /users/me so that frontend can get this information at the auth context level.
    Constraint: solution must be open-source and free (prefer DB-native/Postgres approach).

Why is this enhancement needed?
Explain the benefits (e.g., performance, usability, maintainability, scalability).
This enhancement is needed to enable controlled, tenant-aware feature rollout (organization_id/project_id) without risky global releases. It improves usability by giving admins clear control over who gets which features, improves maintainability through a single reusable gating pattern, and improves scalability by supporting phased rollouts, safer rollbacks, and future growth across multiple orgs/projects.

Additional context
Add any other context, metrics, screenshots, or examples about the enhancement here.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Projects

Status

In Review

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions