This section takes a tour of RT's logical model, shown in Figure 8-2. RT maps its logical model closely to its object model, so we've condensed the details of the object and logical models throughout the section. Figure 8-2. The RT Logical Model Every RT object has a field called ID. This field is an integer that's automatically set to a unique value when an object is created and never changes. RT uses these values internally as keys to objects. Additionally, many of RT's objects have fields called Creator, Created, LastUpdated, and LastUpdatedBy. These fields automatically track the users who created and most recently updated these objects and the times of those actions. For clarity, we've skipped over those fields in the schema listings below. Each of the database tables we discuss here corresponds to two RT objects, a record class and a collection class. The methods for each of these classes are split up into several files; see "Overlays" in Chapter 10 for more details. Method-level documentation for each class is available in Perl's perldoc format. Each collection class is named the same as RT's database table for that sort of object. Each record class is named for the singular version of the collection. So if you're interested in users, for example, you want to look at both RT::Users and RT::User. By default, the primary file for each of these classes lives in /opt/rt3/lib/RT/. The documentation in both the record and the collection modules gives an overview of the database schema for the class and provides pointers to other files that contain class methods and documentation: perldoc /opt/rt3/lib/RT/User.pm and perldoc /opt/rt3/lib/RT/Users.pm Each of these files will give you an overview of the database schema for the class, as well as provide pointers to other files that contain class methods and documentation. 8.4.1. Users In RT, a user is any individual who can perform actions within the system. Any time you create, modify, look at, or delete an object, you need to do it as a user. Out of the box, RT comes with three special users:
RT_System RT uses the RT_System user to perform actions as the system itself. This includes looking up data for internal use when you really don't want access control checks to deny the system access to its own data as well as automatically reopening a closed ticket when a user sends in email about that ticket. Inside RT, you always can access RT_System as $RT::SystemUser.
Nobody RT uses the Nobody user primarily to mark tickets that have no owner. For consistency, it's important that tickets always be owned by somebody, even if that somebody is a dummy user. Inside RT, you can access Nobody as $RT::Nobody.
root Out of the box, RT comes standard with a single user account called root whose password is password. On Unix systems, root is the superuser. Long, long ago, RT used unix system accounts instead of its own account system. The Unix-y name of this account is a holdover from those days. Once you've got an RT system up and running, nothing internal depends on the name root. There isn't a global object in RT for the root user. Users have the following fields:
Name Every user in RT has a Name, which is guaranteed to be unique. While RT doesn't reference users directly by Name, users authenticate to RT and search for other users by Name.
EmailAddress A user's EmailAddress is used by RT to attach incoming email messages to a user account upon receipt. It's also used by RT to figure out where to send outgoing mail when tickets are updated. No two users may have the same email address, although it's fine to have many users with no email address.
Password While RT supports external access control mechanisms, many sites don't have a universal authentication framework, so RT provides its own password-based system. Internally, RT stores an MD5 hash of a user's password in the Password field but never exposes it directly to end-users. Unlike most other fields, Password is write-only. RT provides SetPassword and IsPassword methods but not a Password method. RT treats passwords such as *NO-PASSWORD and *LOCK* as locked passwords and never allows password-based access to accounts with such passwords.
Comments RT is often used in a customer-service scenario, where it's important to be able to keep notes about users. The Comments field is a scratch-pad about a user, but it isn't visible to that user unless they're part of the Privileged group.
Signature When composing mail from within the web interface, RT automatically will append a user's Signature to the message.
RealName In a number of situations, RT will display a user's RealName, rather than their Name or EmailAddress.
Lang RT's web interface provides browser-based language negotiation features, but it's sometimes useful to override that with a user's preferred language. The Lang field stores an RFC3066-style language tag.
Gecos RT provides functionality to allow command-line tools written around the RT framework to map the current Unix username to an RT user's Gecos field.
NickName, Organization, HomePhone, WorkPhone, MobilePhone, PagerPhone, Address1, Address2, City, State, Zip, Country, FreeformContactInfo RT provides these fields to allow sites to use it as a contact management system. They're not used internally.
EmailEncoding, WebEncoding, ExternalContactInfoId, ContactInfoSystem, ExternalAuthId, AuthSystem, Timezone, PGPKey RT doesn't currently use these fields. 8.4.2. Groups A collection of users and other groups can be assigned rights, made watchers of tickets, and so on. Groups can contain users and groups. Groups can't contain themselves. Groups have the following fields:
Name Every group in RT has a name, purely for human convenience. Internally, RT doesn't care about group names.
Description Likewise, the Description is provided so that users know what a particular group is for.
Domain Many parts of RT use the groups system for a wide variety of different purposes. Domain is a high level way to mark what type each group is.
ACLEquivalence Internally, RT's access control system only grants rights to groups. When first created, every user has an ACL equivalence group created with only that user as a member. Whenever RT's API is used to grant rights to an individual user, the right is really granted to that user's ACL equivalence group.
SystemInternal RT keeps track of certain user attributes with system-wide meta-groups. Upon installation, RT creates three of these SystemInternal metagroups: Everyone, Privileged, and Unprivileged. Every single user is added as a member of the Everyone group and either the Privileged or Unprivileged group. If a user is Unprivileged, they can't be granted rights directly, and RT's web frontend automatically shunts them to a restricted self-service frontend upon login.
UserDefined UserDefined groups are system-wide groups created by local staff. Generally, they're used as a system managment convenience. Rights are granted to groups, rather than individual users, and groups are made Ccs or AdminCcs of Tickets or Queues. This makes it easier for administrators to track who can perform actions or who will receive email on a specific topic.
Personal Personal groups are defined by individual users for their own personal use. Currently, they're used only by the Delegation system to allow users to delegate rights to other users or groups.
RT::System-Role, RT::Queue-Role and RT::Ticket-Role Role groups are designed to allow administrators to grant rights to a role and configure mailing rules for a role at either the System or Queue level and have that configuration apply to every user who is operating in that role for a given ticket or queue. As of RT 3.0, the possible roles are Requestor, Cc, AdminCc, and Owner.
Type For ACLEquivalence groups, the group's type is 'UserEquiv'. For SystemInternal groups, the group's type is one of 'Everyone', 'Privileged', or 'Unprivileged'. For each of the role groups, the type is one of Owner, Requestor, Cc, or AdminCc. For Personal groups, the type is always "" (an empty string).
Instance For ACLEquivalence and Personal groups, the group's instance is the user's ID. For SystemInternal and UserDefined groups, the group's instance is always 0. For RT::Ticket-Role groups, the group's instance is the Ticket's ID. For RT::Queue-Role groups, the group's instance is the Queue's ID. For RT::System-Role groups, the group's instance is always 1.
8.4.3. Principals In RT, each user or group is a type of Principal. Principals are an abstraction that RT uses internally so that rights can be granted to both users and groups and so that both users and groups can be members of a group. Principals have the following fields:
PrincipalType A principal's type is always one of User or Group. It tells RT which sort of object this Principal is. Because a Principal's ID is always the same as the ID of the associated user or group object, it would be possible (but slow) to deduce this information on the fly.
Disabled Sometimes a user or group is no longer needed. If you simply deleted it from the database, you'd lose information about what that user or group did in the past. RT provides the Disabled field, which lets you specify that a Principal and its associated user or group is no longer in play.
ObjectId A principal's ObjectId is always the same as its ID. At one point, a User's ID wasn't the same as the ID of the Principal object. You should never be looking at or using a Principal's ObjectId. 8.4.4. GroupMembers The GroupMembers table keeps track of all the users and groups that are members of a group. Generally, developers will interact with the GroupMembers table through the API provided by group objects.
GroupId GroupId refers to the group where the member belongs. It points to the ID of a group object.
MemberId MemberId is the ID of a Principal that is a member of the group referenced by the GroupId. 8.4.5. CachedGroupMembers RT allows both users and groups to be members of groups. Because SQL databases don't generally provide a means to ask a database for all rows that refer to this row recursively, we have to build up a more complex mapping table. Generally, everything you ever want to do with CachedGroupMembers is encapsulated in the interface to group objects. RT's CachedGroupMembers algorithm is quite complex and isn't designed to be modified by user code. Details of its schema are provided here for completeness. CachedGroupMembers have the following fields:
MemberId As in the GroupMembers table, MemberId is a reference to the ID of a Principal that is a member of the group referenced by the GroupId.
Via In cases where a user or group is a member of a (parent) group, Via will point to the ID of the row in the CachedGroupMembers table for the parent group. When the group in question is the top-level group, Via points to this row's ID.[*] [*] To make the access control system work, it's important that a group be listed as a member of itself.
ImmediateParentId ImmediateParentId is the ID of the Group that this row's MemberId is explicitly a member of. It corresponds directly to the GroupId in the GroupMembers table.
Disabled If this cached group member is a member of this group by way of a disabled group or if this group is disabled, this will be set to 1. This prevents us from finding members of disabled subgroups when listing off group members recursively. Also, it allows the access control system to elide members of disabled groups. 8.4.6. ACL A single row in an access control list is an Access Control Entry or ACE. The Access Control List (ACL) table details which rights each Principal has for any ACLed object in RT. ACLed objects include: tickets, queues, and groups. ACLs have the following fields:
PrincipalType PrincipalType captures which sort of object a given ACE applies to. For each of the roles Owner, Requestor, Cc, and AdminCc the PrincipalType is the name of that role. For regular groups, the PrincipalType is simply Group. For an ACE granting rights to a user, the PrincipalType is Group. Behind the scenes, rights are never granted directly to users, but to their ACL equivalence groups.
PrincipalId PrincipalId is a pointer to the principal to which this ACE applies. In the case of regular groups and role groups, it points to the group in question's Principal. If the ACE grants rights to a specific user, the PrincipalId points to that user's ACL equivalence group.
RightName The RightName is a simple textual identifier for the right being granted. For any object that supports access control, you can get a complete list of what rights it supports with the AvailableRights( ) method.
ObjectType Each ACE applies to a specific object. ObjectType is the class of that object. For example, if you granted a right on Queue 1, the class would be RT::Queue.
ObjectId ObjectId is the ID of the object to which this ACE refers. For example, if you granted a right on Queue 1, the ObjectId would be 1.
DelegatedFrom RT's ACL delegation system allows individual users to delegate rights that had been granted to them and automatically removes the delegated rights when the grantor's rights are revoked. DelegatedFrom is a pointer to the ID of the ACE on which this right is based.
DelegatedBy DelegatedBy is the Principal ID of the user who delegated this right. 8.4.7. Links The Links table keeps track of relationships between entities. The object classes wrapping Links have built-in intelligence to do clever things with RT tickets, but you can think of the Links system as a simple store for RDF-style Subject-Predicate-Object triples (Base-Type-Target in RT's lexicon).[*] [*] For more information about RDF, see Practical RDF (O'Reilly). Links have the following fields:
Base Base is the URI of the left-hand side of this link relation. It can contain any URI. By default, RT ships with classes that can handle http:, https:, file:, ftp: and fsck.com-rt: URIs.
LocalBase If this Link's base is a local ticket, LocalBase is a pointer to the ID of that ticket. This field is a convenience that makes it easier for RT to find links related to a particular ticket.
Type Type describes what sort of relationship the Base has to the Target. Out of the box, RT supports three simple types of relationships:
RefersTo The Base refers to the Target. This is a simple weak reference that lets you tie related objects together. For example, "The purchase of new servers refers to the estimates we got from these six vendors."
DependsOn The Base in some way depends on the Target. In the ticketing system side of RT, we use DependsOn to track cases when one Ticket must be completed before another one can be completed such as "The purchase of new servers depends on budget approval for the server migration project."
MemberOf The Target contains the Base. In the ticketing system side of RT, we use MemberOf to track parent-child relationships such as "The purchase of new servers is a member of the server migration project."
Target Target is the URI of the right-hand side of this link relation. It can contain any URI.
LocalTarget If this Link's target is a local ticket, LocalTarget is a pointer to the ID of that ticket. This field is a convenience that makes it easier for RT to find links related to a particular ticket. 8.4.8. Attributes RT's Attributes table, new in 3.2, allows you to store arbitrary metadata about any RT object. It's quite useful for extending objects in ways that we haven't envisioned. Bear in mind, though, that attributes aren't searchable. You can't for example, ask RT to find you all the Users who have an attribute called "LikesUnix."
ObjectType ObjectType refers to what sort of RT object to which this attribute is attached. If you want to store an attribute for the user whose ID is 4, the attribute's ObjectType would be RT::User.
ObjectId ObjectId is the ID of the object for which this attribute is being stored. If you want to store an attribute for the user whose ID is 4, the attribute's ObjectId would be 4.
Name An attribute's Name is the machine-readable name for this attribute. RT uses attributes to store persistent searches. All saved searches have the name SavedSearch.
Description An attribute's Description is the human readable explanation of the purpose of this particular attribute. For saved searches, this would be the user's hand-entered description for what's being searched.
Content Content contains the actual value of this attribute. It can store at least 4,000 characters of text or binary data. Complex data structures are stored in the Perl "storable" format. 8.4.9. Transactions Transactions record everything that happens to a ticket, from its creation through its eventual resolution. Each transaction can have one or more Attachments. Unlike most objects in RT, transactions are immutable once created. Transactions have the following fields:
ObjectType ObjectType describes the class of record to which this transaction refers. Most often, you'll see RT::Ticket here. (In previous versions, RT only tracked transactions on tickets). As of RT 3.4, RT also records changes to RT::User and RT::Group objects.
ObjectId ObjectId is a pointer to the ID of the record to which this transaction refers.
Type A transaction's Type describes what sort of update it is. For most simple updates to individual ticket fields, the type is Set. For adding a comment to a ticket, it's Comment. For updates to Custom Fields, it's CustomField.
TimeTaken For some types of transactions, like Comment and Correspond, users can specify how long they spent on the update. TimeTaken tracks that value in minutes.
Field For updates that alter a field or custom field, Field tracks what was changed.
OldValue OldValue tracks what a field was changed from. In the case of deletion, OldValue is the value that was deleted.
NewValue NewValue tracks what a field was changed to. In the case of a new value being added, NewValue tracks the new value.
Data Some transactions have a bit more data than can be encapsulated easily in the previous fields. Data stores the subjects of incoming correspondence and occasionally other data.
ReferenceType Some transactions store changes to custom fields for things like images, files, or large text blocks. When RT records one of those updates as a transaction, it sets ReferenceType to RT::ObjectCustomFieldValue and fills in OldReference and/or NewReference. Because storing two copies of these big objects can bloat the database, RT stores changes to large values like this by reference instead of just copying the values like it does for smaller fields.
NewReference NewReference contains a pointer to an added value of the type stored in ReferenceType.
OldReference OldReference contains a pointer to a deleted value of the type stored in ReferenceType. 8.4.10. Attachments The Attachment table stores any message body or attachment for a transaction in a structured manner, so MIME email messages can be rebuilt. Attachments are arbitrarily complex MIME entities that can be tied to tickets using transactions. Every email message that RT associates with a ticket will be stored in the database as one or more attachments. If an attachment is made up of multiple MIME parts, RT will split those parts into a tree of related attachments and store each one in the database. Attachments have the following fields:
TransactionId Each Attachment is associated with a Transaction. TransactionId is a reference to the ID of the Transaction associated with this attachment.
Parent If this attachment is part of a complex MIME structure, Parent points to another Attachment representing the parent MIME section.
MessageId If an attachment is an email message, MessageId stores its Message-Id: header. In the future, this will make it easier to build message threads.
Subject If an attachment is an email message, Subject stores its Subject: header.
Filename If an attachment is a named file, Filename stores what it was called when it was submitted to RT.
ContentType ContentType stores this attachment's MIME type.
ContentEncoding When possible, RT undoes all of the encoding that attachments are wrapped in for transport by email, so it can store them in their raw forms in the database. Some databases, like PostgreSQL and Oracle don't support binary data in the same sorts of fields that they use to store character data, like the bodies of email messages. On these databases, RT transparently encodes stored attachments into Base64 or QuotedPrintable encoding when stuffing them into the database and transparently undoes it when pulling them back out. Data about what sort of encoding is used is stored in the ContentEncoding header.
Content Content is the actual body of the attachment, stored as UTF-8 text, binary data, or encoded data.
Headers RT stores the attachment's message headers and MIME headers in the Headers field. RT also stores additional data, including the attachment's length and original text encoding, if it was converted into UTF-8 by RT. 8.4.11. CustomFields RT allows sites to track custom metadata per ticket using a facility known as Custom Fields. These custom fields can be applied to tickets globally or per-queue. Custom fields can be of several types: Select from a list, free-form data entry in a text field, free-form data entry in a textarea field (with either plain or wiki text), file upload, and image upload. Additionally, each custom field can accept either a single value or multiple values. For all intents and purposes, users interacting with RT can treat custom fields the same as regular fields like Status and Subject. Users can see, edit, and search on custom field values through the same interfaces that they use to work with RT. At the API level, however, they're treated somewhat differently. CustomFields have the following fields:
Name Each custom field has a name displayed to users editing or viewing it. Names aren't guaranteed to be unique.
Description Description is a human-readable summary of a custom field.
Type A custom field's Type describes what sort of values it accepts. As of RT 3.4, acceptable values are: Select, Freeform, Text, Image, and Binary. Select fields let the user pick values from a list. Freeform fields let the user enter individual lines of text. Text fields let the user enter large (up to a couple megabytes) blocks of text. Image fields let the user upload images as custom field values. Binary fields let the user attach files as values.
MaxValues MaxValues tells RT how many values this custom field can have for a given object. Out of the box, RT 3.4 lets users pick 0, which allows unlimited possible values, or 1, which limits users to a single selection.
SortOrder SortOrder is an integer field used by RT to automatically list custom fields in the order you want to present them. RT lists custom fields in ascending order sorted by SortOrder.
Disabled Disabled is a boolean field that specifies whether RT should let users see and modify a custom field and its values. It's important not to lose historical data about custom fields and their values, so disable custom fields instead of deleting them.
LookupType RT uses LookupType to describe what sorts of objects to which a custom field applies. RT::Queue-RT::Ticket means that the custom field applies to tickets in a given queue. RT::Queue-RT::Ticket-RT::Transaction means that the custom field applies to transactions on tickets in a given queue. RT::Group tells RT that this custom field should apply to groups. Similarly, RT::User makes sure the custom field only shows up on user objects.
Pattern RT 3.4 doesn't do anything with a custom field's Pattern attribute, but future releases or plugins will add the ability to validate users' input against a regular expression stored there.
Repeated The Repeated attribute is reserved for future use. 8.4.12. CustomFieldValues The CustomFieldValues table holds the list of acceptable values for Select custom fields. CustomFieldValues have the following fields:
CustomField CustomField is a pointer to the ID of the custom field for which this row holds a valid value.
Name Name is the actual value of the custom field to be listed.
Description Description is a longer explanation of the meaning of this value's Name. It's displayed in the administrative interface and some user-visible contexts.
SortOrder SortOrder is an integer field used by RT to automatically list custom field values in the order you want to present them. Values fields are listed in ascending order. 8.4.13. ObjectCustomFields ObjectCustomFields is a simple linking table that RT uses to decide which custom fields apply to a given object.
CustomField CustomField is a reference to the ID of a record in the CustomFields table.
ObjectId Using the custom field's LookupType, RT can figure out the type of objects to which the custom field can apply. ObjectId tells RT the exact object of that type to which a custom field applies. A value of 0 means that this custom field applies to all objects of that type. 8.4.14. ObjectCustomFieldValues ObjectCustomFieldValues holds all current custom field values for all tickets within RT. Values are stored by value, rather than by reference. This enables users to switch custom field types from Select to Freeform and back again without loss of data.
CustomField CustomField is a pointer to the ID of the custom field associated with this value.
ObjectType ObjectType describes what sort of record to which this transaction refers. Its values are RT::Record subtypes. In RT, most transactions are on tickets, so the most common value you'll see is RT::Ticket, but others such as RT::Group and RT::User are also valid.
ObjectId ObjectId is a pointer to the ID of the record (usually a ticket) to which this value applies. In previous versions of RT, this column was called Ticket.
Content Content is the actual textual value of the custom field for the ticket. The content is stored as a 255 character text field.
LargeContent LargeContent stores larger text values for custom fields, as well as image or binary custom field values. As of RT 3.4, it's used by the Image, Text, and Binary custom field types.
ContentType ContentType stores the MIME type of any LargeContent. If there is no LargeContent for this record, it's blank. When searching custom field content, RT is careful to search only values that have a ContentType that begins with text.
ContentEncoding Because some databases handle binary data differently, ContentEncoding tells RT whether it needs to do anything special to decode and present the LargeContent. 8.4.15. Tickets RT is a ticketing sytem. It should come as no suprise that one of the core objects is the Ticket. Every ticket has a number of things associated with it, including role groups for Owner, Requestors, Cc, and AdminCc. Owner is quite special in that it can contain only one user, but the others can contain multiple users and groups. By default, RT is configured to treat each of the groups specially, but internally they are quite similar. Additionally, a ticket can have a number of attached Transactions, CustomFields, and Links. Tickets have the following fields:
EffectiveId By default, a ticket's EffectiveId is the same as its ID. RT supports the ability to merge tickets together. When you merge a ticket into another one, RT sets the first ticket's EffectiveId to the second ticket's ID. RT uses this data to quickly look up which ticket you're really talking about when you reference a merged ticket.
Queue Tickets are grouped into queues. Each ticket can have one and only one queue. Queue is a pointer to the ID of the queue for this ticket.
Type Type is a simple textual identifer that describes what sort of ticket this is. By default, all tickets are of Type ticket. Generally, there's no reason to change that.
Owner Owner is a pointer to the ID of the Principal who owns this ticket. This information is also stored in the ticket's Owner role group, but it is cached in the Ticket record for performance reasons.
Subject Subject is a simple human-readable description of what this ticket is about.
Priority, InitialPriority, and FinalPriority When a ticket is first created, its Priority is copied into its InitialPriority. An external tool can move a ticket's Priority up (or down) toward its FinalPriority.
TimeEstimated, TimeWorked, and TimeLeft RT allows users to track how much time, in minutes, a given ticket is estimated to take. Over time, users can add to the TimeWorked and (hopefully) subtract from the TimeLeft.
Status Each ticket has a single current Status, which can be one of new, open, stalled, resolved, rejected, or deleted. Deleted tickets are treated specially in that they can't be displayed in ticket listings.
Told Told tracks the last time a ticket update was sent to the requestor.
Starts Starts is primarily intended for users' project management needs. RT doesn't handle it specially.
Started Started tracks the last time the ticket's status was flipped from new to another status.
Due Due tracks the ticket's due date.
Resolved The name Resolved is a bit misleading. This field tracks the last time that this ticket's status was set to resolved, rejected, or deleted.
IssueStatement and Resolution These fields are not currently used by RT. 8.4.16. Queues The Queue is RT's basic administrative unit. Every ticket is categorized into a Queue. Access control, business logic, notifications, and custom fields can all be configured at the queue level. Queues have the following fields:
Name Each queue has a unique Name. This name is displayed to users and used by tools such as RT's mail gateway to determine in which queue a new ticket should be created.
Description Description is a human-readable explanation of a queue's purpose that is displayed to administrative staff and sometimes included in outgoing email messages about tickets in this queue.
CorrespondAddress When RT sends out public email correspondence about a ticket, it automatically sets the message's From: and Reply-To: headers to the queue's CorrespondAddress. It's up to local staff to make sure that both this and the queue's CommentAddress are set to values that will be properly routed back into RT.
CommentAddress When RT sends out private email comments about a ticket, it automatically sets the message's From: and Reply-To: headers to the queue's CommentAddress.
InitialPriority InitialPriority specifies a default priority for a newly created ticket in this queue.
FinalPriority FinalPriority specifies a default ending priority for a newly created ticket in this queue. RT ships with a small tool that you can insert into cron to automatically move tickets toward their FinalPriority as they approach their due dates.
DefaultDueIn DefaultDueIn, if set, will set the due dates of newly created tickets in this queue to DefaultDueIn days in the future.
Disabled Sometimes, you don't want a queue to appear in listings anymore. Deleting the queue outright would lose data about every ticket that had ever been in that queue. Instead, RT provides the Disabled flag, which simply masks the queues you don't want to see anymore. 8.4.17. Scrips Scrips are one of RT's key bits of extensibility. Scrips are bits of custom logic that users can install into RT without changing any system code. Scrips are composed of a Condition and an Action. If the Condition returns success, then RT will prepare the Action. If the action is prepared cleanly, it is Committed and all relevant email is sent out and data written to the database. Scrips have the following fields:
Description The Description is a simple human-readable explanation for this Scrip.
ScripCondition ScripCondition is a pointer to the ID of a ScripCondition object.
ScripAction ScripAction is a pointer to the ID of a ScripAction object.
CustomIsApplicableCode CustomIsApplicableCode is a field used primarily by user-defined conditions. Its content is used as the source code for an anonymous subroutine, which can return true or false. If it returns true, the Scrip's Action is prepared. Otherwise, processing of this scrip ceases.
CustomPrepareCode CustomPrepareCode is a field used primarily by user-defined actions. Its content is used as the source code for an anonymous subroutine, which can return true or false. If it returns true, the CustomCommitCode is evaluated. Otherwise, processing of this scrip ceases.
CustomCommitCode CustomCommitCode is a field used primarily by user-defined actions. Its content is used as the source code for an anonymous subroutine, which should perform whatever action the ScripAction needs to perform and return true on success or false on failure.
Stage Stages are the places in RT that call out to fire user-specified scrips. Valid values include:
TransactionCreate TransactionCreate is the standard scrip call-point from RT 2.0. Immediately after a transaction has been posted to the database, RT executes the scrip.
TransactionBatch RT collects updates to a ticket into a single batch and executes all TransactionBatch scrips once the current RT::Ticket object has been marked for destruction.
Queue Queue is the ID of the queue to which this scrip applies. If it's set to 0, this scrip applies to all queues.
Template Template is a reference to the name of the template this scrip should use. If the template is a global template and there's a queue-specific template with the same name in this scrip's queue, RT will use the queue template.
ConditionRules and ActionRules These fields are not currently used by RT.
8.4.18. Templates Templates are simple text templates which Scrips use to build outgoing email messages. Their content is parsed with the Text::Template module. Templates have the following fields:
Queue Queue is a pointer to the ID of the queue with which this template is associated. If this template is a global template that should be available to scrips in all queues, Queue is 0.
Name Name is a simple human-readable name for this template. Unlike most Names, it is sometimes used by RT to find templates.
Description Description is a simple human-readable description for this template.
Content Generally, a template's Content is an email message template that a Scrip interprets and sends off. RT uses a simple heuristic to determine whether a template's content contains email message headers; if the content's first line contains a colon (:), it's assumed to be a message header. RT treats each line as a header until it finds a blank line.
Type, Language, and TranslationOf These fields are not used by RT. 8.4.19. ScripActions ScripActions are references to chunks of code on disk, which are used by Scrips to perform some action. Examples include: Autoreply to Requestor, Notify Owner, and Page Systems Administrators. ScripActions have the following fields:
Name Name is a simple human-readable name for this ScripAction. It's not used internally by RT.
Description Description is a longer human-readable description for this ScripAction. It's not used internally by RT.
ExecModule ExecModule is the name of the Perl module in lib/RT/Action/ that should be called by this ScripAction. That Perl module must be a subclass of RT::Action::Generic.
Argument Argument contains an optional argument to be passed to the Action module during evaluation. RT's Notify ScripAction uses this argument to define which roles should receive mail from a particular scrip. 8.4.20. ScripConditions ScripConditions are references to chunks of code on disk, which scrips use to perform some check or validation. Examples include: On Create, On Correspond, or If the smoke alarm is going off. ScripConditions have the following fields:
Name Name is a simple human-readable name for this ScripAction. It's not used internally by RT.
Description Description is a longer human-readable description for this ScripAction. It's not used internally by RT.
ExecModule ExecModule is the name of the Perl module in lib/RT/Action/ that should be called by this ScripAction. That Perl module must be a subclass of RT::Condition::Generic.
Argument Argument contains an optional argument to be passed to the Action module during evaluation. RT's "Notify" ScripAction uses this argument to define which roles should be receiving mail from a particular scrip.
ApplicableTransTypes ApplicableTransTypes specifies a comma-delimited list of transaction types to which this ScripCondition applies. "Any" means that the ScripAction will run on any transaction. This serves as a first line of defense to cut down on the amount of processing that RT needs to do on any ticket update. |