[Cases] Custom fields in Cases

[cnasikas]

To aid users to classify and enrich their cases better we will provide the ability to create custom fields. Users will be able to configure their custom fields, add values, view them in the case view page and the cases table, and filter by them.

Schema

enum CustomFieldTypes {
  STRING = 'string',
  URL = 'url',
  LIST = 'list',
  BOOLEAN = 'boolean',
}

interface CustomField {
  key: string;
  label: string;
  defaultValue: string | null;
  required?: boolean;
  group_key?: string;
}

interface StringCustomField extends CustomField {
  type: CustomFieldTypes.TEXT;
  limit: number;
}

interface ListCustomField extends CustomField {
  type: CustomFieldTypes.LIST;
  options: string[];
  singleSelection: boolean;
}

Saved objects

The schema of the custom fields should be ZDT compatible. This means that we can only extend the schema by adding optional fields.

Configuration saved object

In the cases-configure saved object we will persist the configuration of the custom fields. Example:

[ { key: 'my_key', type: 'text', label: 'My test custom field', .... } ]

There is no need to index any of the fields so the mapping of the cases-configure saved object will remain as it is.

Cases saved object

In the cases saved object we will persist the values of the custom fields. Example:

[ { key: 'my_key', value: ['My value'] } ]
[ { key: 'my_key_2', value: ['My value 1', 'My value 2'] } ]

A value can be of multiple data types. It can be a string, an integer, a number, and a boolean. Strings can also have a special meaning like dates or IPs. Also, all values should be indexable so they can be filtered and used in aggregations. For these reasons, the mapping of the custom fields in the cases saved object will be:

{
  "mappings": {
    "properties": {
      "custom_fields": {
        "type": "nested",
        "properties": {
          "key": {
            "type": "keyword"
          },
          "value": {
            "type": "keyword",
            "fields": {
              "number": {
                "type": "long",
                "ignore_malformed": true
              },
              "boolean": {
                "type": "boolean",
                "ignore_malformed": true
              },
              "string": {
                "type": "text"
              },
              "date": {
                "type": "date",
                "ignore_malformed": true
              },
              "ip": {
                "type": "ip",
                "ignore_malformed": true
              }
            }
          }
        }
      }
    }
  }
}

The custom_fields property will be an array of key-value pairs. To allow the custom fields to be indexed in a way that they can be queried independently of each other we need to set the custom_fields property as nested.

In some scenarios, the value may need to be an object. For example in the case of the URL type. We need to persist the text and the link to be able to do <a href="{{my_link}}" >{{my_text}}</a>. At the same time, we want each value of the object to be indexable but avoid dynamic mapping which can lead to a field mapping explosion in the .kibana_alerts_cases index. To mitigate this issue and support objects, the object will be flattened and each attribute of the object will be one entry in the custom fields array. For example the { text: 'My text', link: 'https://example.com' } object will be persisted as

[
   { key: 'url.text', value: ['My text'] }, 
   { key: 'url.link', value: ['https://example.com'] } 
]

The url prefix in the key is the grouping key and can be defined when configuring the URL field type in the cases configuration page. The configuration for the URL would look like:

[ 
  { key: 'text', type: 'text', label: 'Text', group_key: 'url' } 
  { key: 'link', type: 'text', label: 'URL', group_key: 'url' }
]

Desing patter

We should follow the Factory pattern to create and view the custom fields in the server and in the UI, similar to what we do with the user actions. This will allow us to easily add more custom fields in the future.

Tasks

• Update Mapping for cases saved object ([Cases] Model version the Cases SO for custom fields #166940, [Cases] Custom fields types #165671, [Cases] Custom fields schema changes #167310)
• Create io-types ([Cases] Custom fields types #165671, [Cases] Add customFields to cases configuration #166439, [Cases] Custom fields schema changes #167310)
• Extend the SavedObject client to support nested sorting ([Core] Allow nested sorting in the SavedObject client #163059)
• APIs ([Cases] Custom Fields API documentation #166353, [Cases] Backend validation custom fields #166962, [Cases] Validate custom field keys #166975, [Cases] Validate length of text custom fields. #167029, [Cases] Required custom fields in the create case API #167131, [Cases] Validate types custom fields #167166)
• Configuration page: Add the ability to configure custom fields ([Cases] added UI to add custom field on configuration page (text and toggle field) #166483, [Cases] Limit number of custom fields in UI #167047, [Cases] Adds the experimental badge to custom fields #167105, [Cases] Delete custom field #167167, [Cases] Edit custom field configuration #167386)
• Create case form: Add the ability to set custom fields ([Cases] Create case form with custom fields #166969)
• View case page: Add the ability to view and set custom fields ([Cases] Edit custom fields in the case view page #166815)
• Cases table: Depends on Case table improvements  #159099
• Create user action for custom fields ([Cases] Custom fields user actions #167144)
• Create a sub-feature privilege to allow only administrators to configure custom fields ([Cases] Custom fields: Allow users to configure roles to prevent access to the cases settings page #167641)
• Allow navigating to the configuration page with a basic license ([Cases] Settings UI License Limitations #167398)

Related issue: #155380

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[elasticmachine]

Pinging @elastic/response-ops-cases (Feature:Cases)