Posted by Docc on June 30, 2009 at 2:05pm
| Project: | Rules |
| Version: | 6.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | feature request |
| Priority: | minor |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
Can`t find anything on it thats why im asking here.
But are there some watchdog events out there for rules?
Comments
#1
No watchdog events, only watchdog actions. What kind of events would you like to use??
This might be an interesting integration. Do you mean something like: "if watchdog create a new log entry for module X with text ZZZZ, trigger a rule" ?
#2
Yes exactly. With some conditions like severity, type and maybe more.
Would be a nice addition. In my case i want to be noticed(mail) when watchdog logs a PHP error.
#3
I created a watchdog event.
You can trigger a rule on a watchdog log entry and then use the various arguments to do conditions. Available arguments are:
- Type (module)
- Message
- Severity
- Log User
- Referrer
- IP
- Link
- Time
With this event trigger you can somewhat integrate all kinds of modules that don't have a trigger. If they generate a watchdog log, you can use that to run a rule.
Here are the patches. Tested and working here. Please review and comment
#4
Im not really sure how to create a condition with this. Should i use the rules conditions to compare the arguments?
Shouldnt there be a watchdog condition for the event?
#5
Yes, use the rules conditions. You would pprobably need the PHP Filter module enables so you can evaluate PHP. Then, in the rules condition on a watchdog event you would find PHP variables for each of the watchdog components that you can compare. You can use a text comparison or a true/false condition based on PHP.
Once you have PHP Filter enabled, enter a condition and then in it you will find a helpful PHP variables tab. All the watchdog variables are listed there. You can then evaluate those in PHP. If you are wondering what they contain, you could create a system message action and display one with say
<? echo "Severity: " . $severity; ?> to see the contents.
#6
Yep that seems to work. Though the $message variable doesnt seems to get run through t() correctly.
For example the watchdog notice for a new page shows: "@type: added %title.".
#7
+1 for this feature. however let's just pass the log entry as whole to rules. Thus you you have to tell rules about it, but that's not hard: http://drupal.org/node/298639
Perhaps let's call it 'watchdog_entry' or so? Thus one could also add token support for it's entry. To get the message translated you'd have to call t() on the message using the variables in $log, see http://api.drupal.org/api/function/dblog_watchdog/6
@loop:
Rules has a recursion prevention, thus this should work for that case too. So you can remove this check.
#8
ok
Totally agree about doing a type. I used the "comment" integration as my guide, so I can figure out how to do a data type quite easily, no problem.
On rules recursion: I know if you trigger a watchdog action from a rule, it will prevent recursion back into the same rule. But, during my test I found another possibility - if it triggered an *error* during the rule execution, and that error was reported by rules itself to the watchdog (ie npt a watchdog action, but a rules error notice), it went into an endless loop until PHP memory ran out. I can't remember exactly how I caused a rules error, but it did go into infinite loop. Let me see if I can re-create in case it is a problem.
#9
@loop: I see, I didn't think of that error logging. However it would be nice if it would be possible to deal with rules error messages too.
Thus, what about moving
<?php//only show the log, if this is no nested evaluation
if (rules_log_evaluation_finished()) {
rules_show_log();
}
?>
in rules_evaluate_rule_set() before the rules_log_evaluation_clear() call. I haven't overlooked something this should fix it thus the rules recurions prevents would prevent a loop. If that works, don't forget to add a comment to remind us of that later on.. :)
#10
Wouldn't it be better to support the events that would cause a log message to be written when/where they occur? Parsing log messages seems like an edge case. Perhaps this issue could be modified into these feature requests:
- Condition: user's ip address
- Condition: referring page
- Condition: time at which event occurs
Severity seems like it'd be a cool concept to integrate, but how would rules keep track of what's important, and more importantly, why? I think that's a level of meta analysis that rules doesn't yet have any use for.
... Just to mess with your mind a bit (the Drupal part, at least): imagine for a moment that the action that wraps around drupal_set_message() were the standard method for calling it. Then whenever a programmer or site builder were to setup a log message, they could also send an email, or update a cck field, or whatever using the same framework. I think if that were the case, then it'd feel weird to trigger a rule based on a log message caused by an action when you could just add another action to the execution list.
#11
>Event: Watchdog log message is created
We have support for that event in 7.x-2.x already! :)
>- Condition: user's ip address
- Condition: referring page
- Condition: time at which event occurs
Those would be best supported just by adding entity metadata for system:time, system:page ,...
#12
Automatically closed -- issue fixed for 2 weeks with no activity.
#13
I tried to implement the code from #3 but I am unable to print the variables to my email, what am I doing wrong
This is what I have in the email that I am sending out.
[type:user-name] has downloaded a file
The message was
<?phpecho $message
?>
<?phpecho $time;
?>
Please help!
#14
@ginga8: sorry to say, but I guess it's pretty obvious, it'll be pretty hard to get support for unsupported code that is now deprecated for 7.x. For 6.x, the best that could happen is a backport, but we'll have to wait and see if anyone picks it back up.
Postponing to see if anyone takes up the backport.
#15
+1 for adding the "Event: Watchdog log message is created"
#16
hm, what would be the use-cased for that in 6.x? As we have no data selectors, nor any pre-defined tokens for watchdog log entries, what would you do with them?
#17
I think there might be cases in which the site maintainer/"sysadmin" would like to get notifications for watchdog error messages by mail.
Do I miss anything with this request ? Can it be done already and I just couldn't find it ?
#18
>I think there might be cases in which the site maintainer/"sysadmin" would like to get notifications for watchdog error messages by mail.
I see, but this won't be possible without writing PHP code. So if the event wouldn't be usable without PHP at all, I see no value in backporting it.