Kami
commented
8 years ago Thanks for the feedback.
That's indeed an interesting idea (allowing user to provide a callable / path to the module with a callable) and something we have already briefly discussed in the past.
As you have pointed out, you can already achieve that inside the action (workflow), but yes, having it inside the rule could make more sense in some situations.
In general, I would be OK with supporting like that in the future, we would just need to be careful users don't abuse this feature and start putting stuff inside this comparison function which should really belong elsewhere.
Another potential problem with this approach is negative security implications and performance overhead. If we decided to support that, it's unlikely that we would introduce sandboxing in the first iteration so this could have negative security complications.
For example, now the user which can create rules can also execute arbitrary code in the scope of the rules engine - in fact, that's why we decided to go with a custom DSL to begin with - to avoid potential negative security implications.
So having said that, doing it the right way (with sandboxing and all) would be quite a decently sized task, but we could maybe introduce some feature flags (e.g. user can opt-in into this feature in the config and / or we introduce another RBAC permission type) to begin with.
userindia77
It would be nice to split off the rule criteria so we can code our own and return a true/false back into the rule engine. This would allow more advanced checking that could be included in packs.
Example. Check to see if an open ticket already exists in your ticketing system.
I know I can do this in either a custom sensor or action, but it makes more sense to be in the criteria section of the rules.