- NAME
- SYNOPSIS
- DESCRIPTION
  - INITIALIZATION
  - LoadConfig
  - Init
  - ConnectToDatabase
  - InitLogging
  - AddFileLogger
  - RemoveFileLogger
  - InitClasses
  - InitSystemObjects
- CLASS METHODS
  - Config
  - DatabaseHandle
  - Logger
  - System
  - SystemUser
  - Nobody
  - CurrentInterface
  - SetCurrentInterface API|CLI|Email|REST|REST2|Web
  - ResetCurrentInterface
  - Plugins
  - PluginDirs
  - InitPluginPaths
  - InitPlugins
  - AddJavaScript
  - AddStyleSheets
  - JavaScript
  - StyleSheets
  - Deprecated
- BUGS
- SEE ALSO

# 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.

## LoadConfig

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, initializes 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.

## AddFileLogger

        RT->AddFileLogger(
            filename  => 'filename.log', # will be created in C<$LogDir>
            log_level => 'warn',         # Log::Dispatch log level
        );

Add a new file logger at runtime. Used to add short lived file loggers that are currently only used for logging Scrip errors.

Note that the log file will be opened in write mode and will overwrite an existing file with the same name.

To remove the file logger use `RemoveFileLogger`.

## RemoveFileLogger

        RT->RemoveFileLogger(
            'filename.log',
            'an optional final log message',
        );

Remove a file logger that was added at runtime. Used to remove file loggers added with `AddFileLogger`.

Accepts an optional second argument to add a final log message that is only appended to the log file if the log file is not empty.

If the log file is empty it is deleted to avoid empty log files in the log directory.

## 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.

See also "ConnectToDatabase".

## 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 validity, 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.

# SEE ALSO

RT::StyleGuide DBIx::SearchBuilder

← Back to index