Case Description shows HTML <p>

When you enter a new case in 7.2.1 the system adds


for HTML formatting but then this isn’t rendered correctly on the view page.

See attachment.

This is a known issue.

Copy modules/Cases/metadata/detailviewdefs.php to custom/modules/Cases/metadata. In the detailview.php in custom/modules/Cases/metadata add the following to the description field definitions:

'customCode'=>'{$fields.description.value|escape:\'htmlentitydecode\' |escape:\'html\'|strip_tags|url2html|nl2br}',

Hi, this is good detail, but I don’t have a metadata file in the custom/modules/Cases/ path…

I tried to copy it all over and it didnt work for me.

I did a repair after making the changes and I received an error referring to the smarty template.

Found this.

It worked for the description in the detailed view which I was having an issue with.


Hi, this solve the issue but it also removes the tag, hence disabling the link too.

I would like to have a link in my description field but I don’t know how to configure the strip_tags function so it leaves out the tag in the tag and it displays the link.

Can anyone help me changing the following custom code to actually allow in the description field?

'customCode' => '{$fields.description.value|escape:\'htmlentitydecode\' |escape:\'html\'|strip_tags|url2html|nl2br}',


This used to work but since upgrade to 7.4 it doesn’t work anymore. some tags are hidden but


still show so all text is globbered together :frowning:

I would really appreciate an update to fix this!

This is my solution work well on 7.4.1

        4 => 
        array (
          0 => 
          	'name' => 'description',
            'customCode' => '{$fields.description.value|escape:\'html_entity_decode\'|strip_tags|escape:\'html\'|url2html|nl2br}',

The order of escape is important.


hmmm… Well interesting, so htmlentitydecode changed to html_entity_decode ?

With me the new solution dos not fix it - now I have lots of


in my screen, which is the equivalent to

even further decoded.

But thanks for the update info to 7.4.1 - just installed that. Unfortunately it did not fix this (for me) MAJOR bug.

Like this the support case module is 50% unusable. As this shows everywhere I cannot believe it isnt fixed.

sigh :unsure:

ok, I digged through this a little bit - so htmlentitydecode or html_entity_decode are both working alike and get the extra gobbling special char descriptors out of the text, but the rest of the line doesn’t do anything. This part does exactly the same result-speaking for me:

'customCode' => '{$fields.description.value | escape:\'html_entity_decode\'}',

Please note the SPACE before and after the “|” pipe since this is neccessary to do anything at all.

But now what about this part?

 | strip_tags | escape:\'html\' | url2html | nl2br

This seems not to do anything at all - in the resulting output urls are not clickable, P Tags are not removed, there are no newlines to line breaks. Somehow somebody will need to help us with the syntax here, it looks to me like we got this totally wrong.

PLEASE! :dry:
take care,

Hi there,

Try this solution. You will need to insert the html_entity_decode.

With regards the HTML we are still in discussion whether to display html in fields in case of malicious code being inserted into the description field.

I am sorry, but this did not change anything in the output. Still I see

and all over the place.

Do I have to remove my changes from detailviewdefs.php also?

And how can you discuss html when you included tinymce as a editor tool - what is this for if the result is not usable? All other filelds including update are showing urls as links, but even that is not priority, I’d just like to see the text es it was entered in the editor, please.

Thank you,

Hi Oddl

I would remove the CustomCode from the detailview as the default should already include those specific parameters and it requires to be in a particular order. You can check this by checking the cached template once you have removed the CustomCode and do a Repair & Rebuild (or if you want to be quicker you can simply delete the cached template from cache/modules/Cases instead of the Repair & Rebuild).

Regards to the HTML, the discussion is with how to proceed with the escaping of all tags, or particular ones. We are looking into it as this has been raised by other members, so we’ll keep you updated and let you know as soon as we have a solution in place.

Thank you for taking your time in this subject. I really appreciate all your efforts to make this product great.

I restored the detailviewdefs.php back to the original version with the output still remaining the same.

For input to the discussion: In my opinion it is useless to have an editor that gives the (greatly appreciated and required) opportunity to structure text with bullet points, line breaks, bold text and paragraphs when the output is invisible html and a big lump of text.

This construct worked somehow in 7.3 with the below mentioned changes in detailview, but the fix was broken in 7.4 - how, I do not understand since the mentioned functions are all still present.

In 7.3 with the fix, the output in the view looked like the output of an html page should look like in an usual browser. I do not require tags to be removed, I’d rather like to see the output just as I entered it into the wysiwyg editor!?

take care and thanks,


I too came across this problem and started to dig around. I have used SuiteCRM 7.1 for my own internal purposes, but now I thought I would use it as a contrived project management tool for each new project I work on. As such I loaded up 7.4 configured it to my liking and was overall pleased with all the new features, except the HMTL problem which creeps up in other areas as well. Since I need it outward facing for my clients, I was horrified when I saw this as I had just created a new case. I have a workflow trigger scheduled to email my client contacts on new case creation. Emails are fine in rendering the markup , but when I’m sending a direct link within the email to the case it would be quite embarassing to me. Thus went to the forum and saw your posting.

Let me say first, I am shocked that this has not been taken care of and responded to appropriately. I know they are running a very thin shop but something like this should not have made it out for release .Even the most cursory testing would have caught this. . Most responses have been quite unsatisfactory and not real helpful. I agree as to what’s the point in providing HMTL Wyswig if your going to suppress it within the interface.

As far as the security issue, escaping markup should be made a configurable option in the administration area. Therefore, eliminate the debate right from the start and let folks proceed at their own risk once the transparency veil is lifted and a solution has been provided.

Now that’s taken care of, I’ll give you the fix , which by the way is not all elegant and breaks all the principles of software engineering. However, I had to do something quick as all of the previous posts where either vague, misleading and | or did not work at all. Yes, I wasted much time here as well. Total time to fix this, albeit temporarily was about an 1.5 hrs.

  1. I went to Git and noticed the changes which were made to include/Smarty/plugins/function.sugarvar.php

  2. Within function.sugarvar.php
    a) Goto Line #95 and comment out the 3 lines dealing with the html escape functionality thereby removing it. Should look like this below:

    $_contents .= ‘|escape:‘html’’;

  3. Do a quick repair & rebuild to flush the system cache.

NOTE: I have not really tested this fully and hope it will globally fix the rendering issues for now until it is captured within the next update.

Let’s hope this gets fixed systematically in the future. Apologize for the rant, but this is really quite unacceptable along the lines of the JOT dashlet tool issue.

Best Regards,


Thank you Scott!
you really made my day as the first one of the new year :silly: :slight_smile: :slight_smile: :slight_smile:
Finally I can work again. For us this is essential as we use it for support, I really hope it will be permanentely fixed in future releases.

take care,
Thomas / Oddl.

Thank you Scott, Glad it helped me too!

Scott’s fix (shown below) did not work for me, running 7.5.3

I also previously upgraded to 7.8.5 did not fix the issue. Had to roll back to 7.5.3 when the upgrade to 7.9.2 failed.


Scott’s fix

  1. I went to Git and noticed the changes which were made to include/Smarty/plugins/function.sugarvar.php
  2. Within function.sugarvar.php
    a) Goto Line #95 and comment out the 3 lines dealing with the html escape functionality thereby removing it. Should look like this below:

$_contents .= ‘|escape:‘html’’;
3) Do a quick repair & rebuild to flush the system cache.

If you see HTML tags in list of Case Module then

  1. Create a logic hook
    and Add this code there

if (!defined(‘sugarEntry’) || !sugarEntry)
die(‘Not A Valid Entry Point’);

class Remove_HTML_TAGS
	function remove_html_tags_method($bean, $event, $arguments)
		$bean->description = strip_tags(html_entity_decode($bean->description));

This will remove HTML tags from the description field of Cases Module