|
Keeping History of Object Changes |
Top Previous Next |
|
While AggreGate database should be periodically backed up, it might be useful to keep history of important system object's changes. For example, if a certain widget has complicated template, it may be very helpful to track down every change to detect and revert erroneous modifications. This short tutorial explains how to activate and view historical changes for any system object or object group. 1. Finding Out Object Context Path At first step, it's necessary to figure out context path or context mask of objects those history should be stored. Point mouse over the object node in System Tree to view context path in the tooltip. In the below image, the context path of Ping Time Chart widget is users.admin.widgets.chartAvailabilityPingHelper.
Right-click on the widget node and select Copy ( 2. Enabling Change History Storage Every time a certain "user-level" property of any system object is modified, AggreGate Server generates a change event. We need to enable historical values storage for this event to be able to access object property change history. The generic way to enable persistent storage for AggreGate events of any type is using global Event Expiration Times table. To access this table, right-click on AggreGate Server node (
Switch to Event Expiration Times tab and click Add Row icon (
Click OK to finish global configuration editing. You don't need to restart the server after this change. 3. Viewing Change History Once the change history is enabled, you may edit properties of your object as usually. To access the change history, right-click on a property in Properties Editor and select View Variable History (
The history will open in a new window:
|