It says you don’t use tyniMCE editor and Direct HTML, but… Is it possible for users to use TyniMCE? Many of our templates are pre-written mails with some paragraphs users must to personalize.
Direct HTML editor is OK for email templates editor, but… users sending single mails needs to edit in wysiwyg editors.
By other hand, now in SuiteCRM 7.12.4, signatures populated when users choose the “from” are deleted when they choose an email template… is this solved in your add-on. I could see you had something like a {{signature}} variable for the template, but I’m not sure if this is the signature from the user who is sending the email or the signature from the assigned user in the lead.
Please… talk us about how we deploy the add-on… is this like a zip I upload to the module-loader? Should I merge your code with my code because this “fix” core code?
That project didn’t go exactly as I wish it had… I didn’t get enough sponsors and I had to move on to other projects. Still, I have a couple of people interested and I plan/hope to make a new version that fits 7.12 and 8.0 (there were changes to PDF engine… not good for my add-on which depended on the old engine).
I think there is a certain incompatibility between letting users use a wysiwyg editor versus getting emails just right, with stylesheets etc. If you let people format they will just do random things. On the other hand, if you have a carefully developed stylesheet, with elements that are easy for your users to invoke (say, a title, or a bulleted list) then your emails will turn out just fine. The logic behind my add-on is that you get things prepared for end-users, so that they have easy and simple ways to edit content, but… with some strictures so that you can keep the formatting consistent. The “preview” feature also helps check if the mail looks right.
Well, that and the fact that TinyMCE throws away the tags that I need for my templates
Still, what my add-on does is make the user preference for “Email editor” to become effective in the Compose window, and not just in the Email templates module. So if a certain user wants TinyMCE she can still select it.
The signatures are just a custom tag I made. You can make one to suit your purposes and add any code behind it. Mine expands to something like this:
<table>
<tbody>
<tr>
<td>{{ assigned|photo }}</td>
<td><p><b>{{ assigned.name }}</b> is standing by to assist you with this purchase.</p>Questions? Please dial {{ assigned.phone_work }} (Office), {{ assigned.phone_mobile }} (Mobile) or simply reply to this email.</td>
<td><img src="http://myurl/public/emailImages/hopeShoes.png" width=80></td>
</tr>
</tbody>
</table>
About deployment- it is a Module that you install in Module loader. Is should be entirely upgrade-safe and compatible with other add-ons (as long as they don’t mess with the same views and classes that I change).
If TinyMCE throws away the need tags for your templates I suppose that users with TinyMCE can’t use your templates, can’t them? or that only impact to template editors?
Please, confirm me if tags like {{ assigned.name }} or {{assigned.phone_work}} referrer to the assigned user of one lead. In our case sometimes users non assigned to a lead can write emails to leads and the signature required is the user signature who is writing and not the assigned user to the lead.
TinyMCE is quite configurable (although it might not be easy to get those configurations working from within SuiteCRM) so it might be possible to make it allow those tags. But maybe I wasn’t clear enough, this is not just a technical “string clean-up” problem. It’s that the approach is different with my add-on. At first people think that wysiwyg is better, but in the end it isn’t. I think you get a better CRM experience with text emails using well-designed tags.
Actually that assigned tag is defined further up in the email, along with another definition for quote content, like this:
{% set quote = person|related('aos_quotes')|last %}
{% set assigned = bean('users', person.assigned_user_id) %}
(Note that this complexity can be hidden from end-users if that block is constant)
The general idea is that with my add-on, you’re in low-code territory. You can do mostly whatever you want. You get references to every relevant piece of contextual information (user, current record, etc) and then you can navigate from there to anywhere else (related records, etc). You can even make the signature selection be based on a complex boolean condition.
It’s really powerful. The answer to “can you do this or that” is generally yes
