Recent Discussions
Dependent Alert Mapping - defining the originating alert
In the current Dependent Alert Mapping feature, alert suppression will only take place if an upstream device has an alert for the Ping or Host Status datasources for overall reachability. There are many cases where the upstream device will not be completely down, and instead will have an alert for an interface or BGP peer going down. This will still impact downstream devices, but Dependent Alert Mapping does not work correctly in these cases because the upstream device was not technically "down". I would like to request that the Dependent Alert Mapping feature give us the option to allow other types of alerts be considered when it determines what alert is "Originating" vs "Dependent". Ideally we would be able to define this when we are defining entry points. We could have the option of only using Ping or Host Status like the feature does today, or we could choose to select our own datasources for determining what the "Originating" alert is. This would allow us to get a lot more granular and make the feature a lot more flexible/powerful than it is today.
Different options for "Delete Instances..."
Recently had this discussion with a customer and it was brought to my attention to raise a feature request for this. Customer is requesting that there are more than two options for deleting instances in a module. Instead of "delete immediately" or "delete after 30 days", they are suggesting a few more options such as "delete after 7 days" or "delete after 14 days".Shared Dashboard Filters/Dropdowns
In the new UI there is a feature to build dashboard filters that allow you to narrow down which resources are displayed based on properties. So I can have an overall health dashboard, and add a "By Location" filter to allow me to use a dropdown to select which site to display data for based on a location property. The filters work pretty well, but the problem is they are only saved at the user-level. So every single user who looks at the dashboard needs to manually create and then save the filters themselves. Not a very good design if you ask me. My feature request is to allow us to save dashboard Views at the dashboard-level. So I as an LM admin can create a useful dashboard View with filters/dropdowns, and then when I save it the View can then be used by other users who may not be as comfortable creating filters in LM. Allowing us to save dashboard Views at the dashboard-level would really increase the accessibility of this feature so that the average LM user can just open a dashboard and use the filters that we have already defined.
Dashboard Interlinking
Hi Team,<br><br> Is there a feature available to interlink dashboards? As per our requirement, when clicking on a device in the dashboard, it currently redirects to the resource tree info page. However, we need it to redirect to the graphs page instead.<br><br> If this isn't feasible, our alternative is to redirect to a new dashboard, passing the device name as a token.<br><br> Regards,<br> SreekanthAllow Read-Only Accounts To Stay Logged in
We use multiple TVs as dhasboards, we currently have individual widgets on them, we would like to display dashboards on the TVs. We were informed by an engineer that we cannot select accounts to stay logged in only all accounts. We would like the option have a ready-only account stayed logged in so we can display dashboards.
