[rt-devel] RT API

[Jesse]

Privyet Dima!

	We've actually implemented something like this in RT2.
The difference is that the actions currently only happen _after_
the transaction is recorded (because most actions depend on the content of
the transaction)   Basically, RT2 lets you define "Action" modules that can
do anything you can do within RT.  we use them for autoreplies, forwarding
correspondence, etc....It's not documented very well yet, but it is there.

Spasibo, 

	Jesse

	

On Tue, Nov 21, 2000 at 08:54:13PM +0300, Dmitry S. Rzhavin wrote:
> Hi!
> 
> After a long period of using RT as trouble-ticket-system I feel
> that it will be great if I can add some automatic events to RT.
> But my programming skills are too low to hack yours code :(. But
> I think such ability will be usefull for many people and you can
> be so please to add some changes to your code :).
> The idea is: when something happends (new mail arrived, someone
> added some comments, etc), RT, before adding changes to some
> ticket, calls external program and sends it all information about
> action. Lets say, someone wish to create new ticket in query "test"
> via some interface. RT looks if it have robot for this query.
> It is ok if RT looks for ~rt/etc/actions/<query name>.robot, and
> calls this program if it exists. So, RT calls etc/actions/test.robot
> and sends it information (as parameters, for example):
> 	new_flag	-- 1 if this message is about to create new request
> 	id		-- ticket number (planned ticket number for new request)
> 	operation_code	-- comment/reply/take/resolve
> 	user		-- RT login, '' if non-member sent message
> 	area_name
> 	current_status	-- 'open' for new request
> 	requestor
> after calling this program, RT sends it (via pipe, for exapmle) subject
> of current ticket (1st string for example, '' if RT is about to create
> new 
> request), message subject (2nd string, '' if action is not via email),
> and text of request then (after all parsing). And then RT waits for
> program
> to finish, accepting output from it as commands, like "give <username>",
> "status <new status>", "priority <number>", and some additional
> commands, like
> 	drop 		-- forget about this request, just skip id if request was new
> 	message	<arg>	-- from next line message follows. There must be some
> 			   terminator at the end of message to allow commands after
> 			   it, its important.
> 		<arg> can be one of:
> 			owner		-- send followed message to owner of ticket
> 			members		-- send followed message to query members
> 			requestor	-- send followed message as reply to requestor
> 			RT		-- place followed message to RT instead of
> 					   original user's message
> 
> It will be even better if you force users to use perl for those scripts
> (what
> else can people use to process text??? :), and call my code as function,
> giving
> it all information as parameters (+3 arrays with default messages to
> owner,
> members and requestor) and use returning values as 5 arrays (commands,
> message
> to place into RT and 3 replies).
> 
> Thats all actually.
> Thank you if you are still reading it at least :)
> 
> _______________________________________________
> Rt-devel mailing list
> Rt-devel at lists.fsck.com
> http://lists.fsck.com/mailman/listinfo/rt-devel
> 

-- 
jesse reed vincent -- root at eruditorum.org -- jesse at fsck.com 
70EBAC90: 2A07 FC22 7DB4 42C1 9D71 0108 41A3 3FB3 70EB AC90

<lamont> I'm reasonably sure that at least two of the electric blue kangeroos
         I saw were real.