Get link to result #1100
Get link to result #1100
Conversation
|
Given that we know what index the event is in, and what the event's ID is, there's 2 cleaner ways to do this:
|
|
I think there's value in being able to share a link in the context within which it was seen, so using the same dashboard that was used to find it makes sense. |
…eliminate looping and put the event in the center of the search.
Don't do any replacements if there are already ARGS references in the dashboard.
Conflicts: src/app/filters/all.js
|
This is awesome @awheeler We have been 'hacking' this in on our own for a while now. This feature is invaluable to our developers and I appreciate your effort here. |
|
I think Alex has a good point: being able to send a link to an event and have it display on the same dashboard the send was seeing when she/he sent it is the best experience. Linking to the event directly in Elasticsearch works fine for those of us comfortable visually parsing JSON, but these events will be seen by a wide audience and not all of them comfortable with raw text in a browser window (or a shell for that matter). Generating a new dashboard just for that single event is a better solution, however it presents of problem that the recipient of the link will see something different than the sender. Yes, it's only one event so there won't be much displayed on the page, but for the sake of consistency, it would be nice to have the link to a single event show on the same dashboard the send is seeing and not a generic one. |
|
There may be value in it, though given it would only show a single event, thus none of the charts would really have much on them, I don't quite see it. I'm strongly against the addition of hardcoded query parameters here, given that they would break many users custom dashboards. The current implementation also forces the first filter to be a time filter, though doesn't actually check if it is before setting to/from keys on it. It also hard codes the time field to be @timestamp. It also assumes that the data being shown has a time field at all, which many do not. I could see this implemented as a scripted or templated dashboard that we ship with Kibana, but attempting to hardcore a bunch of parameters to serve this use has far too many side effects. |
|
Can you show me some example code where an index plus a query is sufficient to display an event? In looking at logstash.js, I have passed index on the command-line, but this doesn't seem to actually set the interval as well, so I get no events displayed, but perhaps I'm doing it wrong? - |
| @@ -296,6 +296,20 @@ function (angular, $, kbn, _, config, moment, Modernizr) { | |||
|
|
|||
| var renderTemplate = function(json,params) { | |||
| var _r; | |||
| var _json; | |||
| if(!json.match('ARGS\.(to|from|style|query)')) { | |||
There was a problem hiding this comment.
Don't make changes to dashboards that are already doing things with to/from/style/query.
|
My intent was to not break pre-existing dashboards, but since I don't have access to any other than stock ones, I may be making erroneous assumptions. My original submission did break them, but that should no longer be the case. |
|
In talking to Rashid, it appears that there are several issues here:
|
|
I'm going to re-architect my repo branch names to better support multiple pull requests against this repo, so I'll be closing this pull request, and then issuing a new one. |
This implements the feature request #717.
Additionally, it adds consistent URL arg support to all dashboards.