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'
The REST query is made by an html form with an input like this : <input type='hidden' value='field1:value1*\n*field2:value2' name='content'/> However, when I analyze the HTML POST Data, I get content=field1%3Avalue1*%0D%0A*field2%3Avalue2 So I can see that the navigator adds a CR (%0D) Is there any way to force the navigator to use only LF without CR ? Otherwise, is there another way to parse those values rather than a new line ? Sylvain 2014-02-10 17:52 GMT+01:00 Kevin Falcone <[email protected]>: > On Mon, Feb 10, 2014 at 02:16:50PM +0100, Sylvain Auguy wrote: > > Ok my bad... It does as you said Kevin, but I still have a problem. > The new customer field > > values are not recognized properly by the pages Modify.html and > ModifyAll.html and it acts as > > if these fields were without any value (while they appear correctly > on Display.html). > > When I perform a request with the mysql CLI client, the display is > very weird. While it is > > correct with a graphical client like mysql workbench. > > You can see it on the attached screenshots (the 3 last lines are the > custom fields which have > > a problem). > > Any idea why these outputs differ depending on the mysql client and > why it interferes with RT > > behavior ? > > The mysql command line client is probably correctly representing the > data in the field while mysqlbench is papering over formatting errors. > > I assume you have extraneous whitespace / line endings, most likely \r > from using a windows machine.. > > You may be able to see better if you run your mysql command line query > with a trailing \G or by running the Content column through mysql's > HEX() function so you can see the literal characters. > > Since those Content values have bogus line endings, they don't match > the CustomFieldValues in RT, so Modify.html won't be able to tell that > the values are the same. > > So - figuring out why your REST client is sending bogus line endings > on trailing characters would be high on the short list of things to > check. > > -kevin >
-- RT Training London, March 19-20 and Dallas May 20-21 http://bestpractical.com/training
