Forum Discussion

asikarwar's avatar
asikarwar
Icon for Neophyte rankNeophyte
10 months ago

Resource Property Filters on the New UI Preview

What exactly is “Resource Property Filters” in the new UI Preview, I tried and tested by creating two filters but I could not make them interdependent or linked to each other example based on what yo...
dashboard
filter
  • LMjosephBrett's avatar
    LMjosephBrett
    10 months ago

    Also, i’m not sure why, but not all properties are available. I just tried adding a filter for the property we use as our tenant identifier. Not sure why it couldn’t find it because it’s guaranteed to be on every device. It is an inherited property so maybe that’s it?

    Hey @Stuart Weenig 

    That is correct, in the current iteration of the resource property filters, as well as the new resource explorer they do not work with inherited properties.  

    As to the specific situation you said wasn’t working.  If you have set up your tenant identifier to match that property in the Account Information → Portal Settings section of your portal.  You can use the property “system.tenant.identifier” to group your resources by tenant.  

    As far as other custom properties go, I know this is not a perfect solution, but there is always the option to make a very simple PropertySource to turn your custom inherited properties into auto.property making them usable in the filters.  The below code for example could be used to grab an inherited location property and turn it into an auto.property. 

    println("location=${hostProps.get('location')}")
     

Mike_Aracic's avatar
Mike_Aracic
Icon for Employee rankEmployee
10 months ago

The simplest way to understand the way resource property filters work is to think of them working much like the role-based-access control does for devices. When you set up a dashboard, all the widgets have all their own filters which determine what data is going to be shown. (Those filters can be either hard-coded in the widget settings or, usually preferably, driven by dashboard tokens) What the end-user actually sees, however, is limited by the groups of resources (and websites) that they have view access to through the “users and roles” assignments associated with their portal user account. Aa a resuly, you and I might see the data from different subsets of resources on the same dashboard. For example, our top 10 CPU % graph on a custom graph widget might have different members because you can see some resources I can’t see, and vice-versa. 

The resource property filters use the same kind of logic to change the data on a dashboard by limiting the view to a subset of resources that you can see;  they must both pass the RBAC check and that match the expression in the resource property filters. If you can see it, and it matches the property filters, then the data will then be put through the same filters as the widgets on the dashboard.

The idea is that this gives a quick way to use resource properties to explore data without having to set up every possible resource group. For example, you might have a lot of AWS tags, too many to bother to set up dynamic groups for all of them, but sometimes want to see a view of just one of them on a particular dashboard. If you want them more to be more permanently attached to the dashboard, you can set up specific resource groups or include them directly in the widget filters. (Although I agree, it would be nice to have a way to get some commonly used ones quickly)

It’s not designed to filter based on the time-series data contained in the datapoints (The top % options in the custom graph widgets can be useful for this kind of viewing), but I have seen users use a PropertySource to periodically evaluate a resource’s datapoint data and put their result in a device property, usually to allow for data-based dynamic grouping, but it could also work for this, so that might be worth exploring, depending on what you’re trying to do.