All custom modules display wrong Created Date

SuiteCRM Forum - English Language Developer Collaboration
1

Hello,

For all my custom modules, the detail view displays the same Date Created (same for Date Modified) in all the records.
After repair, the date is changed, but stiill visible in all the records.

I found some conversations about this:
https://community.sugarcrm.com/thread/18788#comment-76366
https://suitecrm.com/suitecrm/forum/suitecrm-7-0-discussion/5675-custom-module-date-entered-bad-format

But no long term and general solution.

Can you reproduce this bug ?
You can create a module in module builder and deploy it, then create records and modify the date_entered in the database.

Please let me know.
Aure

2

You can try reproducing it yourself in a clean installation here:

https://www.softaculous.com/demos/SuiteCRM

That demo has admin access so you can use Module Builder.

If you check it’s not working there, please open an Issue for this on GitHub. Make sure you reference that Sugarcm forums discussion you linked above, it provides very detailed technical information and should help resolve the bug. Thanks!

3

thank you for your proposition.
but I can not modify the dates in the database.
so I should create records on different days and come back to check the result few days later.
maybe not possible on this instance

Anyway, I just made a new test on my instance.
I modified the detailviewdefs.php for Account module:
I commented //‘customCode’ => ‘{$fields.date_entered.value} {$APP.LBL_BY} {$fields.created_by_name.value}’,
Then I repair

Now all the Accounts show the same Date Entered (same with Date Modified)
Can you test on your instance ?

Thank.
Aure

4

I can’t test, simply due to lack of time. But I trust your diagnosis, and the others on those threads, so go ahead and open the GitHub issue. Thanks!

5

I have the same issue.

Workarround:

change

‘name’ => ‘date_entered’,

to
array (
‘name’ => ‘date_entered’,
‘label’ => ‘LBL_DATE_ENTERED’,
‘customCode’=>’{$fields.date_entered.value}’
),

1 Like
6

Thanks for the workaround, @topesantos!

@aureh12 did you create an issue on Github with this? If so, which one? We should also post the workaround there, it might give some clues about how to fix the bug.