how to find the trigger which send email for perticular workflow?
Is it possible to extract the all trigger for review the parameter setup? We have thousand of trigger defined and really difficult to identify particular trigger.
I wanted to stop notification for specific users from the group.
Hello Shriram Patil,
If you have DEBUG logging turned up to 10 on your server, then when a rules based trigger is fired by an edit, you can search the log/server.log file for the lines "Considering trigger:", which will iterate through each trigger to determine if it will be fired. Any trigger which might be will have that line end with "run: true", while those that are right out will end with "run: false".
In the case of "run: true" lines, there will be a subsequent line which lists the rule (in terms of field/type IDs rather than their actual names, with a value of "'" (an apostrophe) indicating a post-edit value as opposed to a pre-edit value, and will evaluate in more detail if the rule should run. These lines will end in "will not run." if they won't run.
Let us know if that helps or if you need more information.
Regards,
Kael
You can get a list of all triggers with particular fields using the "im triggers" command. For example, if you want to see the trigger names, rule, parameters, and script, you can run:
im triggers --fields=name,rule,scriptParams,script
Adding the --fieldsDelim option can make the data easier to parse. Once you have the output, you can use a file search such as "grep" to find the relevant triggers for this group, or load the data into Excel to filter. Note that you may need to manipulate the data further before loading into Excel as some of the output, such as scriptParams, rule and description, can be on several lines.
Short term this doesn't help, but longer term it has been immensely useful for a number of purposes.
At the beginning and end of every trigger script, I output an eyecatcher to the log. I tend to use a dedicated logging category for this. I output the name of the trigger, the name of the script, the user that caused the event (where I can), and the ID of the item in play at the time. When a trigger event happens that I need to find, I look for these eyecatcher messages in the log.
One other benefit to doing this is it also tells me when there are triggers that are taking longer than I think they should Being in the log means that you have the start/end timestamp as well.
I can't emphasize this suggestion of Jim Bates enough. There are multiple advantages here:
These sound like small things, but when you're trying to debug an issue involving triggers, these small things can make resolving the issue much simpler.
Regards,
Kael