Inconsistent behaviour with boolean condition

[mtrevor]

I'm assessing django-flags for use in a project where we want to be able to switch on or off specific site behaviour without requiring a redeploy. Ideally, we want to be able to deploy with a feature turned off in order to allow for integration setup to happen first.

I'm hitting an unexpected issue with assigning a boolean condition to a flag and I'm concerned it shows I haven't understood a basic principle of this library.

I've created a flag with an existing boolean condition, which I assumed was setting the default of the flag:

FLAGS = {
    'TEST_FLAG': [
        {'condition': 'boolean', 'value': True, 'required': True},
    ]
}

This appears to work as I'd expect:

>> flag_state('TEST_FLAG')
True
>> disable_flag('TEST_FLAG')
>> flag_state('TEST_FLAG')
False

But when I tried to set a flag's default to False, it didn't work the same way:

# settings.py
FLAGS = {
    'TEST_FLAG': [
        {'condition': 'boolean', 'value': False, 'required': True},
    ]
}

# shell
>> flag_state('TEST_FLAG')
False
>> enable_flag('TEST_FLAG')
>> flag_state('TEST_FLAG')
False

I've tried it with and without the required param and it makes no difference.

I've noticed that the conditions I've defined in settings don't appear in the admin panel, but that enabling/disabling a flag will add a boolean condition, so my best guess is they're separately evaluated and the second example ends up with two conditions that together will never be true?

Is the behaviour demonstrated above expected? And if so, is it possible to set a flag's initial state to False?

Thanks.

[willbarton]

@mtrevor a brief thing to try: remove required: True from the setting. I believe this is causing the unexpected behavior. It adds some complexity to flag evaluation that doesn't seem warranted in your situation.

required: True makes Django-Flags require that ALL conditions marked as required evaluate to True. This is never true in the second example, so the flag will never be enabled.

The unexpected behavior comes from the way enable_flag and disable_flag work. They're convenience functions that hide some shenanigans under the hood. If the flag is defined in settings, and enable_flag() or disable_flag() is called to change its state, a database-stored boolean condition is created, and the boolean is set there. You then technically end up with two boolean flag conditions, one in settings that must always evaluate to True, and another that could.

So what you've got happening is you're ending up after the disable_flag call with state equivalent to this:

  'TEST_FLAG': [
      {'condition': 'boolean', 'value': True, 'required': True},
      {'condition': 'boolean', 'value': False},
  ]

This ends up evaluated as:

>>> all([True]) and any([False])
False

This does behave as intended, but possibly not the way you intended.

In your second example, after the enable_flag call you have state equivalent to this:

  'TEST_FLAG': [
      {'condition': 'boolean', 'value': False, 'required': True},
      {'condition': 'boolean', 'value': True},
  ]

This ends up evaluated as:

>>> all([False]) and any([True])
False

So, again, if you leave your required: True off in settings, you'll end up with something like:

  'TEST_FLAG': [
      {'condition': 'boolean', 'value': False},
      {'condition': 'boolean', 'value': True},
  ]

Which evaluates as:

>>> any([False, True])
True

I hope that helps — I do think there's some hidden complexity here in both how enable_flag and disable_flag work and in how "required" conditions interact with other conditions.