Segment rules can turn - true > True

[dabeeeenster]

Ok, so the reason for this is as follows:

When the FE is creating the segment condition, it silently casts the value to the correct type based on the input and sends this in the json.

e.g. entering 'true' results in the following json:

    "value": true

whereas entering, e.g. 'some string' results in:

    "value": "some string"

The BE simply converts whatever is sent into a string instead (for reasons I explain later in this message), but since the json becomes a python dictionary before storing it in the database, true becomes True. This string value is then what is stored against the segment condition and is what is returned to the FE (hence the discrepancy in what is returned).

When evaluating segments, however, the BE leans on the type of the trait, not the segment condition. So, if the trait is a boolean trait, then the BE will check if the condition value string is a valid python boolean and then compare the trait value against that accordingly. See the (simplified) python logic here:

    def check_boolean_value(self, value: bool) -> bool:
        if self.value in ("True", "true", "1"):
            bool_value = True
        else:
            return False

        if self.operator == EQUAL:
            return value == bool_value
        elif self.operator == NOT_EQUAL:
            return value != bool_value

        return False

Where this logic falls down, which is possibly the issue that the user is having, is when you legitimately want to test a string trait against a value of "true". This will never be possible since the FE will always cast this to a boolean and hence python will store the string "True" instead.

The simple fix here (as far as I can tell) is to prevent the FE from casting these values so that python stores the correct string. The BE will then still evaluate boolean trait values correctly since the logic looks at whether the string value is one of the following:

("True", "true", "1")

[kyle-ssg]

Fixed in f1d420e