Multivariate flags UI

[samwinslow]

Changes

Contributes to #5440. Adds a UI in PostHog for configuring multivariate feature flags.

Notes

• This feature itself is feature-flagged behind 5440-multivariate-support
• Client-side library support (i.e. our JS and Python consumers) is not yet available, so this is just a UI for updating feature flag records in the database.
• This will be tested internally for Growth projects before any kind of public release

The feature flag rollout page:

Validations:

Distribute evenly (handling remainders from integer rounding):

Data loss warning if switching from variants to Boolean (default) behavior:

Checklist

• All querysets/queries filter by Organization, by Team, and by User
• Django backend tests
• Jest frontend tests
• Cypress end-to-end tests
• Migrations are safe to run at scale (e.g. PostHog Cloud) – present proof if not obvious
• New/changed UI is decent on smartphones (viewport width around 360px)

[mariusandra]

Hey, apologies this took long to review, but I think this looks good! Approved, but with two comments. See if they make sense to address.

1. As one small change, I'd still add the PR or issue ID inside the feature flag, like the other ones have.
2. As one bigger change, it would be cool if you would limit the multivariate sliders so that none can be dragged such that the total is over 100%.

[samwinslow]

Thank you @mariusandra! Regarding the sliders — TL;DR I had considered doing that, but felt it would arbitrarily limit the user.

Consider some example percentages are [50%, 50%]
User wants to adjust them to [70%, 30%]

Preventing the total from exceeding 100, even temporarily, would force the user to decrease the rollout of one to 30% before increasing the other to 70% (forcing an order of operations).

But this intermediate value of (50 + 30) = 80% is just as incorrect as an intermediate value of (70 + 50) = 120% as the final allocation must sum to exactly 100.

[mariusandra]

Makes sense and agreed, that proposal is also not ideal, and ultimately not better than what's in the PR.

cc @clarkus for thoughts.

[paolodamico]

Just wanted to provide some quick late feedback here. I think we can make the "Boolean" & "String variant" labels clearer for a less technical audience.

[clarkus]

Circling back here to review - I think this is a good v1 especially with the notes @mariusandra and @paolodamico added. The boolean and string options could have some inline tooltips to explain them to less technical audiences or we could change the nomenclature to "true / false" or "text". Whatever we do here should probably align with any data types we expose in the rest of the product.

Sliders are a really challenging component to use for users and a challenging one to validate for engineers. It really comes down to implementation and how accurate a user can be with their input. The input fields here that capture the value are a good idea - you can skip sliders altogether and just type in your distribution.