[Feature Request] Allow conditions as prerequisites to features

[taylorsmithgg]

Having conditional arguments in flags would help to provide a more modular approach to complex feature flags.

For example:
IF Feature A is enabled -> Evaluate Feature B

[dabeeeenster]

We've discussed this a lot internally but feel that this is better suited in code than in Flagsmith itself. Happy to hear arguements for why this should not be the case however!

[taylorsmithgg]

TLDR would be that tying up extensive business logic in the (self-managed) edge with flagging is much more cumbersome than being able to configure it directly through the API or browser.

It also requires redeployments, potential breaking changes, introduces parsing issues etc.
Overall significantly more risk than being able to route dynamically based on conditions that are verified by the API rather than left to if statements.

[dabeeeenster]

Do you have a concrete use case?

[taylorsmithgg]

I do!

In my case, there are customers that may have a larger set of feature flags that are prerequisites to other flags.

My most basic example would be the use of a permanent beta flag that then allows us to add experimental options based on a domain.

In more advanced cases, we may have a certain classification of customer that we could utilize traits and segments for, but would want to also only apply a subset of those beta flags.

While this is all achievable through if statements in our edge routing, we end up having to maintain quite a bit of code and complexity to analyze it correctly, and it takes significantly longer to add the individual flags and modify the code reliably without the mapping between them.

[dabeeeenster]

Thanks @taylorsmithgg - helpful!

Would you expect dependencies to be based purely on the boolean state of the flag, as opposed to any textual value?

[kyle-ssg]

I do!

In my case, there are customers that may have a larger set of feature flags that are prerequisites to other flags.

My most basic example would be the use of a permanent beta flag that then allows us to add experimental options based on a domain.

I'd be interested to understand why this wouldn't be achieved by having a beta segment and segment overrides for the flags that you want to manage. I've had this use case a lot on different apps (Including Flagsmith itself) and it always seemed to work great via segment overrides, but perhaps something in your scenario makes this approach not suitable.

[dabeeeenster]

Ah yes - this would be a great place to put these new models in the UI. Rename Segment Overrides to just Overrides and allow the user to select a flag directly

[dabeeeenster]

As a rough outline for a set of requirements:

• Create a new model object: feature_depends_on that has a parent_flag and child_flag at the Project level.
• Dependencies operate only on the boolean flag state - for v1 of the feature I don't think we should consider flag values.
• A flag with dependencies on other flags will only evaluate to true if:
  • All the flag's parent dependencies evaluate to true
  • The value of the flag itself is set to true
• A flag can have multiple dependencies
• Checks will need to be made when creating or updating dependencies that no circular dendencies created
• The core Flag Engine, Environment Document and all related SDKs will need updating to include this new entity and rules
• Dependencies would be a top level nav item alongside Segments