RT 5.0.3 Documentation

RT

NAME

RT - Request Tracker

SYNOPSIS

A fully featured request tracker package.

This documentation describes the point-of-entry for RT's Perl API. To learn more about what RT is and what it can do for you, visit https://bestpractical.com/rt.

DESCRIPTION

INITIALIZATION

If you're using RT's Perl libraries, you need to initialize RT before using any of the modules.

You have the option of handling the timing of config loading and the actual init sequence yourself with:

    use RT;
    BEGIN {
        RT->LoadConfig;
        RT->Init;
    }

or you can let RT do it all:

    use RT -init;

This second method is particular useful when writing one-liners to interact with RT:

    perl -MRT=-init -e '...'

The first method is necessary if you need to delay or conditionalize initialization or if you want to fiddle with RT->Config between loading the config files and initializing the RT environment.

Load RT's config file. First, the site configuration file (RT_SiteConfig.pm) is loaded, in order to establish overall site settings like hostname and name of RT instance. Then, the core configuration file (RT_Config.pm) is loaded to set fallback values for all settings; it bases some values on settings from the site configuration file.

In order for the core configuration to not override the site's settings, the function Set is used; it only sets values if they have not been set already.

Init

Connects to the database, initilizes system objects, preloads classes, sets up logging, and loads plugins.

ConnectToDatabase

Get a database connection. See also "DatabaseHandle".

InitLogging

Create the Logger object and set up signal handlers.

InitClasses

Load all modules that define base classes.

InitSystemObjects

Initializes system objects: $RT::System, RT->SystemUser and RT->Nobody.

CLASS METHODS

Config

Returns the current config object, but note that you must load config first otherwise this method returns undef.

Method can be called as class method.

DatabaseHandle

Returns the current database handle object.

Logger

Returns the logger. See also "InitLogging".

System

Returns the current system object. See also "InitSystemObjects".

SystemUser

Returns the system user's object, it's object of RT::CurrentUser class that represents the system. See also "InitSystemObjects".

Nobody

Returns object of Nobody. It's object of RT::CurrentUser class that represents a user who can own ticket and nothing else. See also "InitSystemObjects".

CurrentInterface

Returns the interface used to make the current request. Possible values are the following:

Web: Requests handled by RT::Interface::Web, which are all typical web-based requests over http (usually from a browser) that are not REST-type.
Email: Requests handled by RT::Interface::Email, which are incoming emails.
CLI: Requests handled by RT::Interface::CLI, which is most, but not all command-line scripts.
REST: Requests to the RT REST version 1 API.
REST2: Requests to the RT REST version 2 API.
API: Requests that appear to be directly to RT code. This is the default and stays set if not updated by one of the interfaces above.

SetCurrentInterface API|CLI|Email|REST|REST2|Web

Sets current interface and returns it.

ResetCurrentInterface

Resets current interface(i.e. it will default to API)

Plugins

Returns a listref of all Plugins currently configured for this RT instance. You can define plugins by adding them to the @Plugins list in your RT_SiteConfig

PluginDirs

Takes an optional subdir (e.g. po, lib, etc.) and returns a list of directories from plugins where that subdirectory exists.

This code does not check plugin names, plugin validitity, or load plugins (see "InitPlugins") in any way, and requires that RT's configuration have been already loaded.

InitPluginPaths

Push plugins' lib paths into @INC right after local/lib. In case local/lib isn't in @INC, append them to @INC

InitPlugins

Initialize all Plugins found in the RT configuration file, setting up their lib and HTML::Mason component roots.

AddJavaScript

Helper method to add JS files to the @JSFiles config at runtime.

To add files, you can add the following line to your extension's main .pm file:

    RT->AddJavaScript( 'foo.js', 'bar.js' );

Files are expected to be in a static root in a js/ directory, such as static/js/ in your extension or local/static/js/ for local overlays.

AddStyleSheets

Helper method to add CSS files to the @CSSFiles config at runtime.

To add files, you can add the following line to your extension's main .pm file:

    RT->AddStyleSheets( 'foo.css', 'bar.css' );

Files are expected to be in a static root in a css/ directory, such as static/css/ in your extension or local/static/css/ for local overlays.

JavaScript

helper method of RT->Config->Get('JSFiles')

StyleSheets

helper method of RT->Config->Get('CSSFiles')

Deprecated

Notes that a particular call path is deprecated, and will be removed in a particular release. Puts a warning in the logs indicating such, along with a stack trace.

Optional arguments include:

Remove: The release which is slated to remove the method or component
Instead: A suggestion of what to use in place of the deprecated API
Arguments: Used if not the entire method is being removed, merely a manner of calling it; names the arguments which are deprecated.
Message: Overrides the auto-built phrasing of Calling function ____ is deprecated with a custom message.
Detail: Provides more context (e.g. callback paths) after the Message but before the Stack
Object: An RT::Record object to print the class and numeric id of. Useful if the admin will need to hunt down a particular object to fix the deprecation warning.

BUGS

Please report them to rt-bugs@bestpractical.com, if you know what's broken and have at least some idea of what needs to be fixed.

If you're not sure what's going on, start a discussion in the RT Developers category on the community forum at https://forum.bestpractical.com or send email to sales@bestpractical.com for professional assistance.