what-is-this-email-body-in-the-gui? about the-app

[luismanuel001]

Email Body seems to be only shown when the email.sendhtmlemail==false in the /template/config.json, and it sets the email.text variable (the text only email body).

[distributev]

In both situations sendhtmlemail true or false the email preview should be correctly aligned on top right side - on top of the document preview. (actually I see in the screen-shot it's already there - so I don't understand what is this thing on bottom left under the form)

[luismanuel001]

I'm not sure why that is there either, it comes from the previous implementation, I'm guessing it let's you edit the text only email body when sendhtmlemail==false, but I can just remove it if you want, or what should I do about it?

[distributev]

Email should be previewed (compiled) on top right on top of document. Just checked the old mail-merge (though I only have sendhtmlemail==true) and the HTML preview comes correctly on right top just above the document preview.

When the sendhtmlemail==false then the same should happen but it will only show a compiled plain text email which the used can edit if he chooses so. Otherwise the user can just submit the compiled email.

When sendhtmlemail==true the HTML preview is displayed on the same place but there is a View Source button on right which user can press to edit / view the HTML source of the email.

All above was done in previous mail-merge and should work. I remember I tested and it was working. Now I tried again but I have only sendhtmlemail==true data and that works fine.

I strongly suspect it only a matter of GUI misalignment - that text area should come on top right above the document preview and should display the compiled email which the use can further edit if he chooses so.

[luismanuel001]

It is not only a matter of GUI misalignment since the Email Body text box is actually in the same parent div of the form on the left, you can see how it scrolls along the other form elements on the left, while if it was misalignment, it would not scroll but go under the scrolling form containing div.

Also I haven't modified the GUI on any aspect, so I'm pretty sure this was just like this from before I started working on it.

I could certainly just move that Email Body div to be placed where you say it should be at (at the same position as the html preview), but the contents will be the same, not compiled code inside the textarea.

I don't even think the user should be able to edit a textarea of compiled code, since in that case the user will be able to manually edit the variable's compiled values, which doesn't really make sense to me. I think if the user needs to have the ability to edit the textarea, it should be not compiled to avoid issues when the backend tries to compile it again.

[distributev]

With the old repository I never saw that strange misalignement behavior - on the other hand while I remember I tested for sure with HTML = true I not same sure about plain text email (though I think it was tested). I tested again now but I have only HTML = true data. It works fine for that.

From the user perspective it make sense to allow him the flexibility to modify the email before submission (even if in most of the situation he will not actually modify - but it might).

Though I understand what you describe me as a kind of technical difficulty which interferes with desired user behavior. Ideally a good technology should not limit what features users can get (though sometimes it happens)

That being said when the initial code was implemented the backend was not there and the idea was to to interpolate on the front-end and then save the interpolated values (unchanged or altered by users) directly on server. Meenwhile we introduced the ng-node-compile on server because of the need to have same code for CSV and main functionality. But I can see now how the re-interpolation on the /server will vanish the values which the user can alter in the frontend.

Is it possible to use ng-node-compile only for CSV while the main case will interpolate on the /client and saved the interpolated values directly on the /server (without further re-interpolation on server).