Skip to main content

Greetings:

When using LazyApproval I like to include form data in a nicely formatted HTML table in the email so the Approver knows what he or she is approving or rejecting. But I've run into an issue with form data that includes a multi-line rich-text "description" field in which spurious line breaks (<BR />) are added after each <P/> and </LI> tag in the rendering of the email, even though these tags are not in the description field itself.

To be specific, I am storing the following string in a workflow variable called FormattedData:

Capture_1a.PNG

where the variable TripDescription is the multi-line rich-text field where I have earlier replaced "&lt;" with "<" anf "&gt;" with ">" using fn-Replace in a string builder action.

This is added to the Approver's email in the Task Notification component of a Request Approval action:

Capture_1b.PNG

For debugging purposes I am capturing the FormattedData variable into a list column and it looks fine.  A sample list item looks like this:

Capture_1c.PNG

which renders in a browser like this:

Capture_1d.PNG

So there is nothing wrong with the data itself.  However, this is how it appears in the email:

Capture_1e.PNG

and when I do a "View Source" the HTML looks like this:

Capture_1f.PNG

If you look at the highlighted description field you'll see that the original FormattedData variable, which looked just fine, has been transfromed with lots of <BR /> tags that make it look so ugly in the output. 

How to avoid this is the question.

Thanks,

Bruce

Hi Bruce,

Did you try fn-XmlDecode or fn-XmlEncode for the FormattedData.

Give it a  try.

Sojan:

Thanks for the reply. I tried fn-XMLDecode but the problem persists.  Admittedly, fn-XMLDecode is a better method for recovering the HTML tags in the description field than the fn-Replace method that I used, but the effect is the same.  The HTML being embedded in the email is correct but contains line breaks when displayed in the email. 

By the way, this is not an Outlook problem. The same problem exists when the mail is viewed through Mail on OS X and in a Web mail client because it is the underlying HTML that is changed (<BR /> tags added) so any mail client or browser will render it more or less the same way.

I see that I applied fn-XMLDecode to the TripDescription variable rather than to the whole table in FormattedData, as you suggested.  So I tried it also on FormattedData but it also had no effect.

Hi Bruce,

I remember I was having this issue, just make sure that final string "FormattedData" that you constructed should display in a single line. It shouldn't be like the one you pasted above. When you copy paste the string value in notepad, it should display in single line.

All the newlines after <tr> is coming as <br> in display

Yes,  that's what I'm doing.  All my HTML code is entered as a single line of text. Thanks for the suggestion, though. 

Can send me that string, i just want to try.

I have tried with small data, was getting the similar issue. 

When I used <br/> instead of <p></p> , it was fine.

Thanks, I sent it to you by email.

Sojan:

I used fn-Replace to replace all <P> with <br/> and all </P> with an empty string.  Good suggestion, but it didn't work. Something (I don't know what) keeps inserting <BR /> tags at line breaks.  No joy.  I have opened a support ticket but if the HTML is being mangled by a mail server en route there may be no fix.

Hi Bruce,

Thanks for sending the file. I was expecting the final data string without the workflow variable. In email notification change the data display from rich text to plain text. So you will get the final html string with tags. See if there is any <br/> in there.

Hi Bruce,


When you compose your HTML in notepad, be sure not to press the ENTER key after any tag.   Make your HTML is one big run on sentence/giant never ending string and your problem should go away.  This  is how I've fixed this same problem in the past.    You may also have to change Rich Text to Plain text in that drop down you see.

-Thanks,

Mike

Hi Bruce,

I think it's your TripDescription variable that needs investigation rather than the FormattedData variable.  I can't quite figure out how you've created it.  Did you take the contents of a rich text field and run a fn-replace on it?  It's this variable that seems to have the extra carriage returns in it and once you get rid of them, it should render much better.  If you display the contents of TripDescription it should be displayed on one continuous line, it shouldn't have carriage returns anywhere (highlighted in red below).

As Chris depicted above in red, those are the spots I suggest not pressing  ENTER.  Instead press delete to get rid of them and have all the HTML appear on a single line.   Once you have done this test it out.  If the spaces are appearing by themselves after you have done this, let us know.

‌ can you let us know whether this resolved the issue for you please and we can mark this as resolved for other users.

Mike:

The HTML code for the entire formatted table is already one string with no breaks. The code that I showed above, in the very first image, included line breaks just to make it easier to read.  The problem is in the TripDescription variable, over which I have no control since it comes straight out of the form's rich content editor.

Yes, Chris is correct. This comes out of the form's rich text editor.  I can manipulate this to some degree with fn-Replace or fn-XmlDecode but at that point in the workflow there are no <BR /> tags to replace. It's only after whole table is embedded in an email and sent that the <BR /> tags appear, so there is no way to replace them in the workflow.

Ryan:

I'm very impressed and grateful for all the helpful suggestions of the community.  However, none of these suggestions actually helped very much.  THe "spurious line breaks" that I have been writing about are coming from somewhere that I cannot control.

What I have done to minimize the problem is to write the TripDesciption data to, and retrieve it from, the list vs. the XML form data. It seems to be better behaved that way.  After replacing <li> with <li /> and removing <li/> the white space problem is manageable.

FYI, the release notes for Workflow 2010  2.5.3.0, released on April 26, contain this line:

      Rectified the multiple addition of line breaks when editing the source HTML in Send Notification (59600)

This sound like exactly what I was encountering so I'll install this version ASAP and see if it fixes the issue described in this posting.

Hello, 

I just updated my Nintex Workflow with the version : 3.2.2.10

And I have this issue in my Mail Notification. 

Here is the code i get after saving :

203139_pastedImage_1.png

I just sent an email to the Nintex Support who ask me to upgrade my version to solve an other issue (BTW the previous issue seems fixed, but this new one is way far worse :S)

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings