I am using RT 3.8.
I would like to add a custom field (type: Fill in one text area) that
requires an account number to be entered in and then have that value get
passed to an existing perl-SOAP-Lite interface that exists on a remote
server.
I would then like to take the values returned from that server and use
them to auto-populate the other custom fields (textboxes) on the same
ticket page (Customer_Name, Customer_Type, etc).
I have been playing around with custom fields and have even gotten them to
populate dynamically using data contained withing RT itself (users,
groups, etc) but now I need to reach out and touch remote data and
integrate it into RT tickets!
I am a recent refugee from the Microsoft .net world and I am making the
transition to opensource and specifically in this case: Rt and perl so
please be easy on me!
Any help is much appreciated.
Thanks,
Daniel A. Kalfon
It’s almost as if you have read our minds!
Right now we are sketching out a standard AJAX interface to populate
custom fields. The main ideas we have:
-Custom fields are declared plain text input in RT.
-Custom fields with special names are trapped in
Ticket/Elements/EditCustomFields are put come in a JSON serialed form in
a hidden field.
-A JS reads the JSON definition and rules and draws the custom fields
section in a specified
-The JS will be able to access web-services on the server that can
dynamically populate value lists or show/hide fields depending on some
rules that come from the server.
Upon save it’s all just standard RT, since they are actual CustomFields.
Now, IMHO this should be designed very atomically so any part can be
re-used in the standard RT product and compatible mostly compatible with
the current main versions 3.6 and 3.8. And BTW we are using 3.6 and
don’t plan to migrate until 2009.
I would like to know if a) this sounds like what you’re
[dkalfon@voxcorp.net] looking for and b) what are the plans of the
original author regarding dynamic front-end and WS technologies. IMHO
SOAP is overkill and dreadfully complex so a RESTful approach would be
better. Perhaps the RT team has already envisioned a standard WS API?
Please advise, or give us the liberty to propose one?
My general take on this is REST, JSON, Prototype but I “hear” that
JQuery is a better option (I’ve used Prototype extensively and never
needed anything more, but always open to other).El mar, 05-08-2008 a las 22:07 -0400, dkalfon@voxcorp.net escribió:
I am using RT 3.8.
I would like to add a custom field (type: Fill in one text area) that
requires an account number to be entered in and then have that value get
passed to an existing perl-SOAP-Lite interface that exists on a remote
server.
I would then like to take the values returned from that server and use
them to auto-populate the other custom fields (textboxes) on the same
ticket page (Customer_Name, Customer_Type, etc).
I have been playing around with custom fields and have even gotten them to
populate dynamically using data contained withing RT itself (users,
groups, etc) but now I need to reach out and touch remote data and
integrate it into RT tickets!
I am a recent refugee from the Microsoft .net world and I am making the
transition to opensource and specifically in this case: Rt and perl so
please be easy on me!
Any help is much appreciated.
Thanks,
Daniel A. Kalfon
List info: The rt-devel Archives
My general take on this is REST, JSON, Prototype but I “hear” that
JQuery is a better option (I’ve used Prototype extensively and never
needed anything more, but always open to other).
In RT 3.x, we’re using Prototype here and there, though in Jifty we’ve
moved over to JQuery and are a lot happier. RT 4 uses Jifty and will use
JQuery, hopefully fully retiring prototype.
-j
Ahhh, Jifty… (of course, I didn’t relate your name at first! 
)
Cool JA WebFramework! Man, I just love the Perl world .- I started with
CGI then CGI::Application then Catalyst and now guess I’ll get my feet
wet with Jifty. Hope I get the same awe as when I tried AnyEvent/EV
after POE
Anyway, back to our AJAX hack, so if we do somethings with 3.6, 3.8 we
will keep it in Prototype and try to isolate the JS lib as much as
possible. I had not noticed AJAX in the 3.6 code, then again, we are are
very new to the code of RT (albeit not to the use of).
If not too much trouble, could you point to us an example of how AJAX is
being used in 3.6? Perhaps you referred to the use of Prototype for
client-side stuff only? I am guessing the latter.
Since we are not going to play with RT 4 for a while, and if we would
like to publish this work for RT 3.x, how would you recommend we
implement it? (in general terms.) If there is any AJAX at least in 3.8
just point to it and we will follow the general pattern (our current
project is with 3.6 so I haven’t even looked at the 3.8 stuff)
Thanks!
Alejandro ImassEl mié, 06-08-2008 a las 13:05 -0400, Jesse Vincent escribió:
My general take on this is REST, JSON, Prototype but I “hear” that
JQuery is a better option (I’ve used Prototype extensively and never
needed anything more, but always open to other).
In RT 3.x, we’re using Prototype here and there, though in Jifty we’ve
moved over to JQuery and are a lot happier. RT 4 uses Jifty and will use
JQuery, hopefully fully retiring prototype.
-j
If not too much trouble, could you point to us an example of how
AJAX is
being used in 3.6? Perhaps you referred to the use of Prototype for
client-side stuff only? I am guessing the latter.
Autocompleting custom fields and the “favorite tickets” are the two
things come tim mind.
Since we are not going to play with RT 4 for a while, and if we would
like to publish this work for RT 3.x, how would you recommend we
implement it? (in general terms.) If there is any AJAX at least in 3.8
just point to it and we will follow the general pattern (our current
project is with 3.6 so I haven’t even looked at the 3.8 stuff)
That’s really too bad. RT 3.6 is now the “old stable” release rather
than the “current stable” release, which means that if you’re just
starting out, you’re going to end up way behind. 3.6 is only getting
“critical” security fixes at this point. 3.8 has hundreds of bugs
fixed which were still present in 3.6.7.
-j