Allow 'function' fields in email and pdf templates

[HVStechnik]

Issue

E-mails send by the Workflow module based on an Email template do not contain function fields (source = 'function' in vardef definition). Those fields are not automatically calculated, when the bean is initiated and the db row retrieved. For standard views the function fields are calculated during displaying. For email templates they however stayed blank.

Solution

Update the templateParser.php file within the AOS_PDF_Templates module in order to calculate function fields while creating the replacement array for the template markers.
The solution is similar to the calculation of those fields in /include/EditView/EditView2.php lines 1000 to 1040

How To Test This

Create an email template including a function field from a vardef and try to send it automatically.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Final checklist

• My code follows the code style of this project found here.
• My change requires a change to the documentation.
• I have read the How to Contribute guidelines.

Thanks to pgorod for guiding me through my first git pull request!

[codecov-io]

Codecov Report

❗ No coverage uploaded for pull request base (develop@f4a767a). Click here to learn what that means.
The diff coverage is 0%.

@@            Coverage Diff             @@
##             develop    #4266   +/-   ##
==========================================
  Coverage           ?      11%           
  Complexity         ?    41385           
==========================================
  Files              ?     3378           
  Lines              ?   245629           
  Branches           ?        0           
==========================================
  Hits               ?    27035           
  Misses             ?   218594           
  Partials           ?        0

[Mac-Rae]

Please resolve the conflicts on this pull request bringing it up to date.

[HVStechnik]

How do I check the clahub agreement? I have signed the agreement myself already. How can the "commit's parents" not have signed the CLA if I base on the SA SuiteCRM develop branch?

[Dillon-Brown]

Hi @HVStechnik, the issue with the CLAHub is that your commit is coming from what Git sees as two different authors, "HVStechnik" and "Max Wilckens". I would suggest either editing the author of the last commit and force pushing back up or doing a rebase (This may be of some assistance: https://www.git-tower.com/learn/git/faq/change-author-name-email)

Let me know if you run into any difficulties, I can rebase this for you with just the "HVStechnik" account as the author if that makes it easier. Thanks!

[HVStechnik]

Thanks @Dillon-Brown, I managed to change the author, but now travis fails. I think that the php5.6 build currently fails for all new pull requests....

[pgorod]

@Dillon-Brown it would be nice to merge this one, I think it's low risk and useful.

You don't have to label it "Enhancement", in my opinion, since it's technically a bug to have fields that conform to a spec, and render well in some views but fail when sent via email. This doesn't require the extra "Enhancement" review, I believe...

[HVStechnik]

@pgorod I reviewed the custom function options once again and got a bit confused:

Within the vardefs there are three different versions of how to include a custom function to calculate a field value:

1. $vardefs[$field]['function']
   The function vardef key may be an array that stores a file to be included (key: include), the function to be called (key: name), and an optional return mode (key: returns: if set to 'html' the function's return value replaces the field's value, otherwise the function's return value is set as the options key of the vardefs array and defines e.g., the options in an enum field).
   The code is implemented in EditView2, InlineEditing, MassUpdate, SearchForm2, and in SugarFieldBase
   DetailViews2 extends the EditView class (file: EditView2.php) and thus also implements this code. But it does not seem to be called in List views (?) With 'returns' => 'html' it should be similar to the option 3:

2. $vardefs[$field]['source'] == 'function'
   This is, what I was adressing in this PR. If ['source'] == 'function', SugarBean looks for function_class, function_name, and function_params in the vardef array.
   This is implemented in SugarBean ony. It is implemented in the process_union_list_query function, which calls the function in ListViews.

3. $vardefs[$field]['type'] == 'function'
   Last, but not least... This has the same parameters as ['source'] == 'function' (function_class, function_name, and function_params)
   This is implemented in SearchForm2 and EditView2. DetailViews2 extends the EditView class (file: EditView2.php) and thus also implements this code. But I think this version has the disadvantage, that the field does not render via the approapriate SugarField (because no specific type is given). Instead the function field is render via the base field, so that phone numbers, currencies, etc. are not rendered properly.

I would very much recommend to simplify this a little bit:
I think the 'returns' => 'html' cases should better implement option (2). The other implementations of (1) could be simplified by a utils function that implements the redundant code. Option 2 should also render in Detail and Edit view (maybe as read-only in edit views?).

After having done this review, I think we might want to leverage the callFunction function in EditView that does exactly the same as implemented by this PR. Would it be an option to move that function to SugarBean.php and call it whenever a custom function field needs to be evaluated?
What do you think?

PS: This does not make this PR less usefull ;-)

[pgorod]

@HVStechnik thanks for taking the time to study this. I guess some reorganization would be beneficial. We'd have to be careful not to make the changes break any existing customizations that people might have out there, relying on one of these mechanisms.

Another thing that would be quite useful would be to improve (or start?) some Documentation about this... I don't think there's any place really teaching how to use this.

[SuiteBot]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
7 out of 9 committers have signed the CLA.

✅ isleshocky77
✅ samus-aran
✅ Dillon-Brown
✅ cherrador
✅ connorshea
✅ cameronblaikie
✅ lazka
❌ code-ph0y
❌ HamburgischerVereinSeefahrt
_{You have signed the CLA already but the status is still pending? Let us recheck it.}