Splunk Enterprise

Is there a way we can update the code for disabling data input parameter for the addon build with addon builder 4.x?

jabezds
Path Finder

Hi all,

We have a case where we want to restrict a user from editing or updating  a input parameter .

We have created a addon using Splunk's Add-on builder (v4.x), the addon takes couple of Data Input Parameters, which include a parameter that has to be disabled and should not be allowed to be updated.

Is there a way we can update the code or does addon builder provide a option to perform such functionality?

Any help or suggestions will be highly appreciated.

 

Thanks,

Jabez.

0 Karma

sloshburch
Splunk Employee
Splunk Employee

Hi - If folks can't change the value then it probably doesn't need to even be presented in the UI when making/editing the input. Therefore you could hard code it in the python or make it part of the input's definition in `default/input.conf` conf file but don't show it in the UI. Of course another option could be to hack the CSS/javascript of those generated pages to force the field to be readonly but I wouldn't recommend this as I doubt you'd ever be able to use it with AoB after that.

If you do need it to be in the UI then perhaps share more about the practical nuance here. For example, which app and which field are we talking about and what is the use of this field such that you need it in the UI but not editable?

0 Karma

sloshburch
Splunk Employee
Splunk Employee

I've come to understand that the goal here is to provide the end users the ability to set a checkpoint to start from but then not let them change it thereafter since it could produce issues like data re-indexing.

I recently saw an approach that could work: storing the checkpoint on the server side, not the Splunk side. So I saw an add-on that retained context on where it left off with data collection on the service itself for that client. A clever advantage of this is that the add-on in theory could scale on multiple parallel collector instances.

In summary, it sounds like the leading options are to do custom UI stuff to lock down the field OR to allow the setting and checkpoint to exist on the server side, not the Splunk side.

I hope that helps!

0 Karma
Get Updates on the Splunk Community!

Message Parsing in SOCK

Introduction This blog post is part of an ongoing series on SOCK enablement. In this blog post, I will write ...

Exploring the OpenTelemetry Collector’s Kubernetes annotation-based discovery

We’ve already explored a few topics around observability in a Kubernetes environment -- Common Failures in a ...

Use ‘em or lose ‘em | Splunk training units do expire

Whether it’s hummus, a ham sandwich, or a human, almost everything in this world has an expiration date. And, ...