Hello, sorry for the late reply , I will add some thoughts, and structure them as I can.
For me, this questions relates to GrapesJS(HTML editor), Templates, emailing add-on(e-mail history), and bpm add-on (e-mail sending element).
With CUBA 7.2, I was sending e-mails from the bpm process, using a bpm script element to map the email template parameters and send e-mail. This was hard for users because they had to make email template, and then script the parameters map, and invoke the beans to send email. The positive was that e-mail templates have ignore if null option, which is very important if you want to re-use same template for different bpm process branches, otherwise, you must make copies with minute differences which are later harder to manage and update.
Jmix BPM brought bpm email element, and I use that, but I still need a script element to assign emailing list to it. There is text editor for both text and HTML content, so HTML content needs to be done with an outside tool. I use Komposer https://sourceforge.net/projects/kompozer/ which is simple and without bloat, and then paste that into bpm email element. It would be nice to have HTML editor on the email element, with option to show both HTML rendered and as text.
Problem with bpm element is that it does not have the option to ignore if null, so it will break unless you use something like this ${variables:getOrDefault(someVariable,’’)} . There should be a checkbox ignore if null on the bpm element and all the normally referenced process variables ${variablle} can be interpreted by this without user having to code, or if you will put e-mail template add-on with that function there, it would be convenient to have visual process variable to email template mapper.
GrapesJs seems to produce a bit bloated HTML code, and the project itself is moving to some sort of “studio.” It definitely looks awesome, and it’s nice to have the option to offer this to customers who need it. However, a normal customer does not want complexity; they just want a simple e-mail template to write and insert some logos and disclaimers—something like you can find in content management systems.
E-mail history view can be improved with HTML component because you need to scroll down a lot to find and press Show content button. I think that this functionality needs to stay to preview it in the browser tab itself like now, but also additionally to use HTML component to render the HTML if it is HTML content, and text if it is text. Probably the same HTML component that would be used in bpm email element.
Kind regards,
Mladen