[sentinel_one] Update Deprecated Visualizations and Enhanced Dashboards - #15437
Conversation
… in the existing dashboards.
|
Pinging @elastic/security-service-integrations (Team:Security-Service Integrations) |
There was a problem hiding this comment.
We should move the filters from the dashboard to the visualisations so that users do not remove them accidentally.
| "links": [ | ||
| { | ||
| "destinationRefName": "link_81cc8355-af43-42be-a636-6650086f4e79_dashboard", | ||
| "id": "81cc8355-af43-42be-a636-6650086f4e79", | ||
| "label": "Activities", | ||
| "order": 0, | ||
| "type": "dashboardLink" | ||
| }, |
There was a problem hiding this comment.
We would need to apply fix from: #15016 as we don't want to carry the filters/queries from previous dashboards, it may even break them.
By default the links panel carries the filters, so disable the option and re-export dashboards.
cc: @efd6, I think this could be applicable for all integrations when migrating to links panels: #15075
There was a problem hiding this comment.
This is a very good reason why filters should be on the visualisation and not on the dashboard. I think that we should use the filters and queries from the origin, but that those filters should only be filters that the user has applied and the filters that are required for correctness are not affected.
There was a problem hiding this comment.
If we enable it, in scenario when users apply the filter/query on a custom field, say sentinel_one.threat.fieldA: true on Threat dashboard, and when the user navigates to alert dashboard the experience would be broken (because this custom field doesn't exist in alert data stream).
Is that expected correctly?
There was a problem hiding this comment.
Sorry, can you clarify? If the user applies a filter and it doesn't work, they are the person who has applied it and so should be aware of its presence, so they can rectify it. ISTM that it should not break, but if it does the solution would be to remove it. On the other hand, if an analyst is working on a train of thought which involves a specific filter, and wants to correlate two dashboards, then keeping the filter in place makes sense. Now, this may not be the situation always, but it is easier to remove a filter than it is to have to replace it when the system has removed it. I don't think there is definitively correct default, but IMO leaving them in place makes more sense.
There was a problem hiding this comment.
I haven't thought from an analyst POV, it makes sense that way. Thanks!
We can let it be at default (carry filters/queries) for now.
There was a problem hiding this comment.
@mohitjha-elastic, can you please revert the change for links panel and allow them to carry the filters?
1. Add filter at viz level. 2. Remove links of exporting filters in nav links of dashboard. 3. Made the width same for all the nav panels across all dashboards.
🚀 Benchmarks reportTo see the full report comment with |
|
kcreddy
left a comment
There was a problem hiding this comment.
LGTM. Thanks @mohitjha-elastic
💚 Build Succeeded
History
|
|
Package sentinel_one - 1.40.0 containing this change is available at https://epr.elastic.co/package/sentinel_one/1.40.0/ |




Proposed commit message
Checklist
changelog.ymlfile.How to test this PR locally
Related Issue