The reporting functionality of the compliance has received an upgrade. The form has been completely renewed. The 'Saved reports' have been replaced by 'Report templates' allowing the user to save the report-type and all its filters for re-use.

An additional level of reporting has been added to the Nodes and the Policy reports to include Rule-level details or not. You can now select four types of reports: - Nodes - Nodes with rules - Policies - Policies with rules

Once you select a report with valid filters a preview of the results will appear in real-time. Once you click on 'Show report', you get to see a list of all policies, nodes and rules, depending on the report type and filters you selected, including details for the non-compliant ones. You can download this in a csv file, both in UNIX and DOS formats.

Report details for multiconfig rules have been updated to become more clear and detailed.

See the Wiki article on Compliance Reports

There are several events that can trigger a compliance check for a node. A retrieved configuration with a detected change is not the only one. Updates to the stored node details using the front-end is another. But also changes to the node-groups where it is now part of could form a trigger. The same applies to changes to Policies, rules and conditions that apply to the node.

Unfortunately, this intended behaviour was not consistent for each of these changes. Compliance checks now get triggered whenever anything in the process is modified (policies, rules, conditions, nodes, node groups, cmdb nodes) or when a job triggers a configuration change.

The XCH API for compliance reporting has been simplified. Instead of cmpl_report and cmpl_report_raw, there is just the command cmpl_report, which handles everything.

Also see the Wiki article on Requesting Compliance Reports

Compliance Rules that select their configuration sections (blocks) based on 'blocks' don't have a Rule-end field anymore, since it has no practical use.

As the 'block' definition implies, the end of the configuration section is automatically detected using the vendor's indentation and syntax.

Service-types use aliases to located or created objects like nodes, ports, subnets, etc. The aliases are used to give these objects a handle or name for further manipulation.

When working with Service-types, these aliases will on occasion to be renamed. Previously, when renaming an alias, ALL references to the alias were modified. But as lines can be copied and moved, the users intention was more likely to change the alias into a new reference.

Therefore, this behaviour was changed to rename the alias from the current line onwards only. Any earlier references to that alias name will remain unchanged.

Various tools use popup browser windows to provide the use with requested details or reports. These windows could be closed using the 'X' of the window or its 'close' button. Now, for ease-of-use, these windows can be closed using the 'esc' key too.

A bug in the compliance signalling where signals weren't sent out when a node stayed non-compliant is fixed. Compliance signalling sends per-node messages to external systems on compliance events using syslog, snmp-traps, email or rest-api.

The compliance dashboard has been made more stable with unexpected and illogical entries removed.