feat(flags): UX for feature flag dependencies#35284
Conversation
Adds a PropertyFilterType of FlagDependency (`flag`) and a property type of `Flag`
Also add a router for the new endpoint.
And related infrastructure
When a flag has multiple variants, we want to explain what `true` and `false` mean.
Prevent feature flags from creating circular dependencies when one flag depends on another. This validation runs at the API layer when creating or updating feature flags with flag dependencies. - Add _check_flag_circular_dependencies method to detect cycles - Integrate validation into validate_filters for flag properties - Handle different property key formats ($feature/, $feature_flag/, plain) - Add comprehensive tests for direct and indirect cycles - Gracefully handle missing/deleted flag dependencies Fixes #29016
- Add PropertyDefinitionType.FlagValue mapping to EventFeatureFlags in PropertiesTable - Change groupTypeIndex from null to undefined in PropertyValue tests - Remove unused React import and add type annotations in test-boolean-preservation - Add PropertyFilterType.FlagDependency to TaxonomicFilterGroupType mapping - Fix appropriateGroups reference to use filterGroups in featureFlagReleaseConditionsLogic - Add proper type annotations for FeatureFlagGroupType and AnyPropertyFilter
Update error messages in test_validation_person_properties to reflect that flag properties are now allowed in feature flag filters
Spread featureFlagOperatorMap last so its operators take precedence over others, ensuring that flag dependencies show 'evaluates to' instead of 'equals'.
And document why we do it.
|
One of the decisions I made early was to make a flag dependency have a filter type of But now that I'm building the UI, I'm having to special case a lot to because we want It's kind of a big change but I'm thinking I should add a new operator, but I'd love some other opinions. |
📸 UI snapshots have been updated14 snapshot changes in total. 0 added, 14 modified, 0 deleted:
Triggered by this commit. |
haacked
force-pushed
the
haacked/29016-flag-dependencies-ux
branch
from
858cce3 to
dace5dd
Compare
📸 UI snapshots have been updated16 snapshot changes in total. 0 added, 16 modified, 0 deleted:
Triggered by this commit. |
📸 UI snapshots have been updated2 snapshot changes in total. 0 added, 2 modified, 0 deleted:
Triggered by this commit. |
Implements standalone API endpoint that returns possible values for feature flags:
- Boolean flags return [true, false]
- Multivariate flags return [true, false] + variant keys
- Endpoint: /api/projects/{project_id}/flag_value/values?key={flag_id}
- Includes comprehensive test coverage and error handling
- Enables frontend flag dependency selection UI
Extracted from PR #35284 as independent deployable component.
|
This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the |
2 participants
See demo video:
https://www.loom.com/share/9e1213bdd7094274915bb8b6f9f83205?sid=a908b8f7-6a2d-4e8f-a7bf-86e3217d592b
Important
👉 Stay up-to-date with PostHog coding conventions for a smoother review.
Problem
We want to be able to have flags that depend on the evaluation of other flags.
Fixes #29016
Changes
flagfilter property typeDid you write or update any docs for this change?
How did you test this code?
Manual testing.