Ticket EMail Templates

In the file /htdocs/core/triggers/interface_50_modTicket_TicketEmail.class.php, emails are automatically generated and sent when tickets are created, updated, assigned, or closed.

Problem:
These emails cannot be customized through the Email Templates feature (Setup → Emails → Email Templates). There do not appear to be any hooks in the file that would allow modification of the email body or subject. Instead, both the subject and message content are assembled directly within the trigger file and then sent.

As I understand it, simply creating a custom trigger file in a custom module and sending my own emails from there would result in two emails being sent for the same event, because the original trigger would still execute alongside my custom one.

Question:
Am I overlooking the intended way to customize these ticket notification emails? What would be considered the best practice here?

I would prefer to avoid modifying the core file and having to reapply changes after every Dolibarr update.

You’re not missing a setting — those notifications are assembled inside the trigger and bypass the Email Templates screen entirely (there’s an open report, #31999, where even the template’s sender address is ignored). And a second trigger on the same events would double-send, as you suspected.

The upgrade-safe route is disable-then-replace: turn off the native notifications on the Ticket module config page (Home > Setup > Modules > Ticket), then add a small custom module whose trigger fires on TICKET_CREATE/MODIFY/ASSIGNED/CLOSE and sends mail built from an Email Template (make_substitutions() + CMailFile). No double-send, nothing in core to re-patch each update.

Just confirm which toggle silences each mail on your version first. I build these templated ticket-notification setups fairly often — it’s the only approach I’ve found that survives upgrades cleanly.

Ali — Dolibarr AI Consultant / SiliconBlaze.com

Thanks for the detailled info. I will have a go at this during the week

For anyone interested, the solution to this was fairly simple in the end:

  1. Disable the original Notification Emails by adding a hook to the ticketcard context in your custom Module config, then add this to the hook you choose, I used the doActions hook:
if (in_array($parameters[‘currentcontext’], array(‘ticketcard’))) {  
  if (!$error) {    
    $object->context[‘disableticketemail’] = 1;   
    return 0;  
  } else {    
    $this->errors[ ] = ‘Error message’;    
    return -1;  
  }
}
  1. Enable Triggers in your module config, I then simply copied the original ticket trigger file (core/triggers/interface_50_modTicket_TicketEmail.class.php) to custom/myMod/core/triggers and renamed the file to interface_99_modTicket_TemplatedTicketEmail.class.php, also rename the class to InterfaceTemplatedTicketEmail.
    At this point you can check if the trigger gets recognized. Dis- and enable your module to register the triggers. Go to Start→Admin Tools→About Dolibarr→Triggers You should see your new Trigger with a checkmark in the active column.
  2. Create a new Email Template like any other Mail Template you use.
  3. Remove the condition that checks for empty($object->context[‘disableticketemail’]) from the runTrigger method, in order to still send Mails even if this flag is set. (~LL 214 TICKET_CREATE and ~280 TICKET_CLOSE)
  4. In the composeAndSendCustomerMessage method get new template and substitute the content. Add this just before instantiating the CMailFile ($mailfile = new CMailFile(…))
$formmail = new FormMail($this->db);
$formmail->setSubstitFromObject($object, $langs);
$template = $formmail->getEMailTemplate($this->db, ‘ticket’, $user, $langs, 0, 1, ‘YourTemplateLabel’);
$html = make_substitutions($template->content, $formmail->substit);
$htmlBody = str_replace('__MESSAGE_CUSTOMER__', $message_customer, $html);

I am not sure if I need to adjust anything, but the first tests, sending templated mails to the customer on create/close worked like a charm.

Its fairly trivial to repeat step 5 for the Assignee and Admin Messages so I wont go into that.