Variables in Email Templates - Semantics

pgorod commented 4 years ago

Problem

I think we are in need of some reorganization of concepts in this area...

Our Templates currently have the following sets of variables:

Contact / Lead / Target (which generates variables like $contact_*)
We don't have a set of Contact variables separate from the above.
Lead (which generates variables like $lead_*)
Target (which generates variables like $prospect_*...)
Account (which generates variables like $account_*...)

In campaigns, this often wouldn't be ambiguous: we're iterating records that can be of the 3 types (and more...), so we should always have the basic fields there. But what about Accounts? We also send Campaigns to Accounts (and users), why aren't these included in the "joint" scheme?
In individual emails that use templates, this can be a whole lot more ambiguous, due to related fields. When you're in a Contact, you might want to use the Lead Source field, meaning "the Lead Source from the Lead that is related to this contact". That's not the same as "try to find a Lead Source field in the current record, no matter if it's a Contact, a Lead or a Target". Just think of when we need to use fields from Account in Contact emails. It's a common scenario, and if we opt for a "let's try to treat Accounts and Contacts as if they're the same thing, so we can re-use a single template for both", we break this.

The Proposed Solution

I believe that the module variables should only translate to that module's records. So we shouldn't make concessions like "I'm in a Campaign, so I'll pretend this Lead is a Contact and populate contact_first_name anyway". This eliminates ambiguities and provides accuracy.

Instead, we should use different sets of variables for aggregates, with well-defined semantics. We could have Person, for example, since we already have that concept elsewhere. Like person_first_name etc. These would contain only a minimal set of common fields, and make an additional effort to populate from whatever they have available.

Aggregates could start with a common word (like "Any") so they could be easily identifiable:

Any Emailable (includes accounts and users)
Any Person (contacts, leads, targets)
Any Activity (meeting, task, etc)
...

Finish deprecating the `prospect` term once and for all

Meanwhile, if we could drop the prospect word from all places in the UI, including template variables, that would be great. It's the old name for target, it's been deprecated for years.

mr-m0nst3r commented 4 years ago

Hey there,

I'm experiencing this righ now, with email campaign. Haven't tested on sending emails manually using templates.

As far as I can see:

you don't have to use email template when you're sending one email to one person, because in thus situation, you're sending a customized email according to the person's needs, so why using templates?
In the email campaign, it's defined to send a bunch of emails to different person, the receiver is a target list, so will it be a lower fruit if we can just add some relations when we're creating a target list? Thus we can select variables from target list properties, and leave alone the Targets/Leads/Contacts/Accounts.

Pitty that I don't have time and enough skills for doing this.

Looking forward to early fixes.

pgorod commented 4 years ago

@mr-m0nst3r thanks

About your first point - I think Templates are used in these individual messages in order to use "canned responses" - pre-written answers to common interactions.

mr-m0nst3r commented 4 years ago

@pgorod Hi, I thought of that, but, forgive me if I understand SuiteCRM in the wrong way, I think the KB should fit in the situation you described.

Never used KB, I used SuiteCRM two years ago, and pick it up to make my life better. :P

mikek03 commented 4 years ago

I seem to be having a similar/related issue with New Account emails in SuiteCRM version 7.11.13.

I customised the "System-generated password email" to include Dear $employee_first_name or Dear $contact_user_first_name but when the email arrives, the variable is displayed instead of the user's first_name.

pgorod commented 4 years ago

@mikek03 each of those situations is a different challenge. Those email replies use different variable-substitution code.

mikek03 commented 4 years ago

@mikek03 each of those situations is a different challenge. Those email replies use different variable-substitution code.

Not exactly helpful. SuiteCRM has generated those codes in the email template, it doesn't then translate them when the email is sent.

How do i fix this?

pgorod commented 4 years ago

I'm slowly fixing all this for my PowerReplacer add-on, one at a time, but I'm afraid I haven't taken care of this one, so I don't exactly know where the code is.

Are you having trouble finding the code, is that it? I can try helping you out on that, but please spell it out for me, what needs to be done to generate those emails? I'm not familiar with that feature.

mikek03 commented 4 years ago

SuiteCRM provides a function to generate a password and email the user on new user account creation. The email that is sent is configured in Admin->Password Management under Email Templates->For system-generated password. I've used the "Edit" button to edit the predefined template and wish to include an element of personalisation, addressing the email Dear UserLastName but when insering the variable for either User Last Name (which generates $contact_user_last_name) or Employee Last Name (which generates $employee_last_name), it does not get replaced when the email is sent.

The template already includes $contact_user_user_name and @contact_user_user_hash, both which are replaced. I don't know what code is executed to send the new user email or replace those variables with the data in the underlying database.

I expected that the code which replaces attributes is all in one common place which would be consumed by other routines but I don't know where I should be looking. Regardless, this should work by default as it's basic functionality that's been in SugarCRM/SuiteCRM for as long as I remember.

pgorod commented 4 years ago

I expected that the code which replaces attributes is all in one common place which would be consumed by other routines

You wish... and so do I. But unfortunately, no.

I think this email functionality is here: https://github.com/salesagility/SuiteCRM/blob/master/modules/Administration/PasswordManager.php

and I don't see any code to replace variables or to ASSIGN variables so that the tpl can reference them.

I don't think this is related to the current issue - maybe we should continue the conversation on the Forums, or you could open a new issue for the password emails...

EDIT: sorry, this is where it's really happening:

https://github.com/salesagility/SuiteCRM/blob/master/modules/Users/User.php#L2266

Good news - it does have some variables there...

mikek03 commented 4 years ago

Thanks @pgorod, i'll take a look at that. I've raised as a new issue.

marcoblancas commented 2 years ago

Dealing with this problem in 7.12.3. We have hundreds of pre-written email templates that was woking on 7.6.7 composed with the variables that today still are proposed in the template composer.

Contact/Lead/Target -> First Name -> $contact_first_name

And mails users send from Leads with those templates are not populated.

Replacing $contact_first_name by $lead_first_name works but then it will be required different templates for different modules and users are going to be wrong selecting the correct template.

Anybody working with this? Is the same problem present in SuiteCRM 8?

If "Contact/Lead/Target" in templates is not going to work in the future and now it's not working as expected... should we rename it?

marcoblancas commented 2 years ago

I confirm the problem persist in SuiteCRM 8. Today I'm in 7.12.4.

I need to decide if I replace all my references to $contact_xxxx by $lead_xxxx in my email_templates table as a workaround (as my users write most of their mails from the leads module), but first I would like to know some thinking from developers related with the templates motor. Is in the roadmap to fix or refactor this?

Thank you in advance.

pgorod commented 2 years ago

It's all been rewritten, fixed and refactored in my PowerReplacer add-on, but all my attempts to make this code go into the core product, while generating a minimally fair amount of revenue, have failed...

craigpanton commented 2 years ago

I confirm the problem persist in SuiteCRM 8. Today I'm in 7.12.4.

I need to decide if I replace all my references to $contact_xxxx by $lead_xxxx in my email_templates table as a workaround (as my users write most of their mails from the leads module), but first I would like to know some thinking from developers related with the templates motor. Is in the roadmap to fix or refactor this?

Thank you in advance.

Hi @marcoblancas ,

Thank you for getting in touch regarding the above issue. Please raise this as a new issue and a member of the team will assess as soon as possible.

marcoblancas commented 2 years ago

Thnak you @craigpanton. Added new issue https://github.com/salesagility/SuiteCRM/issues/9527