BACKPORT :: Event: Watchdog log message is created

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" ?

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

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.

+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.

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.

@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

    //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.. :)

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.

>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 ,...

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 echo $message and it was downloaded at echo $time;

Please help!

@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.

+1 for adding the "Event: Watchdog log message is created"

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?

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 ?

>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.

For those searching for it: http://drupal.org/project/logging_alerts