Hello,
I use TriggerOnObjectMention on class Ticket. If someone writes @NameOfPerson, an e-mail is sent.
When I mention a person in a public log entry in a ticket (user request), the entry is copied to logs of all child tickets. Every copy, every automated log update, triggers the notification too.
What filter or other setting could I use do avoid multiple notification from child or parent objects?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Adjust the logic where it updates the log entries of the child tickets to first set an attribute value (custom attribute maybe) that indicates it's updating from the parent ticket.
Adjust the notification trigger to consider excluding this value ("is_being_updated_by_parent")
Then in the same function as the first step, at the end, update the attribute value of the child ticket to something else again ( is_being_updated_by_parent > "no" )
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In case of my custom logic maybe I wouldn’t even need an extra field like "is_being_updated_by_parent" because I add a heading to log entries that I could use to filter them.
But I just tested the jb-ticket-merge extension and came across came across this behaviour too. When it creates the new log entries, the notification is triggered again.
So instead of modifying all occurrences of log update functions, a more generic solution would be nice. Like a suitable context for the trigger.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I use TriggerOnObjectMention on class Ticket. If someone writes @NameOfPerson, an e-mail is sent.
When I mention a person in a public log entry in a ticket (user request), the entry is copied to logs of all child tickets. Every copy, every automated log update, triggers the notification too.
What filter or other setting could I use do avoid multiple notification from child or parent objects?
First things first - do you even want this kind of propagation of the log entry? If not, this can be removed.
We intentionally propagate log entries from tickets to their parent project. We need this logic.
I suppose you could "hack" around it.
In case of my custom logic maybe I wouldn’t even need an extra field like "is_being_updated_by_parent" because I add a heading to log entries that I could use to filter them.
But I just tested the jb-ticket-merge extension and came across came across this behaviour too. When it creates the new log entries, the notification is triggered again.
So instead of modifying all occurrences of log update functions, a more generic solution would be nice. Like a suitable context for the trigger.