Datetime value get hard coded in template cache sometimes

[gunnicom]

Example: field date_entered In most detailviewdefs this field is defined as customCode {$fields.date_entered.value} {$APP.LBL_BY} {$fields.created_by_name.value} and that is working.

But if it is not defined as customCode, just as field (Dont know if it came from studio or modulebuilder),

          0 => 
          array (
            'name' => 'date_entered',
            'comment' => 'Date record created',
            'label' => 'LBL_DATE_ENTERED',
          ),

when the template cache gets generated (developer mode off) it writes the value of the first opened object hard to the cached template. Cache file: cache/modules/MODULENAME/detailviewdefs.php

This is how the generated cached template looks if the value gets hard coded into the template.

{if !$fields.date_entered.hidden}
{counter name="panelFieldCount"}

{assign var="value" value=19.03.2015 }
<span class="sugar_field" id="{$fields.date_entered.name}">{$value}</span>
{/if}

I can workaround that issue by editing include\SugarFields\Fields\Datetime\SugarFieldDatetime.php line 205 from if (!empty($sdt)) { to if (false && !empty($sdt)) {

This is how the generated cached template looks if doing the above change:

{if !$fields.date_entered.hidden}
{counter name="panelFieldCount"}

{if strlen($fields.date_entered.value) <= 0}
{assign var="value" value=$fields.date_entered.default_value }
{else}
{assign var="value" value=$fields.date_entered.value }
{/if}
<span class="sugar_field" id="{$fields.date_entered.name}">{$value}</span>
{/if}

But this can only be a workaround. The real fix must be somewhere else. I dont know the correct fix for now, but maybe someone knows the place to look for. Additional Info that maybe important and helpful: DateTime Format is german like 30.1.2015. Files i digged through: include\SugarFields\Fields\Datetime\SugarFieldDatetime.php (from line 195 ) include\SugarFields\Fields\Datetime\DetailView.tpl include\SugarFields\Parsers\Rules\VariableSubstitutionRule.php ( from line 62 )

[gunnicom]

One more Info. If the hardcoded date shows, its only the date like 01.01.2000 With the workaround its shown as DateTime 01.01.2000 01:00

[fcorluka]

I have the same problem, and everyone else should have it. Custom modules don't have in def files (detailviewdef and editviewdef) date_entered and date_modified as custom code, so their values get cached.

Without developer mode, none of the values are correct.

I have test it on versions: 7.4.3, 7.7.8

Currently, solution is to manually modify every def file of every custom module to change: array ( 0 => 'date_entered',

to this

array ( 'name' => 'date_entered', 'comment' => 'Date record created', 'label' => 'LBL_DATE_ENTERED', 'customCode' => '{$fields.date_entered.value} {$APP.LBL_BY} {$fields.created_by_name.value}',

[mugge6]

Issue still exists on SuiteCRM 7.9.7

[salesagility-davidthomson]

This appears to be fixed in 7.8.20. and is also not present in 7.10.7 when using fresh installs

I have been able to recreate the issue First use 7.8.20 and create a new module detailviewdefs.php for date_entered has been created correctly with the section 'customCode' => '{$fields.date_entered.value} {$APP.LBL_BY} {$fields.created_by_name.value}' Now change code base to 7.10.7 in git ( i did not try using upgrade path to 7.10.7 ) the module created in 7.8.20 should still be in module builder. If you deploy the module created in the older version of suitecrm then the date_entered field is now missing the custom code key and value If I now create a new module in 7.10 from scratch the date_entered field is created correctly. It seems to be an issue with redeployment using module created in an older version.

[pgorod]

So, should this be closed now?

[Dillon-Brown]

This issue has been closed as version 7.8.x of SuiteCRM has reached its end of life and therefore will no longer be receiving updates. We have also been unable to replicate this issue in any newer version of SuiteCRM such as 7.10.x or 7.11.x however if you are able, please leave a comment explaining how and we'll re-open this issue.

For more information about 7.8.x end of life please visit our blog post