Dashboards & Visualizations

Hiding links from nav.xml

southeringtonp
Motivator

Is there a way to suppress certain entries from showing up in nav.xml, while still allowing new searches/views to appear by default?

The goal is to suppress the display of certain saved searches (e.g., summary index generation), while still allowing new entries to appear automatically

I'm thinking of something that would work like:

<saved source="unclassified" match="SIGen" is_visible="false" />

so that later entries with source="unclassified" would not include entries matching "SIGen".

Tags (1)
1 Solution

Lowell
Super Champion

You can't do this using the nav.xml file, but you can add is_visible = 0 to the saved search entry in savedsearches.conf. This should keep the saved search from showing up in the navigation menu.

View solution in original post

Lowell
Super Champion

You can't do this using the nav.xml file, but you can add is_visible = 0 to the saved search entry in savedsearches.conf. This should keep the saved search from showing up in the navigation menu.

Lowell
Super Champion

Agreed. It does seem like there should be some more flexibility built into the way saved searches and views are organized into menus. (IMHO, there's lots of room for improvement: Tagging saved searches, in browser match-as-you-type filtering to help you more quickly find the desired saved search, easier ways to set permissions when you create a new search, and so on.)

0 Karma

southeringtonp
Motivator

That's what I was afraid of. This approach is fine for specific searches, but it's a nuisance when you want to do it based on a wildcard match.

0 Karma
Get Updates on the Splunk Community!

Index This | What’s a riddle wrapped in an enigma?

September 2025 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with this ...

BORE at .conf25

Boss Of Regular Expression (BORE) was an interactive session run again this year at .conf25 by the brilliant ...

OpenTelemetry for Legacy Apps? Yes, You Can!

This article is a follow-up to my previous article posted on the OpenTelemetry Blog, "Your Critical Legacy App ...