[Feature] Support Display Names for Index Patterns

[dfradehubs]

Add optional Display Name field for Index Patterns to improve UX

Is your feature request related to a problem? Please describe.

Yes. Currently, index patterns in OpenSearch Dashboards only have a title field that serves both as the technical pattern (e.g., logs-*,prod-istio-gateway-*,metrics-*) and as the display name shown throughout the UI. This creates usability issues when:

1. Complex patterns are hard to read: Comma-separated or wildcard patterns like logs-prod-*,logs-staging-*,metrics-* are difficult to identify at a glance in dropdowns and selectors
2. Technical patterns lack context: A pattern like test-* doesn't communicate its purpose (is it for testing? production? which application?)
3. Multiple similar patterns are confusing: When you have several patterns like app-logs-*, app-metrics-*, app-traces-*, they all look similar in selectors
4. Non-technical users struggle: Users who don't understand wildcard syntax or index naming conventions find it hard to select the right pattern

Example scenario:
I have an index pattern test-istio-gateway,test-nginx-sidecar,test-haproxy-logs that monitors three specific test environments. In Discover, Visualize, and Dashboards, I constantly see this long technical string. I would prefer to see a friendly name like "Test Environments" while keeping the technical pattern intact for queries.

Describe the solution you'd like

Add an optional displayName field to index patterns that provides a user-friendly presentation layer without affecting the semantic behavior:

Key Features:

1. Separate display from semantics:

   • title: The technical pattern used for queries (immutable semantics)
   • displayName: Optional friendly name shown in UI (presentation only)

2. Backwards compatible:

   • displayName is optional
   • If not set, fall back to showing title (current behavior)
   • Existing index patterns work without changes

3. Available everywhere:

   • Management UI: Create and edit display names
   • Discover/Data Explorer: Selectors show display names
   • Visualize: Show display names in pickers
   • Dashboards: Display names in all contexts
   • Filters: Display names in filter editor

4. Implementation approach:

   interface IndexPatternSpec {
     title: string;        // Technical pattern (required)
     displayName?: string; // Friendly name (optional)
   }
   
   // In UI components:
   const displayText = indexPattern.getDisplayName(); // Returns displayName ?? title
   
   // In queries:
   const pattern = indexPattern.title; // Always uses technical pattern

User Experience:

Before:

Selector shows: "test-istio-gateway,test-nginx-sidecar,test-haproxy-logs"
Management shows: "test-istio-gateway,test-nginx-sidecar,test-haproxy-logs"

After:

Selector shows: "Test Environments"
Management shows: "Test Environments (test-istio-gateway,test-nginx-sidecar,test-haproxy-logs)"
Queries still use: "test-istio-gateway,test-nginx-sidecar,test-haproxy-logs" ← No semantic change

UI Changes Needed:

1. Index Pattern Creation Wizard: Add optional "Display name" field as first input
2. Index Pattern Edit Page: Inline editor with pencil icon next to title
3. Index Pattern List: Show display name with pattern in parentheses when set
4. All Selectors: Display display name in dropdowns/pickers (Discover, Visualize, etc.)
5. Breadcrumbs: Use display name for navigation

Describe alternatives you've considered

1. Creating duplicate patterns with different titles:

   • ❌ Wastes resources and storage
   • ❌ Causes confusion about which is the "real" pattern
   • ❌ Doesn't solve the underlying UX issue
   • ❌ Maintenance nightmare

2. Using description field:

   • ❌ Description is for detailed explanations, not short labels
   • ❌ Not shown in selectors/dropdowns
   • ❌ Different semantic purpose
   • ❌ Too verbose for UI display

3. Renaming title to be user-friendly:

   • ❌ Breaks the semantic meaning and pattern matching
   • ❌ Queries would fail
   • ❌ Would require reindexing data
   • ❌ Breaking change for existing setups

4. Adding tags/labels system:

   • ❌ Overcomplicated for this simple use case
   • ❌ Still doesn't solve "what to show in selectors"
   • ❌ Requires complex UI for tag management
   • ❌ Overkill for basic naming needs

Why displayName is the best solution:

• ✅ Clear separation of concerns (presentation vs semantics)
• ✅ Fully backwards compatible
• ✅ Simple and intuitive for users
• ✅ Follows established patterns (Kubernetes displayName, LDAP displayName)
• ✅ Zero breaking changes
• ✅ Minimal code changes required

Additional context

Implementation Considerations:

1. Saved Object Structure:

   {
     "type": "index-pattern",
     "attributes": {
       "title": "test-*",
       "displayName": "Test Environment"
     }
   }

2. Migration Strategy:

   • Add displayName?: string to IndexPattern/DataView models
   • Create migration that initializes displayName = undefined for existing patterns
   • Update saved object mapping to include displayName field
   • No data loss, full backwards compatibility
   • Export/Import preserves both fields

3. API Behavior:

   • Saved Objects API accepts displayName in create/update operations
   • _find queries include displayName in results
   • Search operations can query by both title and displayName
   • getDisplayName() method returns displayName ?? title

4. Areas That Need Updates:

   • ✅ Management UI (create/edit/list index patterns)
   • ✅ Discover / Data Explorer (index pattern selector)
   • ✅ Visualize (index pattern picker)
   • ✅ Dashboard (index pattern references)
   • ✅ Filter editor (index pattern selection)
   • ✅ SQL/PPL query autocompletion
   • ✅ Breadcrumbs and page titles

Benefits:

• Improved UX: Users can assign meaningful, contextual names to technical patterns
• Better onboarding: New users understand patterns through friendly names without needing to learn pattern syntax
• Reduced errors: Easier to select the correct pattern from a list of many
• No breaking changes: Existing patterns continue to work exactly as before
• Enterprise-friendly: Large organizations can enforce human-readable naming conventions
• Accessibility: Screen readers can announce meaningful names instead of cryptic patterns
• Internationalization ready: Display names can be localized while patterns remain technical

Example Use Cases:

1. Complex comma-separated patterns:

   • Pattern: logs-2024-*,logs-2023-*,legacy-logs-*
   • Display Name: "All Application Logs"

2. Multiple environments:

   • Pattern: prod-app-* → Display: "Production Application"
   • Pattern: staging-app-* → Display: "Staging Environment"
   • Pattern: dev-app-* → Display: "Development Environment"

3. Team-specific patterns:

   • Pattern: team-alpha-metrics-* → Display: "Team Alpha Metrics"
   • Pattern: team-beta-logs-* → Display: "Team Beta Logs"

4. Multi-tenant scenarios:

   • Pattern: customer-123-* → Display: "Acme Corp Data"
   • Pattern: customer-456-* → Display: "Global Industries Data"

Similar Features in Other Tools:

• Kubernetes: Uses metadata.displayName extensively for resources
• Grafana: Supports custom display names for data sources
• Elasticsearch/Kibana: Community has requested similar feature multiple times
• LDAP/Active Directory: Common pattern with cn vs displayName

Technical Implementation Notes:

The implementation should:

1. Add displayName?: string to IndexPatternSpec interface
2. Update saved object type definition to include displayName in mappings
3. Create migration function for version compatibility
4. Modify all selector components to use getDisplayName() instead of accessing title directly
5. Update IndexPatternSelect, DatasetSelector, DataSourceSelectable components
6. Add UI for editing display name in Management
7. Include display name field in creation wizard
8. Update breadcrumbs and page titles to use display name
9. Ensure export/import functionality preserves display name
10. Add appropriate unit and integration tests

Screenshots/Mockups:

Management - Edit Page:

Index Pattern Selector in Discover:

Creation Wizard - Step 1:

Visualization:

Community Impact:

This feature would particularly benefit:

• Large enterprises managing dozens of index patterns
• Multi-tenant deployments where patterns need business context
• Teams with non-technical users who need intuitive interfaces
• Organizations with complex naming conventions where technical patterns are cryptic

Proposed Migration Path:

1. Version 3.2.0+: Introduce displayName field
2. Migration runs automatically on startup
3. Existing patterns work unchanged (displayName=undefined)
4. Users can optionally add display names
5. Future exports include both fields

---

Note: I have implemented a working proof-of-concept with all necessary changes tested across Management, Discover, Data Explorer, Visualize, and other components. The implementation touches approximately 29 files and includes comprehensive test coverage. Happy to contribute a PR if this feature request is accepted by the maintainers.

main...dfradehubs:OpenSearch-Dashboards:main

Related Documentation:

• OpenSearch Index Patterns: https://opensearch.org/docs/latest/dashboards/management/index-patterns/
• Data Views Concept: https://opensearch.org/docs/latest/dashboards/