I’m looking into a contract that requires (among many other things)
ticket tracking and I would like to know how reasonable it is to
integrate large sets of functionality to RT without breaking the
maintenance cycle.
Thank you for your time.
Joshua Colson jcolson@realm.ination.cc
!DSPAM:29,441b021f317233335862897!
I’m looking into a contract that requires (among many other things)
ticket tracking and I would like to know how reasonable it is to
integrate large sets of functionality to RT without breaking the
maintenance cycle.
We do certainly go into extension mechanisms in the book.
http://rtbook.bestpractical.com should have a pointer to the index.
Joshua,
Your question seems a bit vague. Your subject mentions "extentions",
then you mention large sets of functionality. What “kind” of
functionality? Is it something already being offered in 3.6? Is it
linking to other systems?
Kenn
Joshua Colson wrote:
Joshua,
Your question seems a bit vague. Your subject mentions "extentions",then you mention large sets of functionality. What “kind” of
functionality? Is it something already being offered in 3.6? Is it
linking to other systems?Kenn
My apologies. I’ve always had a problem with articulating questions.
Basically, what I’m trying to do (unfortunately all of the requirements
have not been defined as yet) is connect to a RETS (Real Estate
Transaction Server) on ticket creation and pull some data (Agent ID,
Agent Name, Listing ID, etc.). I want that data tied to the ticket in
some fashion. I’m not sure yet if it makes sense to define custom fields
for the data or if it should just reference external sources. I also
need the system to take some of the data that it has fetched and
generate faxes and/or print jobs that are automatically handled (handed
off to hylafax/cups/whatever). There are many more requirements, but
that is the idea. Basically inserting functionality in at various points
in the process. I understand that scrips can do most of what I want. I
really was just curious what the book has to say about it because I
would like to buy it, but I don’t want it to just sit on my shelf.
Thank you for your input.
Joshua Colson jcolson@realm.ination.cc
Joshua,
Your question seems a bit vague. Your subject mentions "extentions",then you mention large sets of functionality. What “kind” of
functionality? Is it something already being offered in 3.6? Is it
linking to other systems?Kenn
My apologies. I’ve always had a problem with articulating questions.
Basically, what I’m trying to do (unfortunately all of the requirements
have not been defined as yet) is connect to a RETS (Real Estate
Transaction Server) on ticket creation and pull some data (Agent ID,
Agent Name, Listing ID, etc.). I want that data tied to the ticket in
some fashion. I’m not sure yet if it makes sense to define custom fields
for the data or if it should just reference external sources. I also
need the system to take some of the data that it has fetched and
generate faxes and/or print jobs that are automatically handled (handed
off to hylafax/cups/whatever). There are many more requirements, but
that is the idea. Basically inserting functionality in at various points
in the process. I understand that scrips can do most of what I want. I
really was just curious what the book has to say about it because I
would like to buy it, but I don’t want it to just sit on my shelf.Thank you for your input.
If you use RT, you should buy it. 
Joshua,
Your question seems a bit vague. Your subject mentions "extentions",then you mention large sets of functionality. What “kind” of
functionality? Is it something already being offered in 3.6? Is it
linking to other systems?Kenn
My apologies. I’ve always had a problem with articulating questions.
Basically, what I’m trying to do (unfortunately all of the requirements
have not been defined as yet) is connect to a RETS (Real Estate
Transaction Server) on ticket creation and pull some data (Agent ID,
Agent Name, Listing ID, etc.). I want that data tied to the ticket in
some fashion. I’m not sure yet if it makes sense to define custom fields
for the data or if it should just reference external sources. I also
need the system to take some of the data that it has fetched and
generate faxes and/or print jobs that are automatically handled (handed
off to hylafax/cups/whatever). There are many more requirements, but
that is the idea. Basically inserting functionality in at various points
in the process. I understand that scrips can do most of what I want. I
really was just curious what the book has to say about it because I
would like to buy it, but I don’t want it to just sit on my shelf.Thank you for your input.
If you use RT, you should buy it.
That is not really the answer he is waiting for.
I am wondering the same as Joshua, as we deal with information we need to pull from great p(l)ains. (Sometime in the near future)
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.comDiscover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.comWe’re hiring! Come hack Perl for Best Practical: Careers — Best Practical Solutions
A sine curve goes off to infinity or at least the end of the blackboard
– Prof. Steiner
My apologies. I’ve always had a problem with articulating questions.
Basically, what I’m trying to do (unfortunately all of the requirements
have not been defined as yet) is connect to a RETS (Real Estate
Transaction Server) on ticket creation and pull some data (Agent ID,
Agent Name, Listing ID, etc.). I want that data tied to the ticket in
some fashion. I’m not sure yet if it makes sense to define custom fields
for the data or if it should just reference external sources. I also
need the system to take some of the data that it has fetched and
generate faxes and/or print jobs that are automatically handled (handed
off to hylafax/cups/whatever). There are many more requirements, but
that is the idea. Basically inserting functionality in at various points
in the process. I understand that scrips can do most of what I want. I
really was just curious what the book has to say about it because I
would like to buy it, but I don’t want it to just sit on my shelf.Thank you for your input.
If you use RT, you should buy it.
That is not really the answer he is waiting for.
I am wondering the same as Joshua, as we deal with information we need to pull
from great p(l)ains. (Sometime in the near future)
Then I still don't understand the question.
Will the book tell him how to do those things? No.
Will the book make it easier for him to figure out how to do them? Almost certainly.
Is it impossible to do these things without the book? No.
Are there aspects of RT not covered in the book? Of course.
Do I recommend getting the book anyway? Yes.
I learned most about RT by reading the code, and I made some
mods before the book was out, even before the wiki was
available. So, the book wasn't as useful to me as it would be
to someone new, I already knew much of it. Still, someone
else in my department is doing some RT work, and I made her
get her own copy. I'm willing to let the book move to another
room, but not another building :-)
bobg
Basically, what I’m trying to do (unfortunately all of the requirements
have not been defined as yet) is connect to a RETS (Real Estate
Transaction Server) on ticket creation and pull some data (Agent ID,
Agent Name, Listing ID, etc.). I want that data tied to the ticket in
some fashion. I’m not sure yet if it makes sense to define custom fields
for the data or if it should just reference external sources.
From a generic design standpoint: this depends on your desired binding
time. If what you what to know is what those (possibly externally
changeable) fields said when you created the ticket, copy that data
into custom fields.
If you want to know what they contain when you look, then you can
just store the reference.
Cheers,
– jra
Jay R. Ashworth jra@baylink.com
Designer Baylink RFC 2100
Ashworth & Associates The Things I Think '87 e24
St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274
A: No.
Q: Should I include quotations after my message body?