[rt-users] Problem : A custom field edited via REST will be disabled

[Sylvain Auguy]

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 <falcone at bestpractical.com>:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20140213/bed38851/attachment.htm>