philrz
commented
1 year ago A community Zui Insiders user also asked about this on public Slack. In their own words:
is there a way to use the same "Pin" for the pool for all saved querys? it is annoying to select multiple querys and have to select the pool for each one
I suggested they review this issue and #2478 and provide their input on how they'd like to see this work.
One of the workflows I became accustomed to in the classic Brim app was the ability to select a single pool, then single-click each of several Saved Queries and see what results came up. This was particularly handy in security use cases when quickly seeing which queries returned some/zero results gave a quick sense of the essence of some pcap/logs (any alerts? any Windows SMB activity? etc.) I've shown an example of this in the attached video.
https://user-images.githubusercontent.com/5934157/203430159-5e27905a-8316-4010-9de0-885210e488ba.mp4
Thus far Zui doesn't yet have quite the same smooth workflow for this.
frompins and their referenced pools are currently preserved as part of a Saved Query. This means that applying several Saved Queries against a new pool requires setting/replacing the contents of thefrompin each time in order to see the result. This means one or more additional clicks compared to what we had in Brim, such as needing to click the pool name in thefrompin pulldown or clicking to the Pools list and doing alt-click. These are shown in the attached video.https://user-images.githubusercontent.com/5934157/203430529-2ff22507-fefd-4c47-b6e2-42253de9a7bc.mp4
Before opening this issue, I searched and found existing issue #2478, and the solution proposed there might do the trick. However, with the alt-click functionality in the Pools list fresh in my mind, I thought of yet another approach that might work instead/also: When on the Queries list, alt-clicking on a Saved Query entry could copy just the query text from the Saved Query but leave any existing pins (e.g.,
from) in the Query Session in place. This might have some slight advantages over the #2478 approach because it could allow saving the query with a hard-wiredfrompin but effectively override it when needed. I could see this being handy for use cases like if there's a "production" pool for which a query was originally written and you frequently want to apply it against that pool (so, click without alt so it's executed with its pre-populated pool name reference) but you also want to be able to easily apply it to many staging/test pools (now you alt-click).