how to add custom module fields in email templates

Hi,
I got here asking myself (and google) the same question. Sorry for the >1 year post.

Adding the custom field to database works fine, but I did not see a way to add the field to the Edit view, other than editing SugarCRM core files.
There is no editviewdefs.php file, it is done in what I suppose is an older way, using html templates.

The list view however is more up to date. I could add the custom field to it and use massupdate to change its value.
Not very efficient but it might work for my limited needs, it won't be used very often.

Still, if anyone can share a way to edit the EmailTemplates record view without changing core files I would very much like to know how to do it :)

Stay safe,
Laurent

Laurent (and Sino Thomas the OP),

Sorry for the long reply, and for the detailed nature if you already know most of this, but you did ask :)

You are right that the Email Templates uses an older method for display / edit of the form and data. I am guessing only real oldies like myself remember the way Sugar used to be in the pre-v.5 days ;) It is possible to adjust these layouts in a custom-safe-ish way though (as with all older dev work, if this module gets changed to Sidecar then you will lose all dev stuff and have to re-create it using the Sidecar model).

Anyway, the really old method even pre-dates the use of the editviewdefs files and is based on (Smarty?) templates. These use separate .html and .php files to create the layouts and populate the forms. In short, there are pairs of files that create these, they are split into Detail and Edit views and are named accordingly. You are looking for files named DetailView.php and DetailView.html which you will find in the module directory for EmailTemplates. There are equivalent Edit versions of these as well. The old system allows you to make copies of these in the appropriate ./custom directory to create your own custom versions of the layouts. This applies to all modules, not just EmailTemplates however, all others have been superseded by the viewdefs and latterly by the clients/{platform}/{view}/... model. Further, and specific to the EmailTemplate module, you will find an additional file called "EditViewMain.html" - this is used in conjunction with "EditView.html" to provide alternate layouts based on the source of the email template. I'll explain further on that in a moment. For now you need to simply copy the existing stock files into the equivalent ./custom directory and edit them there.

What you really need here now is to grab a copy of the developer guide for Sugar version 4.5 or thereabouts. Unfortunately, you are unlikely to find such a guide in the SugarCRM.com pages as it is so old. There are a couple of books that help you understand this development model if you are interested though. Or you may find a kind soul who has kept an old copy of the dev guide. I am pretty sure I deleted mine a while back thinking it was useless  So in the absence of a full dev guide I'll try to give a couple of pointers. The rest should not be tricky to work out, it is only PHP and HTML templating after all.

First, the .php version of these files do the grunt work of collecting the data from the DB and getting it ready to show / edit. They also specify the layout file to be used. They set up and fill in a template using the XTemplate class, you will normally find the line which does this using:
$xtpl = new XTemplate({path-to-template-file]);
In the case of this Email Template, the EditView.php has a condition here, it uses different layout files depending on a couple of items. You will easily find this and see what is happening. Basically here though you create the template based on the "*View.html" layout you wish to use. In your ./custom version of the .php file you will need to specify the custom directory path to the layout file. So for the custom edit view it would read:
if ($has_campaign || $inboundEmail) {
$xtpl = new XTemplate('custom/modules/EmailTemplates/EditView.html');
} else {
$xtpl = new XTemplate('custom/modules/EmailTemplates/EditViewMain.html');
}

Within the PHP file you will also find that variables for use in the layout are defined. There are lots of these in the format:
$xtpl->assign({VARIABLE}, {value});
and this is where you assign things like field values for display in the DetailView and initialisations of fields for the EditView. These variables are then referenced in the layout to pull the data that the PHP code has created / retrieved.

Now you need to adjust the custom version of the HTML layout template which is what actually makes the visible changes in the forms / pages. For the Detail View these only need go in the custom DetailView.html file but for the Edit version you will probably need to make changes in both EditView.html and EditViewMain.html - the latter is most likely what you are requiring here.

This .html file is quite simple in that it is just a HTML layout of what you see on the screen. No real explanation of the layout needed here I hope. It is pure HTML though so you will see that things like hidden field elements are described that handle return paths and data passed into the POST form for record and module for example. The bits you will need to concentrate on and adjust are where your new custom field is placed. You will need to create new table rows (I said it was old!!!) and define the HTML element markup for them. You can here, as you see from existing markup, use the variables you defined in the .php file to bring data into the layout. I am not going to go into that as this is all quite straightforward if very old-fashioned.

Finally, the trusted QR&R is needed to bring the custom files you create into the cache. Et voila! Your changes will automagically appear 

I suppose I could have simplified all the above into "make custom copies of the stock files and edit them there" but that removes the fun of going back over the old development techniques!

Hopefully this is easy enough to follow and helps you or others. Been interesting to think about the olden days again.

Good luck.

JH.

Thanks John, this is a great answer!

Your pointers are showing me steps I missed when I tried to customize the view, I'll try again.

Worst of cases, I can manage with workarounds even if it's less user-friendly.

Anyway I am bookmarking that for future reference.

Cheers,
Laurent

Hi Laurent, John

I just stumbled upon this while I was searching for another help topic, and can't just go over it. Really interesting to read Johns answer, as I also started with Sugar with pre 6.x version. However this requirement came up only in the 8 version for me.

As this thread is already a bit older, and you already found a solution, I'll do it short.

I solved it like this, that I added the module to Studio. Here you'll find a short description how I did it.

https://sugarclub.sugarcrm.com/dev-club/f/questions-answers/952/adding-custom-fields-to-email-template-records/3748#3748

Unfortunately, I don't know anymore where I found the original thread, but it was somewhere in the Sugar community. I used this approach for other core modules too, also in later versions.

Maybe it help you or someone else out.

Best regards
Rene

Rene Ryhner

Your solution is good if you just want to add the modules to Studio (ProspectLists is another one where this is often needed) but I'm afraid it doesn't actually solve the issue here - or in the other thread - properly. The reason is as I stated in my answer above: the Email Templates module specifically uses different HTML layouts for different data circumstances, hence my explanation of needing to adjust both EditViewMain.html and EditView.html files. I strongly suspect this is the reason why this module was excluded from the Studio editor in the first place.

Whilst your solution will add the Email Templates module to the Studio layout editor, Studio cannot (has never and I doubt ever will) be able to handle multiple data-driven layouts so any changes will almost certainly still have to be done in code by hand for these older Smarty layouts.

All this is going to be moot soon though as since my last answer this module has indeed been converted to Sidecar and so the older Smarty templates are no longer in effect from version 11 onwards.

Thanks,

JH.

Hi John,

Could it make sense to change the approach of "building the Sugar" and to employ the Sugar platform flexibility already in place - in order to solve the task faster and with lower efforts?

The content of the template-based emails is manageable on the fly (aka data-driven content or dynamic content) with no coding for Sugar platform for almost 4 years - with a Logic Builder configuration tool 

Here is the example:

integroscrm.com/.../

Dmytro,

"Sugar's platform has been able to be managed, amended and otherwise customised for over 15 years by manner of code updates by myself and other like-minded developers."

Neither that statement by me nor your answer has any bearing whatsoever on the post I made earlier today about whether Rene's proposed solution addressed the issues raised.

If you want to avoid annoying people with your oft-posted, rarely researched advertising then it might be worth reading the posts in full before responding.

Thanks,

JH.

Dmytro,

"Sugar's platform has been able to be managed, amended and otherwise customised for over 15 years by manner of code updates by myself and other like-minded developers."

Neither that statement by me nor your answer has any bearing whatsoever on the post I made earlier today about whether Rene's proposed solution addressed the issues raised.

If you want to avoid annoying people with your oft-posted, rarely researched advertising then it might be worth reading the posts in full before responding.

Thanks,

JH.

Hi John,

Sorry for annoying you - and thank you - I am quite careful in reading the topic and confident in identifying a business reason, which developers are trying to solve with coding efforts on this topic

Not sure what configuring experience has been actually referred to in the reply,
but the idea is to stop trying to enhance the editor or asking the vendor to make it while there is a capability to manage the email content in Sugar platform on the fly with no coding skills - there are so many challenges that are worth skilled developer's time investments, why not to leave simpler things for Sugar admins and let the platform do the work?

I hope this makes sense.

You didn't annoy me, I just get frustrated at how sales people are only interested in the sale. They have no regard as to whether what they are selling is worth the cost to the purchaser.

As before, I won't go any further after this answer, I have work to do ;)

Dmytro Chupylka said:

but the idea is to stop trying to enhance the editor or asking the vendor to make it

This is the crux: nowhere in this thread has any such thing been mentioned or suggested. The OP & Laurent asked a question designed to enhance their knowledge of how something works, not just to be given something that does work in one particular way.

Dmytro Chupylka said:

why not to leave simpler things for Sugar admins

This is admirable. However there is a difference between "administration" and "system changes". The latter (including the smallest change imaginable) should, in a real business sense, be subject to change control, regression testing and further change management. No-code tools do not provide this and cannot be used in this way. Software Engineers (by their very nature of engineering something) understand this and this is the expertise being paid for. A sort of insurance against (possibly extremely) costly malfunctions further down the line. If you don't need insurance then fine - I am yet to discover such a situation though.

If that is a concept tricky to understand I suggest reading the short story "A Sound of Thunder" by Ray Bradbury.

If any more is needed I can suggest a long-term experiment. I shall buy myself an engineered Mercedes-Benz and you can buy yourself an assembled Dacia. We can meet up in 20 years and see whose car is performing more efficiently

Thanks,

JH.

Since I'm not a sales guy either but rather a consultant that tries to make work in Sugar CRM faster, more convenient and efficient, I would choose roller-blades or a bike :)
Lower CAPEX, lower maintenance, better for health, and provide more flexibility than a car to reach the close destination faster - a good return on investments!

However, I would agree that in the world of cars, insurance is a good idea anyway.