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

Kevin Falcone falcone at bestpractical.com
Mon Feb 10 11:52:31 EST 2014

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 235 bytes
Desc: not available
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20140210/b38cc3f4/attachment.sig>

More information about the rt-users mailing list