Hi,
When I edit a custom field via REST, the associated
"ObjectCustomFieldValue" will, by default, appear as disabled in the
database.
Is there any reason for that ? How can I avoid it ?
I use RT 3.8.4.
Sylvain
When I edit a custom field via REST, the associated “ObjectCustomFieldValue” will, by default,
appear as disabled in the database.
Is there any reason for that ? How can I avoid it ?
I use RT 3.8.4.
When you update the value of a custom field on a ticket, the old
ObjectCustomFieldValue is disabled and a new row with the current
value is inserted.
-kevin
Thanks Kevin
This is the behavior I was expecting, except that in my case, it adds a new
row with the field “disabled = 1”
Is it a known bug that has been solved in a later version ?
Sylvain2014-02-07 17:51 GMT+01:00 Kevin Falcone falcone@bestpractical.com:
On Fri, Feb 07, 2014 at 11:05:04AM +0100, Sylvain Auguy wrote:
When I edit a custom field via REST, the associated
“ObjectCustomFieldValue” will, by default,
appear as disabled in the database.
Is there any reason for that ? How can I avoid it ?
I use RT 3.8.4.When you update the value of a custom field on a ticket, the old
ObjectCustomFieldValue is disabled and a new row with the current
value is inserted.-kevin
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 ?
[image: Images intégrées 1]
[image: Images intégrées 2]
Sylvain2014-02-10 7:11 GMT+01:00 Sylvain Auguy s.auguy@gmail.com:
Thanks Kevin
This is the behavior I was expecting, except that in my case, it adds a
new row with the field “disabled = 1”
Is it a known bug that has been solved in a later version ?Sylvain
2014-02-07 17:51 GMT+01:00 Kevin Falcone falcone@bestpractical.com:
On Fri, Feb 07, 2014 at 11:05:04AM +0100, Sylvain Auguy wrote:
When I edit a custom field via REST, the associated
“ObjectCustomFieldValue” will, by default,
appear as disabled in the database.
Is there any reason for that ? How can I avoid it ?
I use RT 3.8.4.When you update the value of a custom field on a ticket, the old
ObjectCustomFieldValue is disabled and a new row with the current
value is inserted.-kevin
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
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 :
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 ?
Sylvain2014-02-10 17:52 GMT+01:00 Kevin Falcone falcone@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
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.
http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1
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 ?
Would it be possible to make a patch for this ?
Sylvain2014-02-13 21:56 GMT+01:00 Sylvain Auguy s.auguy@gmail.com:
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 :
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@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
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.
Forms in HTML documents
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 ?
You’re only sending \r, if you sent valid POST data, RT would
understand it.
Would it be possible to make a patch for this ?
Hardcoding a form to submit random stuff to the RT REST interface is
begging for trouble (see your current state).
You’re also testing against RT 3.8.4, which currently gets nothing but
security and critical bugfixes and will be end of lifed shortly.
http://bestpractical.com/rt/release-policy.html
-kevin
Ok my RT version is not supported so I don’t demand you to solve this
particular case. However, I think there is a problem in the way RT parses
those values without handling correctly the new lines.
To support my position, I will describe again what I do.
I use the following to send a form with a variable called content which
has, as value, the fields and their values, as follow:
<input type=‘hidden’ value=CF.{Field1}: Value1*\n*CF.{Field2}: Value2’
name=‘content’/>
When I check the form Data which is sent, here is what I get:
- content:
CF.%7BField1%7D%3A+Value1*%0D%0A*CF.%7BField2%7D%3A+Value2
How can you say it is an invalid FORM data ? You can see that it sends %0D%0A
(\r\n) instead of the \n I write in my html form.
And this is the normal behavior described in the HTML specs.
Is the REST interface is not intended to be used with HTML forms ?
If I update RT to a new version (which I can’t), would it solve this ?
Sylvain