Saved Groups with Complex Targeting Conditions

[jdorn]

Features and Changes

• Rename "Inline Groups" to ID Lists
• Rename "Runtime Groups" to Condition Groups and add support for arbitrary targeting conditions
• Expand documentation on targeting in general

This is solving the same problem as #1838 but in a different, simpler way with fewer backwards incompatible changes and a cleaner UI.

Testing:

• Migration works for legacy saved groups (both inline and runtime)
• Create a new saved group (both kinds)
• Update saved groups (both kinds)
• Add id list to Target by Attribute
• Add both kinds of groups to Saved Group Targeting
• Verify SDK payload renders correctly
• Archetype testing
• Verify $groups attribute is added automatically when you had been using runtime groups
• REST endpoints for saved groups
• Referencing ID Lists from within Condition Groups

[github-actions]

Deploy preview for docs ready!

✅ Preview
https://docs-bs8dflkjk-growthbook.vercel.app

Built with commit 68c96e4.
This pull request is being automatically deployed with vercel-action

[github-actions]

Your preview environment pr-1978-bttf has been deployed.

Preview environment endpoints are available at:

• https://growthbook-3000-pr-1978-bttf.growthbook.okteto.dev
• https://growthbook-3100-pr-1978-bttf.growthbook.okteto.dev

[bttf]

Some of it above my head but from what I can tell it checks out. Left a few comments / questions

[bttf]

Is source deprecated? If so, should we consider cleaning it up in the migration?

[jdorn]

It is deprecated. Since I'm using this field in the JIT migration, I thought it might be safest to leave it in the mongoose schema, even if it's not being set or queried anymore.

[bttf]

Is it possible that we have saved groups in the DB without an org assigned?

(Is this something we'd want to include in the migration?)

[jdorn]

No, saved groups have always had an organization field set.

[bttf]

I noticed the 'auto-add' endpoint added to the organization router/controller but having trouble understanding it. It seems like a legacy way of storing saved groups. Is that correct? Could you explain a little bit about it?

[jdorn]

We had the concept of "runtime" saved groups. It would look something like this:

{
  id: "sg_abc123",
  organization: "org_abc123",
  source: "runtime",
  attributeKey: "admins"
}

When we rendered this into the SDK payload, we would convert it to a condition looking for this special $groups attribute:

{
  defaultValue: false,
  rules: [
    {
      condition: { "$groups": {"$elemMatch": {"$eq": "admins"}}},
      force: true
    }
  ]
}

And we told people to pass that $groups attribute into their SDK:

new GrowthBook({
  attributes: {
    $groups: ["admins", "beta-users"]
  }
})

Since this was a special attribute, we didn't require people to add it to the SDK Configuration -> Attributes page to be able to use it.

Now that we switched to use the <ConditionInput> component for these groups, it's a pretty bad experience if you go try and edit one of these old runtime groups. If that attribute doesn't exit, it defaults to the advanced JSON editing view which is hard to use.

So this is a little utility endpoint to auto-add a $groups attribute to their org if it's missing and they had previously set up a runtime group. If it fails to run for whatever reason, it's not the end of the world. The user experience will just be slightly degraded until they manually define the attribute in the UI.