Add Tags for Organizational Management

[bradphilips]

At a large organization like Progressive, we need a way of easily identifying Flags that are aligned with certain organizations (e.g. Mobile, Online Servicing) as well as separate types of tags such as Feature Flags, A/B Tests and Configuration Distribution. Tags is a feature that is commonly used to organize and provide searchability across large groupings of like objects, similar to #hashtags on social media or file tags in macOS Finder. This works by assigning descriptive tag(s) to these objects so looking for them is as simple as looking for the tag and anything associated to it will be found. We would like to add a tagging system to Flagr to accomplish the same goals.

This could be used to identify Flags easily by searching their assigned tags and batch evaluate them all in one call.

Outside of this, we could also use this for organization of flags of different types or assigned to different organizations, and potentially for reporting and access control.

Design:

How we are thinking of this from a design perspective is that Tags would be a many to many relationship to Flags. The tasks we have identified are as follows:

1. Create a Tag entity with the following schema:

type Tag struct {
	gorm.Model

	Value string  `sql:"type:text" gorm:"unique;not null"`
	Flags []*Flag `gorm:"many2many:flags_tags"`
}

2. Modify the Flag.go to reference a many to many relationship between Tags:

// Flag is the unit of flags
type Flag struct {
	gorm.Model

	Key         string `gorm:"type:varchar(64);unique_index:idx_flag_key"`
	Description string `sql:"type:text"`
	CreatedBy   string
	UpdatedBy   string
	Enabled     bool
	Segments    []Segment
	Variants    []Variant
	**Tags        []Tag `gorm:"many2many:flags_tags;"`**
	SnapshotID  uint
	Notes       string `sql:"type:text"`

	DataRecordsEnabled bool
	EntityType         string

	FlagEvaluation FlagEvaluation `gorm:"-" json:"-"`
}

3. Provide Get, Create and Delete endpoints for tags (/flags/{id}/tags, /flags/{id}/tags/{id}
4. Modify the FindFlags to allow searching for Tags
5. Modify the Evaluate Batch to evaluate by a flagTags property
6. Modify the UI to provide the ability to add tags to flags
7. Modify the search to be able to search Flags by Tag
8. Add Unit Tests
9. Add endpoints for managing Tags independently? (e.g. /tags, /tags/{id})
   a. We’re not sure this is needed – let us know your thoughts

Benefits of this Approach:

1. Allows many Tags to be associated with a single Flag and allows a single Tag to be associated with many Flags
2. Removes duplicity when assigning a Tag that already exists in the database as when assigning it will check for the existence of the Tag and assign it if already available
3. Doesn’t alter the underlying schema of the Flags table itself
4. Allows us to easily identify Flags being used in different organizations or by type of flag (e.g. Feature Toggle, A/B Test, Config Distribution)
5. Allows us to easily evaluate all flags by a certain type – we have a use case for external alerting to provide a batch evaluation of all flags matching a certain moniker.

There are already a couple issues open for this:

#314 and #323

We are already underway with prototyping the development above, and should have a PR shortly but would like to get your thoughts.

Let us know what you think. Thanks!

[fenriskiba]

I've been working with @bradphilips on this issue, and we are getting close to submitting a PR for it, but we had a quick question.
We weren't sure if we should include the associated tags in the response for evaluations that don't use them.

We've included it in the evalContext of any Batch Evaluation that uses it just like we would a Flag ID or Flag Key:

{
  "evaluationResults": [
    {
      "evalContext": {
        "entityContext": {
          "hello": "world"
        },
        "entityID": "a1234",
        "entityType": "report",
        **"flagTags": [ "ABTest" ]**
      },
      "evalDebugLog": {
        "segmentDebugLogs": []
      },
      "flagID": 1,
      "flagKey": "koy8411v5o6zc62i2",
      "flagSnapshotID": 1699,
      "segmentID": 2,
      "timestamp": "2020-05-28T20:51:45Z",
      "variantAttachment": {
        "text": "Hi"
      },
      "variantID": 1,
      "variantKey": "hi"
    }
  ]
}

But we were debating including Tags in the rest of the response like the flagID, flagKey, segmentID, etc. so that the analytics logs would include which Tags are on the Flag being evaluated against:

{
  "evalContext": {
    "entityContext": {
      "hello": "world"
    },
    "entityID": "a1234",
    "entityType": "report",
    "flagKey": "koy8411v5o6zc62i2"
  },
  "evalDebugLog": {
    "segmentDebugLogs": []
  },
  "flagID": 1,
  "flagKey": "koy8411v5o6zc62i2",
  **"flagTags": [ "ABTest" ],**
  "flagSnapshotID": 1699,
  "segmentID": 2,
  "timestamp": "2020-05-28T20:52:37Z",
  "variantAttachment": {
    "text": "Hi"
  },
  "variantID": 1,
  "variantKey": "hi"
}

We weren't sure if it would make sense to add that information to the response for analytics, or if hiding it to prevent exposing unnecessary information would make more sense for the larger community.

[zhouzhuojie]

Hey, thanks for the thoughtful decision making. If we are not sure what to do about tags in the evaluation response or in analytics, I think we can skip them in the response for now. We can always add them later or make them appear with optional configuration. What do you think?

[fenriskiba]

Makes sense to me. Thank you!

[bradphilips]

Sound good to me as well! Thanks so much for the feedback, @zhouzhuojie.