<div dir="ltr">To follow up with my investigations, I saw that the HTML spec stipulates that a new line in a form content will be represented by "CR LF" pairs.<div><a href="http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1">http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1</a><br>
</div><div><div><br></div><div>So, there seems to be no way to edit multiple fields via REST called by an HTML form, because it will always send newlines as \r\n and that RT will recognize only \n as a new line. Or... Am I missing something ?<br>
</div></div><div><br></div><div>Would it be possible to make a patch for this ?</div><div><br></div><div>Sylvain</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-02-13 21:56 GMT+01:00 Sylvain Auguy <span dir="ltr"><<a href="mailto:s.auguy@gmail.com" target="_blank">s.auguy@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Now I can see that the value in the database for a customer field edited by rest is, for instance, 'my value\r' instead of 'my value'<div>
<div><br></div><div>The REST query is made by an html form with an input like this :</div>
<div><br></div><div><input type='hidden' value='field1:value1<b>\n</b>field2:value2' name='content'/></div><div><div><br></div></div></div><div>However, when I analyze the HTML POST Data, I get </div>
<div><br></div><div>content=field1%3Avalue1<b>%0D%0A</b>field2%3Avalue2</div><div><br></div><div>So I can see that the navigator adds a CR (%0D)</div><div><br></div><div>Is there any way to force the navigator to use only LF without CR ?</div>
<div>Otherwise, is there another way to parse those values rather than a new line ?</div><div><br></div><div>Sylvain</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-02-10 17:52 GMT+01:00 Kevin Falcone <span dir="ltr"><<a href="mailto:falcone@bestpractical.com" target="_blank">falcone@bestpractical.com</a>></span>:<div>
<div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Mon, Feb 10, 2014 at 02:16:50PM +0100, Sylvain Auguy wrote:<br>
> Ok my bad... It does as you said Kevin, but I still have a problem. The new customer field<br>
> values are not recognized properly by the pages Modify.html and ModifyAll.html and it acts as<br>
> if these fields were without any value (while they appear correctly on Display.html).<br>
> When I perform a request with the mysql CLI client, the display is very weird. While it is<br>
> correct with a graphical client like mysql workbench.<br>
> You can see it on the attached screenshots (the 3 last lines are the custom fields which have<br>
> a problem).<br>
> Any idea why these outputs differ depending on the mysql client and why it interferes with RT<br>
> behavior ?<br>
<br>
</div>The mysql command line client is probably correctly representing the<br>
data in the field while mysqlbench is papering over formatting errors.<br>
<br>
I assume you have extraneous whitespace / line endings, most likely \r<br>
from using a windows machine..<br>
<br>
You may be able to see better if you run your mysql command line query<br>
with a trailing \G or by running the Content column through mysql's<br>
HEX() function so you can see the literal characters.<br>
<br>
Since those Content values have bogus line endings, they don't match<br>
the CustomFieldValues in RT, so Modify.html won't be able to tell that<br>
the values are the same.<br>
<br>
So - figuring out why your REST client is sending bogus line endings<br>
on trailing characters would be high on the short list of things to<br>
check.<br>
<span><font color="#888888"><br>
-kevin<br>
</font></span></blockquote></div></div></div><br></div>
</blockquote></div><br></div>