Read one saved object's query and filters
malcolm_saved_object_detailRead-only
Retrieve the underlying query, filters, and resolved index pattern for any saved search or visualization in Malcolm.
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 141 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 — a sixth of one install's saved
searches used 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 this Malcolm the index-pattern
reference id is the pattern itself ("arkime_sessions3-*"); elsewhere it
can 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
TableJSON 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
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |