WriteCustomAction - Revision history

Kincl: Fixing greater than symbols post import from old wiki and adding pre wrappers

2016-08-15T17:38:42Z

Fixing greater than symbols post import from old wiki and adding pre wrappers

Bduye: /* From "User Defined" to a module */

2016-07-21T10:21:46Z

From "User Defined" to a module

← Older revision		Revision as of 06:21, 21 July 2016
Line 217:		Line 217:

	</pre>		</pre>

			''Note'': for RT4, replace '''RT::Action::Generic''' by '''RT::Action'''

	That's it. Save it as '''lib/RT/Action/MyAction.pm''' (it is important that the file have the same name as the package ("MyAction" in the example)), fill in preparation and commit code then you can register your action in the DB. Use the following data file and [[AddDatabaseRecords]] instructions.		That's it. Save it as '''lib/RT/Action/MyAction.pm''' (it is important that the file have the same name as the package ("MyAction" in the example)), fill in preparation and commit code then you can register your action in the DB. Use the following data file and [[AddDatabaseRecords]] instructions.

Bduye: add

blocks

2016-07-20T21:51:09Z

add <pre> </pre> blocks

← Older revision		Revision as of 17:51, 20 July 2016
Line 189:		Line 189:

	User defined actions you write in the web UI are handy and quick way to write an action. However, at some point you want to re-use your action, make it configurable, edit it in more suitable editor rather than text area, make it more complex and consist of additional methods. So it's time to move from "User Defined" action to your first module file.		User defined actions you write in the web UI are handy and quick way to write an action. However, at some point you want to re-use your action, make it configurable, edit it in more suitable editor rather than text area, make it more complex and consist of additional methods. So it's time to move from "User Defined" action to your first module file.

			<pre>

	use strict;		use strict;
Line 214:		Line 216:
	1;		1;

	That's it. Save it as [=lib/RT/Action/MyAction.pm](it is important that the file have the same name as the package ("MyAction" in the example)), fill in preparation and commit code then you can register your action in the DB. Use the following data file and [[AddDatabaseRecords]] instructions.		</pre>

			That's it. Save it as '''lib/RT/Action/MyAction.pm''' (it is important that the file have the same name as the package ("MyAction" in the example)), fill in preparation and commit code then you can register your action in the DB. Use the following data file and [[AddDatabaseRecords]] instructions.

			<pre>

	@ScripActions = (		@ScripActions = (
Line 224:		Line 230:
	},		},
	);		);

			</pre>

	Now your action in the DB and you can pick it for a scrip through the Web UI instead of picking "User Defined".		Now your action in the DB and you can pick it for a scrip through the Web UI instead of picking "User Defined".

Medea61: /* Step by step or "Tickets, transactions and attachments" */

2016-07-19T17:15:10Z

Step by step or "Tickets, transactions and attachments"

← Older revision		Revision as of 13:15, 19 July 2016
Line 156:		Line 156:
	Lets look what happens with RT from the beginning when a user clicks on create button in their browser. Web server gets request with queue id, ticket subject and body, owner and etc. RT fetches info from the request that is needed for Ticket record: its Queue id, Status, Subject, [[CurrentUser]](Creator), and then runs the next code:		Lets look what happens with RT from the beginning when a user clicks on create button in their browser. Web server gets request with queue id, ticket subject and body, owner and etc. RT fetches info from the request that is needed for Ticket record: its Queue id, Status, Subject, [[CurrentUser]](Creator), and then runs the next code:

	<~~nowiki~~>		<pre>
	# init empty instance of RT::Ticket class		# init empty instance of RT::Ticket class
	my $TicketObj = RT::Ticket->new( $session{'CurrentUser'} );		my $TicketObj = RT::Ticket->new( $session{'CurrentUser'} );
Line 165:		Line 165:
	my $id = $TicketObj->Create( %ARGS );		my $id = $TicketObj->Create( %ARGS );

	</~~nowiki~~>		</pre>

	Ticket is created and it's time to record transaction into table. RT has all info for this: ticket's id that was recently created and transaction type - 'Create'.		Ticket is created and it's time to record transaction into table. RT has all info for this: ticket's id that was recently created and transaction type - 'Create'.

	<~~nowiki~~>		<pre>
	# this call creates new transaction record		# this call creates new transaction record
	# this is very similar to situation with new ticket record		# this is very similar to situation with new ticket record
	my $TransactionObj = $Ticket->_RecordTransaction( %ARGS );		my $TransactionObj = $Ticket->_RecordTransaction( %ARGS );

	</~~nowiki~~>		</pre>

	Transactions in RT has an many-to-one mapping with ticket. One ticket => one or more transactions. You can get collection of transactions by calling Transactions method on a ticket object:		Transactions in RT has an many-to-one mapping with ticket. One ticket => one or more transactions. You can get collection of transactions by calling Transactions method on a ticket object:
			<pre>
	my $transactions = $TicketObj->Transactions;		my $transactions = $TicketObj->Transactions;
			</pre>
	Each transaction belongs to only one ticket and you get ticket object with the following code:		Each transaction belongs to only one ticket and you get ticket object with the following code:
			<pre>
	my $ticket = $TransactionObj->TicketObj;		my $ticket = $TransactionObj->TicketObj;
			</pre>
	As you can see RT still didn't use content that you wrote in the body. Content is an RT::Attachment object. You know how RT creates new record and know about Ticket-Transaction relation, the same relationship applies to Attachments and Transactions.		As you can see RT still didn't use content that you wrote in the body. Content is an RT::Attachment object. You know how RT creates new record and know about Ticket-Transaction relation, the same relationship applies to Attachments and Transactions.

Medea61: /* How to change ticket custom field values */

2016-07-19T17:13:41Z

How to change ticket custom field values

← Older revision		Revision as of 13:13, 19 July 2016
Line 120:		Line 120:
	Step 1, get the custom field (CF) object or ID. Don't use the hardcoded CF ID from the database. [why?] Step 2, get the CF object by ticket object by ticket object (I hope you remember how to get a ticket object) and CF name.		Step 1, get the custom field (CF) object or ID. Don't use the hardcoded CF ID from the database. [why?] Step 2, get the CF object by ticket object by ticket object (I hope you remember how to get a ticket object) and CF name.

	<~~nowiki~~>		<pre>
	...		...
	my $CFName = 'MyCustomField';		my $CFName = 'MyCustomField';
Line 136:		Line 136:
	}		}
	...		...
			</pre>
	</~~nowiki~~>

	Now we could add value to ticket:		Now we could add value to ticket:
			<pre>
	my $Value = 'MyValue';		my $Value = 'MyValue';
	$Ticket->AddCustomFieldValue( Field => $CF, Value => $Value );		$Ticket->AddCustomFieldValue( Field => $CF, Value => $Value );
			</pre>
	or		or
			<pre>
	$Ticket->AddCustomFieldValue( Field => $CF, Value => $Value, RecordTransaction => 0 );		$Ticket->AddCustomFieldValue( Field => $CF, Value => $Value, RecordTransaction => 0 );
			</pre>
	you also could use custom field id instead of object.		you also could use custom field id instead of object.
			<pre>
	$Ticket->AddCustomFieldValue( Field => NN , Value => $Value );		$Ticket->AddCustomFieldValue( Field => NN , Value => $Value );
			</pre>

	== Step by step or "Tickets, transactions and attachments" ==		== Step by step or "Tickets, transactions and attachments" ==

Admin at 14:28, 14 June 2016

2016-06-14T14:28:37Z

← Older revision		Revision as of 10:28, 14 June 2016
Line 64:		Line 64:
	[[File:Example1ScripBehavior.png\|thumb\|275px]]Preparation code:		[[File:Example1ScripBehavior.png\|thumb\|275px]]Preparation code:

	<nowiki># we don't need any preparation yet.		<nowiki>
			# we don't need any preparation yet.
	return 1;		return 1;

	</nowiki>		</nowiki>

	Commit code:		Commit code:
Line 119:		Line 120:
	Step 1, get the custom field (CF) object or ID. Don't use the hardcoded CF ID from the database. [why?] Step 2, get the CF object by ticket object by ticket object (I hope you remember how to get a ticket object) and CF name.		Step 1, get the custom field (CF) object or ID. Don't use the hardcoded CF ID from the database. [why?] Step 2, get the CF object by ticket object by ticket object (I hope you remember how to get a ticket object) and CF name.

	<nowiki>...		<nowiki>
			...
	my $CFName = 'MyCustomField';		my $CFName = 'MyCustomField';
	my $CF = RT::CustomField->new( $RT::SystemUser );		my $CF = RT::CustomField->new( $RT::SystemUser );
Line 134:		Line 136:
	}		}
	...		...

	</nowiki>		</nowiki>

	Now we could add value to ticket:		Now we could add value to ticket:
Line 154:		Line 156:
	Lets look what happens with RT from the beginning when a user clicks on create button in their browser. Web server gets request with queue id, ticket subject and body, owner and etc. RT fetches info from the request that is needed for Ticket record: its Queue id, Status, Subject, [[CurrentUser]](Creator), and then runs the next code:		Lets look what happens with RT from the beginning when a user clicks on create button in their browser. Web server gets request with queue id, ticket subject and body, owner and etc. RT fetches info from the request that is needed for Ticket record: its Queue id, Status, Subject, [[CurrentUser]](Creator), and then runs the next code:

	<nowiki># init empty instance of RT::Ticket class		<nowiki>
			# init empty instance of RT::Ticket class
	my $TicketObj = RT::Ticket->new( $session{'CurrentUser'} );		my $TicketObj = RT::Ticket->new( $session{'CurrentUser'} );

Line 161:		Line 164:
	# this call is inherited from SearchBuilder API		# this call is inherited from SearchBuilder API
	my $id = $TicketObj->Create( %ARGS );		my $id = $TicketObj->Create( %ARGS );

	</nowiki>		</nowiki>

	Ticket is created and it's time to record transaction into table. RT has all info for this: ticket's id that was recently created and transaction type - 'Create'.		Ticket is created and it's time to record transaction into table. RT has all info for this: ticket's id that was recently created and transaction type - 'Create'.

	<nowiki># this call creates new transaction record		<nowiki>
			# this call creates new transaction record
	# this is very similar to situation with new ticket record		# this is very similar to situation with new ticket record
	my $TransactionObj = $Ticket->_RecordTransaction( %ARGS );		my $TransactionObj = $Ticket->_RecordTransaction( %ARGS );

	</nowiki>		</nowiki>

	Transactions in RT has an many-to-one mapping with ticket. One ticket => one or more transactions. You can get collection of transactions by calling Transactions method on a ticket object:		Transactions in RT has an many-to-one mapping with ticket. One ticket => one or more transactions. You can get collection of transactions by calling Transactions method on a ticket object:
Line 210:		Line 214:
	1;		1;

	That's it. Save it as [=lib/RT/Action/MyAction.pm], fill in preparation and commit code then you can register your action in the DB. Use the following data file and [[AddDatabaseRecords]] instructions.		That's it. Save it as [=lib/RT/Action/MyAction.pm](it is important that the file have the same name as the package ("MyAction" in the example)), fill in preparation and commit code then you can register your action in the DB. Use the following data file and [[AddDatabaseRecords]] instructions.

	@ScripActions = (		@ScripActions = (

Admin: 12 revisions imported

2016-04-06T20:39:47Z

12 revisions imported

New page

This text in Portuguese in [[WriteCustomActionBR]]

How to write custom action code

== Introduction ==

Included in RT3 is the ability to create your own custom ticket actions via the Web UI. The RT3 Custom Scrip capability lets you access the RT API and is a very powerful tool for customising RT.

== Basics ==

[[File:Example1ScripUI.png|thumb|left|325px|Modify a scrip UI]]Let's start with Web UI. Goto Configuration -> Globals -> Scrips -> New Scrip.

The Scrip UI will display the following selectors: Description, Condition, Action, Template and Stage. In the action selector you can pick actions based on files (modules). An outstanding action from this list is "User Defined". The rest of this document describes this action. So in the Action field, select "User Defined" from the menu.

Once you have selected "User Defined" from the Action Field, the following two Action code areas are enabled and used by RT:
* Custom action preparation code
* Custom action cleanup code

When a [[Transaction]] is created, RT does the following steps to enable all this magic and give you a chance to be a small God:

* Select [[Scrip|Scrips]]
* Check applicability of scrips by executing [[Condition]]s
* Execute preparation code scrip by scrip
* Scrips that fail will be thrown away
* Execute commit code of survived scrips proceeding scrip by scrip

When RT executes your perl Action code within this scrip, your code can become an actor upon the ticket. RT has already defined the variable $self. This variable represents an instance of class [=RT::Action::[[UserDefined]]], a subclass of <code>RT::Action::Generic</code>. You can get more info from perldoc and from the source code.

Instance <code>$self</code> provides your Action code with very useful methods:

$self->TransactionObj

Returns <code>RT::Transaction</code> instance, the transaction that has been created and caused all this.

$self->TicketObj

Returns <code>RT::Ticket</code> instance which represents the ticket. Our transaction was applied to it.

$self->TemplateObj

Returns the template (<code>RT::Template</code>) which was selected for this scrip.

=== Getting more info about these objects ===

You can get complete information about these objects from their POD (embedded documentation).

perldoc /opt/rt3/lib/RT/Ticket.pm
perldoc /opt/rt3/lib/RT/Ticket_Overlay.pm
perldoc /opt/rt3/lib/RT/Tickets.pm
perldoc /opt/rt3/lib/RT/Tickets_Overlay.pm
perldoc /opt/rt3/lib/RT/Transaction.pm
perldoc /opt/rt3/lib/RT/Transaction_Overlay.pm
perldoc /opt/rt3/lib/RT/Transactions.pm
perldoc /opt/rt3/lib/RT/Transactions_Overlay.pm
...

== Simple example ==

Ok, let's try to change something.

Requirement: There is a support queue for special customers where each request must have high priority on ticket creation.

[[File:Example1ScripBehavior.png|thumb|275px]]Preparation code:

<nowiki># we don't need any preparation yet.
return 1;

</nowiki>

Commit code:

$self->TicketObj->SetPriority( 100 );
return 1;

I hope that this example is understandable enough, but it has at least one weakness. I've hardcoded the priority value. Since RT lets the administrator define default final priority per queue, our code should reflect that.

my $qfp = $self->TicketObj->QueueObj->FinalPriority || 100;
$self->TicketObj->SetPriority( int( $qfp * 0.9 ) );
return 1;

This change to the logic first retrieves the [[FinalPriority]] of the current Queue or 100 if no [[FinalPriority]] is set for the Queue. Then it sets the Priority of this ticket to 90% of the retrieved Priority. The final 10% of the priority is reserved for very exclusive, super high priority requests.

== Errors handling ==

It's important to check errors to protect you from headache. Most methods in RT that change something return a tuple ($status, $msg). If $status is not true value then something failed and $msg is error text describing the reason. Let's extend our code:

my $qfp = $self->TicketObj->QueueObj->FinalPriority || 100;
my ($status, $msg) = $self->TicketObj->SetPriority( int( $qfp * 0.9 ) );
unless ( $status ) {
$RT::Logger->error("Couldn't change priority: $msg");
return 0;
}
return 1;

== What you can (not) do with scrips ==

You can manipulate almost any object in RT within a scrip.

* update properties of tickets, for example set properties of tickets with commands in email
* change linked tickets, for example [[OpenTicketOnAllMemberResolve]] and [[OpenDependantsOnResolve]]
* extract info from messages, implement own workflow, create approvals and many-many more actions

Let's talk about impossible things you don't even want to try to do with a scrip:

* you couldn't deny action scrip's triggered, for example you don't want to allow users to open ticket unless it has owner, you may think that you can create scrip "on ticket open block action if ticket has no owner", but it's impossible. I said impossible? no... sure you can create such scrip, but instead of preventing action you can revert it by setting status back to old value. yeah, this works but don't forget that it would be two transactions 'set open status' and 'set previouse status'. Each action could be applied to other scrips, so really it's not preventing action.
* you couldn't run scrip at some time, remember RT runs scrips after creating transactions, but of course we have solution for this situation - rt-crontool.

== How to be silent ==

Now you put SetXxxx calls all over the places in RT and suddenly note that strange transactions appear in tickets. They have creator [[RT System|RT_System]] and describe what you've done with your scrips. Sometimes it's better to be silent and not mislead users. These transactions also go through the steps described earlier and could trigger some conditions too. Just use the long form of SetXxx functions:

$TicketObj->_Set(Field => 'Priority', Value => 90, RecordTransaction => 0);

The zero in the [[RecordTransaction]] argument informs RT not to record the change as a new transaction.

== How to change ticket custom field values ==

Step 1, get the custom field (CF) object or ID. Don't use the hardcoded CF ID from the database. [why?] Step 2, get the CF object by ticket object by ticket object (I hope you remember how to get a ticket object) and CF name.

<nowiki>...
my $CFName = 'MyCustomField';
my $CF = RT::CustomField->new( $RT::SystemUser );
$CF->LoadByNameAndQueue( Name => $CFName, Queue => $Ticket->Queue );
# RT has bug/feature until 3.0.10, you should load global CF yourself
unless( $CF->id ) {
# queue 0 is special case and is a synonym for global queue
$CF->LoadByNameAndQueue( Name => $CFName, Queue => '0' );
}

unless( $CF->id ) {
$RT::Logger->error( "No field $CFName in queue ". $Ticket->QueueObj->Name );
return undef;
}
...

</nowiki>

Now we could add value to ticket:

my $Value = 'MyValue';
$Ticket->AddCustomFieldValue( Field => $CF, Value => $Value );

or

$Ticket->AddCustomFieldValue( Field => $CF, Value => $Value, RecordTransaction => 0 );

you also could use custom field id instead of object.

$Ticket->AddCustomFieldValue( Field => NN , Value => $Value );

== Step by step or "Tickets, transactions and attachments" ==

Lets look what happens with RT from the beginning when a user clicks on create button in their browser. Web server gets request with queue id, ticket subject and body, owner and etc. RT fetches info from the request that is needed for Ticket record: its Queue id, Status, Subject, [[CurrentUser]](Creator), and then runs the next code:

<nowiki># init empty instance of RT::Ticket class
my $TicketObj = RT::Ticket->new( $session{'CurrentUser'} );

# create new record
# if you more familiar with SQL then it's INSERT
# this call is inherited from SearchBuilder API
my $id = $TicketObj->Create( %ARGS );

</nowiki>

Ticket is created and it's time to record transaction into table. RT has all info for this: ticket's id that was recently created and transaction type - 'Create'.

<nowiki># this call creates new transaction record
# this is very similar to situation with new ticket record
my $TransactionObj = $Ticket->_RecordTransaction( %ARGS );

</nowiki>

Transactions in RT has an many-to-one mapping with ticket. One ticket => one or more transactions. You can get collection of transactions by calling Transactions method on a ticket object:

my $transactions = $TicketObj->Transactions;

Each transaction belongs to only one ticket and you get ticket object with the following code:

my $ticket = $TransactionObj->TicketObj;

As you can see RT still didn't use content that you wrote in the body. Content is an RT::Attachment object. You know how RT creates new record and know about Ticket-Transaction relation, the same relationship applies to Attachments and Transactions.

== From "User Defined" to a module ==

User defined actions you write in the web UI are handy and quick way to write an action. However, at some point you want to re-use your action, make it configurable, edit it in more suitable editor rather than text area, make it more complex and consist of additional methods. So it's time to move from "User Defined" action to your first module file.

use strict;
use warnings;

package RT::Action::MyAction;
use base qw(RT::Action::Generic);

sub Prepare {
my $self = shift;

... here goes preparation code ...

return 1;
}

sub Commit {
my $self = shift;

... here goes commit code ...

return 1;
}

1;

That's it. Save it as [=lib/RT/Action/MyAction.pm], fill in preparation and commit code then you can register your action in the DB. Use the following data file and [[AddDatabaseRecords]] instructions.

@ScripActions = (
{
Name => 'My super duper action',
Description => 'Super-puper action that does hell of a job' ,
ExecModule => 'MyAction',
Argument => 'some argument if needed'
},
);

Now your action in the DB and you can pick it for a scrip through the Web UI instead of picking "User Defined".

== See also ==

Other documentation on this wiki that may help

[[GlobalObjects]], [[ObjectModel]]

== Special thanks ==

* [[TimWilson]], who was the main editor and reviewer

86.6.24.184: /* Errors handling */ - fixed typo

2014-08-02T21:28:32Z

Errors handling: - fixed typo

← Older revision		Revision as of 17:28, 2 August 2014
Line 89:		Line 89:
	my ($status, $msg) = $self->TicketObj->SetPriority( int( $qfp * 0.9 ) );		my ($status, $msg) = $self->TicketObj->SetPriority( int( $qfp * 0.9 ) );
	unless ( $status ) {		unless ( $status ) {
	$RT::Logger->error("~~Coudln~~'t change priority: $msg");		$RT::Logger->error("Couldn't change priority: $msg");
	return 0;		return 0;
	}		}

207.236.194.136: /* How to change ticket custom field values */

2013-04-16T16:04:21Z

How to change ticket custom field values

← Older revision		Revision as of 12:04, 16 April 2013
Line 117:		Line 117:
	== How to change ticket custom field values ==		== How to change ticket custom field values ==

	Step 1, get the custom field (CF) object or ID. Don't use the hardcoded CF ID from the database. Step 2, get the CF object by ticket object by ticket object (I hope you remember how to get a ticket object) and CF name.		Step 1, get the custom field (CF) object or ID. Don't use the hardcoded CF ID from the database. [why?] Step 2, get the CF object by ticket object by ticket object (I hope you remember how to get a ticket object) and CF name.

	<nowiki>...		<nowiki>...
	my $CFName = 'MyCustomField';		my $CFName = 'MyCustomField';
	my $CF = RT::CustomField->new( $RT::SystemUser );		my $CF = RT::CustomField->new( $RT::SystemUser );
	$CF->LoadByNameAndQueue( Name => $CFName, Queue => $Ticket->Queue );		$CF->LoadByNameAndQueue( Name => $CFName, Queue => $Ticket->Queue );
	# RT has bug/feature until 3.0.10, you should load global CF yourself		# RT has bug/feature until 3.0.10, you should load global CF yourself
	unless( $CF->id ) {		unless( $CF->id ) {
	# queue 0 is special case and is a synonym for global queue		# queue 0 is special case and is a synonym for global queue
	$CF->LoadByNameAndQueue( Name => $CFName, Queue => '0' );		$CF->LoadByNameAndQueue( Name => $CFName, Queue => '0' );
	}		}

	unless( $CF->id ) {		unless( $CF->id ) {
	$RT::Logger->error( "No field $CFName in queue ". $Ticket->QueueObj->Name );		$RT::Logger->error( "No field $CFName in queue ". $Ticket->QueueObj->Name );
	return undef;		return undef;
	}		}
	...		...

	</nowiki>		</nowiki>

	Now we could add value to ticket:		Now we could add value to ticket:

24.226.146.16 at 21:01, 26 March 2013

2013-03-26T21:01:24Z

← Older revision		Revision as of 17:01, 26 March 2013
Line 65:		Line 65:

	<nowiki># we don't need any preparation yet.		<nowiki># we don't need any preparation yet.
	return 1;		return 1;

	</nowiki>		</nowiki>

	Commit code:		Commit code:
Line 120:		Line 120:

	<nowiki>...		<nowiki>...
	my $CFName = 'MyCustomField';		my $CFName = 'MyCustomField';
	my $CF = RT::CustomField->new( $RT::SystemUser );		my $CF = RT::CustomField->new( $RT::SystemUser );
	$CF->LoadByNameAndQueue( Name => $CFName, Queue => $Ticket->Queue );		$CF->LoadByNameAndQueue( Name => $CFName, Queue => $Ticket->Queue );
	# RT has bug/feature until 3.0.10, you should load global CF yourself		# RT has bug/feature until 3.0.10, you should load global CF yourself
	unless( $CF->id ) {		unless( $CF->id ) {
	# queue 0 is special case and is a synonym for global queue		# queue 0 is special case and is a synonym for global queue
	$CF->LoadByNameAndQueue( Name => $CFName, Queue => '0' );		$CF->LoadByNameAndQueue( Name => $CFName, Queue => '0' );
	}		}

	unless( $CF->id ) {		unless( $CF->id ) {
	$RT::Logger->error( "No field $CFName in queue ". $Ticket->QueueObj->Name );		$RT::Logger->error( "No field $CFName in queue ". $Ticket->QueueObj->Name );
	return undef;		return undef;
	}		}
	...		...

	</nowiki>		</nowiki>

	Now we could add value to ticket:		Now we could add value to ticket:
Line 155:		Line 155:

	<nowiki># init empty instance of RT::Ticket class		<nowiki># init empty instance of RT::Ticket class
	my $TicketObj = RT::Ticket->new( $session{'CurrentUser'} );		my $TicketObj = RT::Ticket->new( $session{'CurrentUser'} );

	# create new record		# create new record
	# if you more familiar with SQL then it's INSERT		# if you more familiar with SQL then it's INSERT
	# this call is inherited from SearchBuilder API		# this call is inherited from SearchBuilder API
	my $id = $TicketObj->Create( %ARGS );		my $id = $TicketObj->Create( %ARGS );

	</nowiki>		</nowiki>

	Ticket is created and it's time to record transaction into table. RT has all info for this: ticket's id that was recently created and transaction type - 'Create'.		Ticket is created and it's time to record transaction into table. RT has all info for this: ticket's id that was recently created and transaction type - 'Create'.

	<nowiki># this call creates new transaction record		<nowiki># this call creates new transaction record
	# this is very similar to situation with new ticket record		# this is very similar to situation with new ticket record
	my $TransactionObj = $Ticket->_RecordTransaction( %ARGS );		my $TransactionObj = $Ticket->_RecordTransaction( %ARGS );

	</nowiki>		</nowiki>

	Transactions in RT has an many-to-one mapping with ticket. One ticket => one or more transactions. You can get collection of transactions by calling Transactions method on a ticket object:		Transactions in RT has an many-to-one mapping with ticket. One ticket => one or more transactions. You can get collection of transactions by calling Transactions method on a ticket object: