[Bug] Cannot use strings with commas when using an `$in` or `$nin` operator in a targeting condition

[Jeremy Dorn]

Summary

In simple mode, the $in operator uses a comma as a delimiter, so there's no way to add the string "a,b" as one of the values.

In advanced mode, you can do this, but on save it automatically converts it to simple mode and messed up the condition:

There is a workaround, but it is ugly. By wrapping the condition in an $and operator, you can make it complex enough where we don't try converting back to simple mode:

[Michael Knowlton]

@jdorn I've dug into this and I've not been able to identify a quick and easy fix for this, that doesn't introduce any unintentional side effects for the normal use case (i.e. the use case where the id doesn't contain a comma).

Currently, we call value.split(","), so we split on every comma. We could update the split call to split on (", ")- so we split anytime there is a comma followed by a space. That would fix the issue, but introduce some side effects. Namely, if someone enters "a,b,c,d" - today that will result in["a", "b", "c", "d"], but if we introduce the change, it'd result in ["a,b,c,d"]. And that is probably a lot more common than an id containing a comma, so probably not the route we want to go. Its possible to build some really twisty logic that looks to see if there is a comma followed by a space, and if so, split with (", "), otherwise split with the standard (","). But that again could lead to weird, unexpected results. And I'd hate to create a confusing experience for the "normal" flow.

Another option is to update the "Advanced mode" behavior in a way that reduces the simple mode conversion. Maybe something as simple as a "don't auto format my json" or something.

And the last option, which would be the most flexible, but would introduce complexity into the UI, is allowing the user to select the delimiter. We could add an optional delimiter field to BaseRule, where if not set, we default to using the comma.

Perhaps this is another opportunity to introduce some localization - my hunch is this is more likely to affect non-us countries that use a comma as a decimal separator. It's less flexible than allowing the org to select the delimter at the rule level.

[Marllon Vilano]

Another option is to update the "Advanced mode" behavior in a way that reduces the simple mode conversion. Maybe something as simple as a "don't auto format my json" or something.

As a developer having the same problem, I like this approach.

[Jeremy Dorn]

I think a simple fix for now is to change the jsonToConds function slightly so that it skips converting to simple mode when one of the array elements contains a comma.

if (operator === "$in" || operator === "$nin") {
  if (v.some(str => str.includes(","))) {
    valid = false;
    return;
  }
  return conds.push({
    field,
    operator,
    value: v.join(", "),
  });
}