I am interested in working on a couple of features for otrs... a) For a trusted mail server, it'd be nice if certain terms structured in a specific ways (ie, #^\s*COMMAND\s*$# in the reply messages triggered certain actions. For example, "I'm now working this ticket" might trigger the onwership to change to the account that owns the e-mail address in the from field. "This issue is resolved" might trigger the ticket to be closed. b) The free fields are interesting. I'd like to go farther with them though. It'd be nice if you could add name/value pairs to a ticket dynamically. ie, if you need additional fields, do something to the affect $ticketObj->AddFreeField( 'assetname' => 'computer', 'location' => 'upstairs', 'ipaddress' => '1.1.1.1' ); my $ipaddress = $ticketObj->GetFreeField( name => 'ipaddress' ); With this ability, otrs could become the base for a lot of systems without a lot of extra development. c) It'd be nice to be able to take actions on a group of tickets from the queue view, ie, close them all with the same resolution message. Any recomendations I can keep in mind while working on these features that will increase my chances of getting code accepted the first time? Any coding style documents, rules, etc. (besides the obvious of just looking at the existing code and trying to follow suite)
Hi Jon, On Thu, Feb 05, 2004 at 08:23:16PM -0800, jon@hogue.org wrote:
I am interested in working on a couple of features for otrs...
a) For a trusted mail server, it'd be nice if certain terms structured in a specific ways (ie, #^\s*COMMAND\s*$# in the reply messages triggered certain actions. For example,
"I'm now working this ticket" might trigger the onwership to change to the account that owns the e-mail address in the from field.
"This issue is resolved" might trigger the ticket to be closed.
b) The free fields are interesting. I'd like to go farther with them though. It'd be nice if you could add name/value pairs to a ticket dynamically. ie, if you need additional fields, do something to the affect
$ticketObj->AddFreeField( 'assetname' => 'computer', 'location' => 'upstairs', 'ipaddress' => '1.1.1.1' ); my $ipaddress = $ticketObj->GetFreeField( name => 'ipaddress' );
With this ability, otrs could become the base for a lot of systems without a lot of extra development.
Currently this is solved with TicketFreeFields (http://doc.otrs.org/cvs/en/html/configfile-freetext.html). Usable with PostMaster filter of in the agent frontend. Define a Key and an Value.
c) It'd be nice to be able to take actions on a group of tickets from the queue view, ie, close them all with the same resolution message.
Any recomendations I can keep in mind while working on these features that will increase my chances of getting code accepted the first time? Any coding style documents, rules, etc. (besides the obvious of just looking at the existing code and trying to follow suite)
It sounds good! We are working on the pod docu of the current core modules (http://dev.otrs.org/), maybe it helps you. The style guide is there: http://doc.otrs.org/cvs/en/html/dev-style.html If you have any ideas or any code, post it on here and we can discuss it. And if it's good, then we take it to the tree. PS: Feel free to ask what ever you want! :) Martin -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Manage your communication!
participants (2)
-
jon＠hogue.org -
Martin Edenhofer