Suitecrm: HTML field doesn't update new value with developerMode disabled

Created on 5 May 2020  路  9Comments  路  Source: salesagility/SuiteCRM

Issue

When working with an HTML type Sugarfield, and a new value is set via any backend code(LogicHook, Action, ...), the field won't update even when the DetailView is refreshed. However, if the developer-mode sugar property is enabled (true), the HTML field will update as expected after reloading the DetailView page of the module.

Is this the expected behavior for an HTML field?

Expected Behavior

The HTML field should update regardless the developer-mode property value

Actual Behavior

If the developer-mode is disabled (false), the html field won't update after changing its value. We normally update the value from a LogicHook or an action controller

Possible Fix

We are currently using the wysiwyg, although we don't really need a full 'iframe' for this.

Steps to Reproduce

  1. Deactivate developer-mode
  2. Add an HTML field in a module
  3. Add any backend logic that will update the value of the HTML field.
  4. See that the HTML field is not updated

Context

We are using these HTML fields to display information about a certain action within the record, as a log field, and enriching the text using CSS.

Your Environment

  • SuiteCRM Version used: 7.11.8 (and SugarCRM 6.5)
  • Browser name and version (e.g. Chrome Version 51.0.2704.63 (64-bit)): Chrome and Firefox (64-bit)
  • Environment name and version (e.g. MySQL, PHP 7): PHP 7.3, MariaDB
  • Operating System and version (e.g Ubuntu 16.04): Debian 9

Most helpful comment

This worked without Warnings adding the whole list of parameters into the function:

public function setup($module, $focus = null, $metadataFile = null, $tpl = 'include/DetailView/DetailView.tpl', $createFocus = true, $metadataFileName = 'detailviewdefs').

Thanks for the help.

All 9 comments

You probably just need to invalidate your cache when you update the values programmatically.

This might help you:
https://community.suitecrm.com/t/disable-cache-in-one-view/59512/4?u=pgr

I tried this solution before and it showed some error regarding the number of parameters provided to the parent function checkTemplate() and directly discarded it. But I can reproduce it again and show the error if you think it may help.

However, I believe that the expected behavior out of the box shall be to show the updated value. Unless there is something we didn't understand right.

I guess the caching system is just doing its job: detail views show data, they don't update it. So the rendering is optimized with a stable cached file.

If you decide to add some custom logic that invalidates this reasoning, then I guess you need to also invalidate the cache. I am sure the error you got can be resolved.

@SinergiaCRM
This might help you:
https://community.sugarcrm.com/thread/18487

@chris001 , probably I didn't explain our issue with enough details. The value of the field we are trying to update is an HTML SugarField, and changing its value we reload/refresh the url programmatically for the changes to appear. At this time, all the fields of the records are updated successfully but not the HTML.

What we aren't trying to do is to update that value dynamically without reloading/refreshing the url.
If we check the bean during the display() of the DetailView, we can see the updated value of the HTML that is not appearing in the gui.

@pgorod , I implemented again the solution proposed in your url and the error that appears relates with the setup() function of DetailView2:
{"content":"\nWarning: Declaration of CustomDetailView::setup($module, $focus, $metadataFile = NULL, $tpl = 'include\/De...') should be compatible with DetailView2::setup($module, $focus = NULL, $metadataFile = NULL, $tpl = 'include\/De...', $createFocus = true, $metadataFileName = 'detailview...') in \/usr\/home\/betasuitecrm.sinergiacrm.org\/web\/custom\/include\/DetailView\/CustomDetailView.php on line 0\n\n\n

We have found already an alternative solution using "wysiwyg" SugarFields and a little bit of CSS.

@SinergiaCRM I think you just need to change this line in your custom file

public function setup($module, $focus, $metadataFile = null, $tpl = 'include/DetailView/DetailView.tpl')

to

public function setup($module, $focus = NULL, $metadataFile = NULL, $tpl = 'include/DetailView/DetailView.tpl')

This worked without Warnings adding the whole list of parameters into the function:

public function setup($module, $focus = null, $metadataFile = null, $tpl = 'include/DetailView/DetailView.tpl', $createFocus = true, $metadataFileName = 'detailviewdefs').

Thanks for the help.

Reviewing the thread appears that this issue was a misunderstanding and tht it was resolved thanks to chris and pedro :+1: Closing the issue now.

Dear @samus-aran:

Although the issue has been closed, we would like to call your attention on its main point, as we don't feel it is a misunderstanding.

As we stated above, we think that the behaviour of HTML fields is not what it should be expected. As in any other type of field, every record can have a different value for an HTML field and we feel that the appropiate value should be shown in the detail view for any given record. But what it really happens is that the first value ever shown for this field is cached in the view template so it is shown in every record instead of the right database values. Which would be the meaning of a field that can store values as any other field but can't show these values on the GUI?

We would like to know your thoughts on this question. Maybe the issue should be reopened?

Thank you very much.

PS. As stated above, there are a couple of workarounds that can be used: set developer mode to true or disable the cache for detail view. Anyway, we feel these workarounds are not nice as permanent solutions.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Mausino picture Mausino  路  3Comments

pgorod picture pgorod  路  3Comments

ArturoBurela picture ArturoBurela  路  3Comments

dawansv picture dawansv  路  3Comments

ajprouty87 picture ajprouty87  路  3Comments