MessageTemplates parameter migration from CUBA's EmailTemplate

Support
,
#1

Hi Jmix Support team,

My application is using the EmailTemplates add-on in CUBA, and I am trying to migrate it to use the MessageTemplates add-on in JMIX instead. But I encounter a roadblock while doing so, will dive deeper into details from here onwards to explain the situation.

{5DC04ECE-6E5D-4185-B6B1-CDED7AD4EDFA}
{26CEB89D-321A-4C69-850C-76053F6905DB}

As shown above, currently my template has Parameters that are defined for it, which are mainly defined in the EMAILTEMPLATES_EMAIL_TEMPLATE.REPORT_XML column. Right now in JMIX’s MSGTMP_MESSAGE_TEMPLATE table, there is only the CONTENT column available for the HTML code of the template but no similar columns to replace the usage of REPORT_XML column to define my parameters. There is a MSGTMP_MESSAGE_TEMPLATE_PARAMETER table available for this but it would make it very troublesome to migrate these 1 by 1 as I have at least a few hundreds of templates in the system this way with existing clients using them, please provide some suggestions to solving this or what is the ideal way to migrate from EmailTemplates to MessageTemplates that Jmix team would recommend to existing CUBA users, especially with the current data stored this way.

Furthermore, another problem is that in Message Templates we do not have a way to define data like FROM / TO / CC / SUBJECT etc. now, where should these defined previously in the EmailTemplates go? Will EmailTemplates be introduced back again in the future as it seems like an important functionality for enterprise applications to have?

Best Regards,
Wei Jian.

#3

Hi!

Thank you for your question.

The previous implementation of the EmailTemplates add-on was based on the functionality of the Jmix Reports add-on. Specifically, when generating messages, a report generator was used to populate messages with parameters.

The REPORT_XML column contained the serialized value of the report used to generate the message. Since the MessageTemplates add-on a standalone and independent add-on, it has no such dependencies and tables.

Since the add-on now performs one single task - generating messages, other properties such as FROM / TO / CC / have been removed from it.

You can store these properties however you like. For example, by creating separate tables in the database. A special Email add-on is used for sending messages. So you can generate a message from a template and send it to the addresses you need using the Email add-on API.

You could try implementing a single-run spring bean that will convert your EmailTemplate to MessageTemplate entities. You could create this bean as a JMX bean and run it at runtime to migrate your customers’ applications. In this case to process REPORT_XML, you can use the build-in report serialization function: io.jmix.reports.ReportsSerialization.

Best regards,
Dmitriy