9.2. RT Codebase

RT's object-oriented code is arranged in several distinct groups of modules. Each group generally depends on a specific core or essential module that provides methods other modules can inherit or overload as appropriate: RT::Base, RT::Record, and RT::SearchBuilder.

RT::Base is a relatively minor but central utility module, which sets the current user for ACL decisions and the like. The following classes inherit this functionality:

     RT::Date     RT::Record     RT::SearchBuilder     RT::System     RT::URI 

RT::Record inherits from DBIx::SearchBuilder::Record and is responsible for handling a single object corresponding to a single record in the database. The following classes inherit from RT::Record:

     RT::ACE     RT::Attachment     RT::Attribute     RT::CurrentUser     RT::CustomField     RT::Group     RT::GroupMember     RT::Link     RT::Principal     RT::Queue     RT::Scrip     RT::ScripAction     RT::ScripCondition     RT::Template     RT::Ticket     RT::Transaction     RT::User 

RT::SearchBuilder also inherits from DBIx::SearchBuilder. It provides methods and functionality for collections of objects. The following collection objects inherit from RT::SearchBuilder:

     RT::ACL     RT::Attachments     RT::Attributes     RT::CustomFields     RT::GroupMemebers     RT::Groups     RT::Links     RT::Principals     RT::Queues     RT::ScripActions     RT::ScripConditions     RT::Scrips     RT::Templates     RT::Tickets     RT::Transactions     RT::Users 

You saw earlier that DBIx::SearchBuilder records and collections always take a database handle as a parameter to their _Init methods. The RT::Record and RT::SearchBuilder objects take care of this for you. But there's an added wrinkle. Within RT, every object needs to know which user is working with it so that it can make the right access control decisions and keep good records of who does what. With few exceptions, every RT object's new method takes only a single paremeter, an RT::CurrentUser object. (For bootstrapping reasons RT::CurrentUser can take a username or id number instead of an RT::CurrentUser object.) RT doesn't pass this information back to DBIx::SearchBuilder but uses it internally to make access control decisions.

RT implements ACLs (Access Control Lists) as the control mechanism for authorization for ticket and object creation. If you set the ACLs to permit the Everyone group to create tickets, RT automatically creates accounts for every user who ever submits a ticket. You can read more about ACLs and how RT uses them in Chapters 2 and 5.

Other modules are worth browsing to discover the functionality provided by the standard RT distribution. Action::Generic, Condition::Generic, Search::Generic, and URI::base are just a few ideas for further research and exploration. RT has a rich code base. Explore further to find your own ideas and solutions for your own particular application requirements.

9.2.1. Exceptions

Errors are handled by cancelling (or rolling back) the current transaction at the database level and sending the error to the current interface whether that's the command-line interface, email, or the web frontend and to syslog. The /etc/syslog.conf configuration file can specify different responses to generate for the various RT errors and logging messages.

To get at the SQL, look at the relevant database logs. Alternatively you might try setting the DBI_TRACE variable to something suitably high to dump the SQL to STDERR.