Read one saved object's query and filters
malcolm_saved_object_detailRead-only
Reads one saved object with its query, filters, and index pattern resolved, so you can recover a curated query or find the search behind a visualization.
Instructions
Read one saved object with its query, filters and index pattern already resolved.
Use this on a saved SEARCH to recover the query a human curated —
Malcolm ships over a hundred of them, and the Arkime-side equivalent is
arkime_views — and on a visualization to find the search it is built
from. malcolm_saved_objects lists the catalogue and stops there;
malcolm_dashboard_export resolves DASHBOARD ids only and answers 200
with an embedded 404 for a visualization or saved-search id, so for
those two this is the only route. For the traffic a query matches, take
the string to malcolm_search or search_dsl.
Three indirections are followed here instead of being handed back: the
query sits in kibanaSavedObjectMeta.searchSourceJSON as a JSON *string*
needing a second parse, the index is a reference NAME that means nothing
until it is looked up in the object's own references[] array, and the
query itself is stored in two shapes — some saved searches use the
pre-7.x {"query_string": {"query": "..."}} object rather than a plain
string. `query` is always the string.
Field names, and which of them appear for which object type, are in the
output schema. Read `language` before reusing `query`: "lucene" and
"kuery" are not interchangeable. On Malcolm's training instance the
index-pattern reference id is the pattern itself ("arkime_sessions3-*");
it can also be a UUID, which this tool resolves with
object_type="index-pattern".
A visualization has no query of its own — `based_on_search` names the
saved search it inherits one from — and the aggregation and panel-layout
blobs behind a dashboard come from malcolm_dashboard_export. Raises if
nothing has that type and id.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| object_id | Yes | The object's id as malcolm_saved_objects returns it, e.g. "bc940221-83d5-416e-a353-dc8fc2f84141". Ids are not unique across types, so object_type has to match. | |
| object_type | No | The object's type, one of: search (a curated query, the usual case), visualization, dashboard, index-pattern. A right id with the wrong type reads upstream as no such object. | search |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |