Allow "Default Rolluot" for Boolean to be false

[PlkMarudny]

Problem

It is a cosmetic issue maybe, but I would prefer to have bool flags to be set to 'false' by default and just enable them gradually, so whoever is not granted a feature it has is disabled. A new feature will be disabled until enabled then, this type of logic.

Ideal Solution

Allow to change the values of the "Default Rollout" for boolean flags from true to false.

Search

• [X] I searched for other open and closed issues before opening this

Additional Context

No response

[GeorgeMac]

Hey @PlkMarudny the default value for a Boolean flag is just the enabled property of the flag. You can leave it as false, but then have rules which cause the evaluated result of enabled property to be true when the conditions on the rollouts are true.

This works as you described here, where the flag returns false if all other conditions fail.

[anthonpetrow]

@GeorgeMac hi I would like to clarify about this issue your answer is unclear to me please tell me, how I can make the default value false for all keys?

[GeorgeMac]

Hey @anthonpetrow

When it comes to Boolean flags, the enabled property (the toggle on the flag view) is the value returned when all other rollout conditions associated with a flag resolve to false. If you want each of your flags to be disabled by default, leave this property (toggle in the UI) as false / disabled / off.

You can then add rollouts which change the resulting value of the flag to true (or false, you can do the reverse here too) under certain conditions (within some percentage rollout or when matching a segment).

Does that help clarify?

Another point which might help: you do not need to “enable” a Boolean flag to use it. You can still use a “disabled” flag, this just means the flags evaluates to false (ie disabled by default).

[ducva]

@GeorgeMac I understand it can work with enabled property. But from UI/UX view, I think enabled is for different purpose. It says this Flag is in used or not, not about the Flag's value. So I think having a Default value is better option. This is an example:

1. Enabled = true, Default Value = true:

• If segment matched => return segment's value
• If segment no matched => return Default value

2. Enabled = false

• always return false.

[GeorgeMac]

@ducva I totally appreciate that. I agree that it is confusing that enabled is leveraged for the default here. I understand and appreciate the point you are each making and how enabled and default values as separate concepts on the flag would have been clearer.

When designing this, I did push against what you're describing as I felt (at the time) that having both enabled and default was more confusing than representing a boolean flag as just a single boolean value (e.g. like a remote boolean variable) that you could change the resulting value of based on conditions was cleaner (This was influenced by my past experience other feature flag tools that did it in this way). However, to get there, we already had models for representing the flag that we needed to fit this in, which meant co-opting enabled for the default value to get the desired semantics.

Clearly this was a mistake and has left folks confused. I hold my hands up there 🙌

Now that we have this contract though, we can't change it out from under folks. Introducing default today and making enabled == false meaning that the flag always evaluates to false, would change behaviour unexpectedly. Flags would suddenly start being disabled when Flipt is upgraded. So I am wondering, what are the paths forward?

The first, most backwards compatible things I can think of, would be to rework the wording so that the existing behaviour is more intentional and clear from the UI and API perspectives.

For the boolean flag page view in the UI, we could simply change the wording of enabled to default. This alone might help, or it might be confusing in terms of the disconnect between the UI and the API/declarative format.

We could go a step further and introduce a default field to the APIs, which takes the place of enabled and deprecate the enabled for the boolean flag type. This would make the API fall more inline with the UI change suggestion.

These are couple relatively low touch changes that might make the existing experience clearer, what do you all think?

We are totally open to suggestions though, if anyone has any, for backwards compatible changes here that could help in this area 🙏