RTC Attribute characters per field
We've been automatically generating RTC workitems from email input for sometime now.
One of the limitations we hit early on was converting the email body into the RTC Description, because the large HTML has a byte size limit of 32k. Which forced us to implement a character limit when converting the email body to the Description, but then add the email body to the WI as an attachment.
We're looking at alternatives for a field for a project which does not want to use this attachment mechanism.
Does anyone have any reference details for the attribute types within RTC that are publicly (or otherwise) available so we can better understand and identify an attribute type that we can use as a custom atrtibute to capture the mail body?
One of the limitations we hit early on was converting the email body into the RTC Description, because the large HTML has a byte size limit of 32k. Which forced us to implement a character limit when converting the email body to the Description, but then add the email body to the WI as an attachment.
We're looking at alternatives for a field for a project which does not want to use this attachment mechanism.
Does anyone have any reference details for the attribute types within RTC that are publicly (or otherwise) available so we can better understand and identify an attribute type that we can use as a custom atrtibute to capture the mail body?
Accepted answer
This topic appears to have duplicated a discussion started earlier.
I have added my comments there, and some of the links to WI requesting enhancements to facilitate attributes with "unlimited" content constraints.
I have added my comments there, and some of the links to WI requesting enhancements to facilitate attributes with "unlimited" content constraints.
Comments
Also please see the first link in the accepted answer to https://jazz.net/forum/questions/204766/size-limits-for-data-fields-in-jazz/204769
2 other answers
Just for interest's sake, why don't they like the attachment approach?
That is the best way to handle large chunks of content.
Cheers,
Geoff
On 7/26/2011 9:23 AM, ddoughty wrote:
That is the best way to handle large chunks of content.
Cheers,
Geoff
On 7/26/2011 9:23 AM, ddoughty wrote:
We've been automatically generating RTC workitems from email input for
sometime now.
One of the limitations we hit early on was converting the email body
into the RTC Description, because the large HTML has a byte size
limit of 32k. Which forced us to implement a character limit when
converting the email body to the Description, but then add the email
body to the WI as an attachment.
We're looking at alternatives for a field for a project which does not
want to use this attachment mechanism.
Does anyone have any reference details for the attribute types within
RTC that are publicly (or otherwise) available so we can better
understand and identify an attribute type that we can use as a custom
atrtibute to capture the mail body?
Just for interest's sake, why don't they like the attachment approach?
That is the best way to handle large chunks of content.
Cheers,
Geoff
On 7/26/2011 9:23 AM, ddoughty wrote:
We've been automatically generating RTC workitems from email input for
sometime now.
One of the limitations we hit early on was converting the email body
into the RTC Description, because the large HTML has a byte size
limit of 32k. Which forced us to implement a character limit when
converting the email body to the Description, but then add the email
body to the WI as an attachment.
We're looking at alternatives for a field for a project which does not
want to use this attachment mechanism.
Does anyone have any reference details for the attribute types within
RTC that are publicly (or otherwise) available so we can better
understand and identify an attribute type that we can use as a custom
atrtibute to capture the mail body?
Errrrrr.......
They're pedantic users, who want to see everything on a single page....
Apart from that, we're kind of pushing the bounds of RTC and using it as a call logging tool for business users to email issues directly into development for rapid turn around. So if they shout loud enough, they kind of get what they want. It beats having to integrate into the likes of proprietary call logging systems (which also dont do what they want them to do).
Also, the sooner IBM get RTC javascripting enabled the better!