About bayuste

bayuste · ‎10-21-2025

The presence of a dashboard in the default directory tree removes the delete option from Settings > User Interface > Views interface. You can use Settings -> User Interface > Views to (1) delete private dashboards in the user directory tree; and (2) to delete a shared dashboard in the app local directory tree as long as there is not another copy of the dashboard in the default directory tree. Dashboards end up in the default directory tree on a search head cluster via deployment from a search head deployer. Dashboards also commonly reside in the default directory tree on stand alone search heads in apps installed directly from Splunkbase. Edit one of these default dashboards in the GUI, and it will be saved in the local directory tree. But the original copy of the dashboard in default will remove the delete option from Settings > User Interface > Views. The default dashboards can only be deleted manually from the filesystem.

bayuste · ‎12-20-2024

We can be more direct in our manipulation of the dashboard in newer versions of Splunk. The structure of the nested div elements for tables is as follows [ .splunk-view .splunk-table - [ .shared-reportvisualizer - contains the table ] [ .splunk-view .splunk-paginator - contains the paginator ] ] All we have to do is reverse the display order of the div elements in the .splunk-table container ... <row depends="$always_hide_css$"> <panel> <html> <style> div[id^="topPaginatorTable"] .splunk-table { display: flex; flex-wrap: wrap; } div[id^="topPaginatorTable"] .shared-reportvisualizer { position: relative; order: 2; } div[id^="topPaginatorTable"] .splunk-paginator { position: relative; order: 1; } </style> </html> <panel> <row> Then add id="topPaginatorTable1", id=topPaginatorTable2, etc, to each table in the dashboard where you want to move the paginator to the top. I like this method better as it leaves no padding artifacts in the case that no paginator is required, and rest of the box model of HTML formats correctly for width constrained panels.

bayuste · ‎11-21-2021

I disagree. Reading Rich’s answer would lead you to believe that “| rest /servicesNS” is more restrictive than “| rest /services” by limiting the scope to the specified namespace. In fact, it is the other way around. Or, more precisely, “| rest /services” is equivalent to “| rest /servicesNS/<currentUser>/<defaultApp>”, which implicitly limits the results to what is visible from the current user running in the default app context, which is usually the search app. We can expand the namespace to include more results by converting the call to “| rest /servicesNS/-/-“, or we can change the namespace to an explicit user/app context with “| rest /servicesNS/<arbitraryUser>/<arbitraryApp>”. It is a subtle but important difference. For some global system-wide resources, the results will be the same from every user/app context. In those cases, the call is usually shortened from “| rest /servicesNS/-/-” to “| rest /services”. So, every time I see “| rest /services”, I translate that in my head to be “| rest /servicesNS/<currentUser>/<defaultApp>”

Posts	5
Solutions	0
Karma Given	0
Karma Received	6
Member Since	‎03-13-2018

Online Status	Offline
Date Last Visited	‎10-21-2025 05:46 PM

Re: Unable to delete dashboards in an app

Re: How to re-position the paginator in a dashboar...

Re: Difference between Splunk rest api services an...

Join the Conversation

Re: Unable to delete dashboards in an app

Re: How to re-position the paginator in a dashboar...

Re: Difference between Splunk rest api services an...