Validity Update Rules

Assuming we want to make a report that is valid for all device contexts whose description has the Collector_ prefix, we may use the following Validity Expression:

startsWith({.:info$type}, "device.") && startsWith({.:info$description}, "Collector_")

This Validity Expression checks the type and description fields of the info variable, which is available in all contexts. The context type never changes, but its description may be edited at any time. If we want our report to be added to any context right after its description has been changed to one starting with Collector_, we need to add the following Validity Update Rule:

• Mask: users.*.devices.*

• Event: infoChanged

• Target Expression: <Not Set>

This rule will be activated every time an infoChanged event occurs in any device context. This actually happens when an info variable is changed, e.g., when a context description change occurs. The rule will cause Validity Expression recalculation for the device context whose description was changed, and if the new description starts with Collector_, the Launch Report action will be added to the device.

We need to make a dashboard that can be opened only for devices that belong to a certain group. We have to use the following Validity Expression:

aggregate({users.admin.devgroups.test:visibleChildren}, "{env/previous} + ({path} == '" + dc() + "' ? 1: 0)", 0) > 0

This Validity Expression uses the aggregate() function to list all rows in the visibleChildren table of every context. If the path field in the current row is equal to the path of the context, whose validity is being checked (returned by the dc() function), this context is deemed found among group members and thus valid. In this case, the aggregate() function will return 1 (and 0 otherwise).

If we want our dashboard to be registered in the context menu of devices right after we add them to the test group, we need to add the following Validity Update Rule:

• Mask: users.admin.devgroups.test

• Event: visibleChildAdded

• Target Expression: {path}

Once a new member is added to the group, the visibleChildAdded event will occur in the group context. Target Expression refers to the path field of this event, and thus, the Validity Expression will be recalculated for the newly added member, pointed by the path field of the event. Since it will always return True, the dashboard's Open Dashboard Action will be added to the device.

To ensure that dashboard is no longer valid when devices are removed from the group, we need to add another Validity Update Rule:

• Mask: users.admin.devgroups.test

• Event: visibleChildRemoved

• Target Expression: {path}

The only difference is that at the time of the visibleChildRemoved event, the Validity Expression will already return False for the context pointed by the path field of event data. So the dashboard will de-register itself from any device that was excluded from the group.