saved object tagging phase 1

[nreese]

Create a new saved object type for storing tags

{
  "type": "tag",
  "updated_at": "2017-11-01T11:29:45.060Z",
  "tag": {
     "name": <string containing tag name that is displayed in tag pill, limited to 50 characters (like github)>,
     "color": <hex string - tag pill color>
   }
}

New kibana tag API

We will not be storing tag counts in the tag saved object. The tag counts will be generated on the fly by querying all saved objects, building a snapshot of counts, and adding the generated counts with the tag saved object results . This will avoid all the complexities of managing tag counts during saved object writes.

• get
  • query string parameter to include counts
• delete - delete tag saved object, remove tag from all other other saved objects

Saved object API updates

• add tag to saved object (saved search, visualization, dashboard)
• delete tag from saved object
• Update read to translate tag ids to tag names?

Manage tags on visualizations, saved-searches, and dashboards

• Tag management is done in save UI
• Ability to create new tags in save UI.
• Link to tag CRUD GUI for deleting/editing tags.

Use tags to filter visualizations, saved-searches, and dashboards lists

• dashboard list view
• dashboard add panels view
• visualize list view
• saved search list view
• index pattern

Questions

• Where should tags live in saved objects? Should tags live at the top level or should they live inside each saved object type?
• Where will tag ids get converted to tag name? Where should tag joining be done? In the saved object API? On the client?
• Where should tag CRUD GUI live? Should this be placed under management? Is this just going to be a pop-out?
• Tag colors: Should any color be allowed? Should there just be a static list of colors?

[nreese]

@elastic/kibana-operations @elastic/kibana-design @elastic/kibana-management Do you have any opinions about the questions above or the tentative plans for object tagging?

[snide]

Tag colors: Should any color be allowed? Should there just be a static list of colors?

Likely a mix. I'm planning to use the viz color blind palette (which is 10 colors) for the tags. We've got the color picker component as well though, so I'll make sure the badge component can how accept a hex color as a prop as well.

[AlonaNadler]

Adding a few to @nreese list

What are we trying to solve?

• Since all the dashboards/visualizations are in the same lists, users can’t tell easily which dashboard is relevant for their role, which makes it harder to find the relevant dashboards
• Users sometimes delete and edit dashboards that are not theirs since it’s not immediately clear in Kibana that these objects are global

Tags dedicated page(pop-up) : this page will have all functions related to managing tags:
-Create a new tag:

• Type tag name
• Select Tag color
• (Optional) tag’s description

-Edit a tag name:

• Edit color
• Edit name
• Delete a tag

-List number of objects in the tag (#visualizations, #dashboards, etc..) - list of tags with a summary of the number of objects from each type
-Search for a tag - search for a tag by name including full or partial match.

Tag an object: When saving an object (for new and existing object) user can select to tag the object with one or multiple tags from a list of existing tags (tagging an object is optional).

-Remove a tag from an object can also be done by clicking save (except for index pattern, TBD)

Filtering by a tag:

• Users can filter the objects by specific tag by filtering existing tab or by searching for the tag name
• Filter multiple tags - using OR (instead of AND)
• Persist last selection of tags - user selected Sales tag and Marketing tags in dashboard, next time he logs in to dashboards the list will be filtered by Sales or Marketing

[trevan]

@AlonaNadler, that document is not publicly available. Can it be?

[AlonaNadler]

@nreese I added index pattern to your lists of objects that can tagged

[nreese]

cc @elastic/kibana-platform

[chrisronline]

The GUI should probably live in management in the same area that saved objects are managed.

I'm not sure about the storage. I'm hoping we can just store them within each saved object itself instead of duplicating a list at some higher level. In the management UI, we can just search all saved objects (this shouldn't be too costly based on what I've heard about saved object counts, but someone feel free to contradict me here) and that will be the list we display.

[tylersmalley]

My immediate concern is the addition of a new type as an inter-object dependency. A seemingly large percentage of our users use the export/import as a backup/restore solution. How will we handle this? We will also rely on client-side joins for this data, increasing the complexity of creating a new object with a tag.

I am wondering if we could denormalize this data on the objects themselves and completely eliminate the need of adding a new type.

Example:

{
  "type": "visualization",
  "updated_at": "2017-11-01T11:29:45.060Z",
  "tags": [{
     "name": <name>,
     "color": <hex>
   }],
  "visualization": {
    ..
  }
}

Getting a list of available tags should be easy. The only question I have is changing a tag name or color. I believe this should be possible with the update_by_query using a script, but we would need to verify.

[bmcconaghy]

So it seems like we could just have tags as the strings themselves and then use ES foo to build cached list of available tags for UI purposes. If we are going to be querying the docs anyway for tags, I don't see why we need the tag objects.