I want to bind an action to a click event (probably 'click:cell', but can go with 'click:row') in a TableView. That action will get the data from the click event and display a popup (Bootstrap modal) populated according to those data. All this is done in an HTML panel.
I know how to get the value of any column in the table from the event. However, I would like to have some data which are not shown on the screen, but are still "bound" to a table row. Even an access to a _raw
field (as long as it's not displayed) would suffice - I'd extract what I need in JavaScript.
To clarify - let's consider the following search:
index=myIndex category=$selected_category$ | fields product, cost, amount, total, category | table _time, product, cost, amount, total
$selected_category$
is a token set by a drop-down and having a value of "*"
(All) or a legitimate category value (populated by a search piped into dedup category
). As you can see, I do not want to display category on the screen. However, I would like to have access to it from the click event. Right now, all the various data.row.<field> and event.rowContext.row.<field> members do not include that category field.
Any reasonable way to achieve what I want?
I guess I found how to achieve this. Start the SimpleXML dashboard with all the needed fields (so my initial search would indeed contain that category field - the last pipe would read | table _time, product, cost, amount, total, category
). Export the dashboard into HTML. Then find the TableElement you want to modify - looks like this:
var element2 = new TableElement({
"id": "element2",
"count": 10,
"dataOverlayMode": "none",
"drilldown": "cell",
"rowNumbers": "false",
"wrap": "true",
"managerid": "search2",
"el": $('#element2')
}, {tokens: true, tokenNamespace: "submitted"}).render();
and add a property named fields
, like this:
var element2 = new TableElement({
"id": "element2",
"count": 10,
"dataOverlayMode": "none",
"drilldown": "cell",
"rowNumbers": "false",
"wrap": "true",
"managerid": "search2",
"fields": "_time, product, cost, amount, total",
"el": $('#element2')
}, {tokens: true, tokenNamespace: "submitted"}).render();
Voilà - the displayed fields are the _time, product, cost, amount, total, but the event contains both e.data.row.category and e.event.rowContext.row.category properties! (In addition to everything else)
This is an old question but the new answer to this for anyone running into this should be in simple xml just add the attribute fields with a quoted list like so:
...
<option name="drilldown">no</option>
<fields>["_time","product","cost","amount","total"]</fields>
...
I guess I found how to achieve this. Start the SimpleXML dashboard with all the needed fields (so my initial search would indeed contain that category field - the last pipe would read | table _time, product, cost, amount, total, category
). Export the dashboard into HTML. Then find the TableElement you want to modify - looks like this:
var element2 = new TableElement({
"id": "element2",
"count": 10,
"dataOverlayMode": "none",
"drilldown": "cell",
"rowNumbers": "false",
"wrap": "true",
"managerid": "search2",
"el": $('#element2')
}, {tokens: true, tokenNamespace: "submitted"}).render();
and add a property named fields
, like this:
var element2 = new TableElement({
"id": "element2",
"count": 10,
"dataOverlayMode": "none",
"drilldown": "cell",
"rowNumbers": "false",
"wrap": "true",
"managerid": "search2",
"fields": "_time, product, cost, amount, total",
"el": $('#element2')
}, {tokens: true, tokenNamespace: "submitted"}).render();
Voilà - the displayed fields are the _time, product, cost, amount, total, but the event contains both e.data.row.category and e.event.rowContext.row.category properties! (In addition to everything else)
Two warnings (found this out the hard way):
element2.on("click", function (e) {...})
) - it doesn't work. The actual syntax would be e.data["row.category"] - there is no row
property under e.data, rather several individual "row.<field>" properties!e.data
.As a friendly criticism - Splunk documents should detail such stuff a little better to be useful. All these findings feel too much like reverse engineering to me...