Using JIRA velocity email templates with custom event listeners

I’m working on customizing JIRA notification system to send emails to additional recipients when specific issue events occur. I’ve set up an event listener that captures issue events successfully.

public class CustomIssueEventHandler implements InitializingBean, DisposableBean {
    private final EventPublisher publisher;

    public CustomIssueEventHandler(EventPublisher publisher) {
        this.publisher = publisher;
    }

    @Override
    public void afterPropertiesSet() throws Exception {
        publisher.register(this);
    }

    @Override
    public void destroy() throws Exception {
        publisher.unregister(this);
    }

    @EventListener
    public void handleIssueEvent(IssueEvent event) {
        // Custom email processing logic goes here
    }
}

For the email template processing, I’m trying to leverage JIRA’s built-in velocity templates:

ApplicationProperties appProps = ComponentAccessor.getApplicationProperties();
String siteUrl = appProps.getString(APKeys.JIRA_BASEURL);
String encoding = appProps.getString(APKeys.JIRA_WEBWORK_ENCODING);

VelocityManager velocityMgr = ComponentAccessor.getVelocityManager();
VelocityParamFactory paramFactory = ComponentAccessor.getVelocityParamFactory();

Map templateContext = paramFactory.getDefaultVelocityParams();
templateContext.put("siteurl", siteUrl);
templateContext.put("timestamp", new Date());
templateContext.put("issue", event.getIssue());

String emailContent = velocityMgr.getEncodedBody("templates/email/html/", "issueresolved.vm", siteUrl, encoding, templateContext);

SMTPMailServer server = MailFactory.getServerManager().getDefaultSMTPMailServer();

Email notification = new Email("[email protected]");
notification.setMimeType("text/html");
notification.setEncoding("utf-8");
notification.setBody(emailContent);

try {
    server.send(notification);
} catch (MailException ex) {
    ex.printStackTrace();
}

The template renders partially but I’m missing styling, images and internationalization elements. What’s the proper way to include these components when reusing JIRA’s email templates? Is there a better approach than manually processing velocity templates?

looks like your missin some velocity context variables that jira usually adds automaticaly. try adding i18nBean and webResourceManager to your template context - thats what handles the styling and translations. also check if your usin the rght template path, might need to be absolute.

I ran into similar issues when implementing custom JIRA notifications. The missing styling and i18n components happen because you’re bypassing JIRA’s standard email rendering pipeline. Instead of calling velocityMgr.getEncodedBody directly, try using the NotificationRecipient and TemplateIssueNotificationEvent approach. Create a custom notification event that extends the base notification classes, then let JIRA’s email subsystem handle the template processing. This ensures all the necessary context variables like applicationProperties, customFieldManager, and dateTimeFormatter get injected properly. You’ll also want to register your custom templates in the same directory structure as JIRA’s built-in ones so the resource resolution works correctly. The manual velocity processing you’re doing skips too many initialization steps that JIRA normally handles behind the scenes.

The issue stems from missing context components that JIRA’s native email system automatically provides. You need to populate the velocity context with additional beans beyond the default parameters. Add the I18nHelper for translations and WebResourceManager for CSS/JS resources, and ensure you’re setting the correct locale context. Instead of manually building templates, consider extending NotificationSchemeManager or using the existing MailThreadManager which handles proper context initialization. The built-in email infrastructure already manages resource paths, encoding, and internationalization correctly. For images and styling, verify that your base URL configuration includes the proper context path and that static resources are accessible from email clients. JIRA’s default templates reference resources with absolute URLs that need proper resolution in the email context.