8 Event notification 31
8.3 Notification rules
The rule system is centered around two kinds of entities:
• condition, which determines if a rule is matched, and
• action, which determines what happens if it matches.
Notification rule configuration
A condition is a Lua expression, while rules are Lua blocks (may contain several statements).
Roughly, the condition/action table is equivalent to:
if condition1 then action1 end
if condition2 then action2 end
if condition3 then action3 end
...
However, an important difference is that if a condition would cause an error, the condition is considered false instead;
the corresponding action not taken, but the rule check goes on.
Additionally, an empty condition is equivalent to true, and the corresponding action is unconditionally taken. To
disable an action without deleting it, you can use an explicitly false condition false or a condition that's not a valid
Lua expression, e.g. -. To keep the condition text, you can wrap it with false and (...).
Rules are applied from the first one to the last one, so order is important. The "Operations" column contains buttons
which make manipulating rule order easier.
Though you can filter events by the type identifier, it's not necessary in many cases. For example, the condition
auth_allowed==false will match only dli.auth.login_denied events, as auth_allowed is set to
false for those events only. This is notably distinct from a not auth_allowed condition, which will match all
sorts of messages which don't have an auth_allowed property.
Tricks which allow running code in the condition (as opposed to the action) are possible but discouraged.
DLI DIN4 User’s Guide: 20170809T111540Z
To Next Page
Loading...