|< Day Day Up >|
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.
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.
|< Day Day Up >|