It's often useful to be able to test configuration/database changes and then apply the same changes in production without manually clicking around. It's also helpful if you're developing customizations or extensions to be able to get a fresh database back to the state you want for testing/development.
This documentation applies to careful and thorough sysadmins as well as extension authors who need to make database changes easily and repeatably for new installs or upgrades.
RT ships with many initialdata files, only one of which is used to configure a fresh install; the rest are used for upgrades, but function the same despite being named differently.
etc/initialdata
etc/upgrade/*/content
The upgrade "content" files are meant to be incremental changes applied on top of one another while the top level initialdata file is for fresh RT installs.
Extensions may also ship with database changes in such files. You may find some in your install with:
find local/plugins -name initialdata -or -name content
By default, initialdata files are Perl, but often consist primarily of a bunch of data structures defining the new records you want and not much extra code. There's nothing stopping you from writing a bunch of code, however!
RT's initialdata importer is also pluggable and you can add handlers for other formats using the option "InitialdataFormatHandlers" in RT_Config. Starting in RT 5.0, RT supports JSON in addition to Perl. See below for details.
The basic template of a new Perl initialdata file should look something like this:
use strict;
use warnings;
our @Queues = (
# some definitions here
);
our @Groups = (
# some other definitions here
);
1;
The @Queues
and @Groups
arrays are expected by RT and should contain hashref definitions. There are many other arrays RT will look for and act on, described below. None are required, all may be used. Keep in mind that since they're just normal Perl arrays, you can push
onto them from a loop or grep
out definitions based on conditionals or generate their content with map
, etc.
The complete list of possible arrays which can be used, along with descriptions of the values to place in them, is below.
@Users
push @Users, {
Name => 'john.doe',
Password => 'changethis',
Language => 'fr',
Timezone => 'America/Vancouver',
Privileged => 1,
Disabled => 0,
};
Each hashref in @Users
is treated as a new user to create and passed straight into RT::User->Create
. All of the normal user fields are available, as well as Privileged
and Disabled
(both booleans) which will do the appropriate internal group/flag handling. Also accepts an Attributes
key, which is equivalent to pushing its arrayref of values onto @Attributes
, below, with Object
set to the new user.
For a full list of fields, read the documentation for "Create" in RT::User.
@Groups
push @Groups, {
Name => 'Example Employees',
Description => 'All of the employees of my company',
Members => { Users => [ qw/ alexmv trs falcone / ],
Groups => [ qw/ extras / ] },
};
Creates a new RT::Group for each hashref. In almost all cases you'll want to follow the example above to create a group just as if you had done it from the admin interface.
In addition to the Members
option shown above, which can take both users and groups, the MemberOf
field may be a single value or an array ref. Each value should be a user-defined group name or hashref to pass into "LoadByCols" in RT::Group. Each group found will have the new group added as a member.
It also accepts an Attributes
key, which is equivalent to pushing its arrayref of values onto @Attributes
, below, with Object
set to the new group.
@CustomRoles
push @CustomRoles, {
Name => 'Support Rep',
Description => 'Support representative assigned for this ticket',
};
Creates a new RT::CustomRole for each hashref. The above example will create the role globally. To apply the role to only a specific queue, use the ApplyTo
entry as described in "@CustomFields" below.
@Queues
push @Queues, {
Name => 'Helpdesk',
CorrespondAddress => 'help@example.com',
CommentAddress => 'help-comment@example.com',
};
Creates a new RT::Queue for each hashref. Refer to the documentation of "Create" in RT::Queue for the fields you can use. It also accepts an Attributes
key, which is equivalent to pushing its arrayref of values onto @Attributes
, below, with Object
set to the new queue.
@CustomFields
push @CustomFields, {
Name => 'Favorite color',
Type => 'FreeformSingle',
LookupType => 'RT::Queue-RT::Ticket',
};
Creates a new RT::CustomField for each hashref. It is the most complex of the initialdata structures. The most commonly used fields are:
Name
The name of this CF as displayed in RT.
Description
A short summary of what this CF is for.
ApplyTo
May be a single value, or an array reference of such; each should be either an ID or Name. If omitted, the CF is applied globally. This should not be used for User or Group custom fields.
This argument may also be passed via Queue
, for backwards compatibility, which also defaults the LookupType
to RT::Queue-RT::Ticket
.
Type
One of the following on the left hand side:
SelectSingle # Select one value
SelectMultiple # Select multiple values
FreeformSingle # Enter one value
FreeformMultiple # Enter multiple values
Text # Fill in one text area
Wikitext # Fill in one wikitext area
BinarySingle # Upload one file
BinaryMultiple # Upload multiple files
ImageSingle # Upload one image
ImageMultiple # Upload multiple images
Combobox # Combobox: Select or enter one value
AutocompleteSingle # Enter one value with autocompletion
AutocompleteMultiple # Enter multiple values with autocompletion
Date # Select date
DateTime # Select datetime
IPAddressSingle # Enter one IP address
IPAddressMultiple # Enter multiple IP addresses
IPAddressRangeSingle # Enter one IP address range
IPAddressRangeMultiple # Enter multiple IP address ranges
If you don't specify "Single" or "Multiple" in the type, you must specify MaxValues
.
LookupType
Labeled in the CF admin page as "Applies to". This determines whether your CF is for Tickets, Transactions, Users, Groups, or Queues. Possible values:
RT::Queue-RT::Ticket # Tickets
RT::Queue-RT::Ticket-RT::Transaction # Transactions
RT::User # Users
RT::Group # Groups
RT::Queue # Queues
RT::Class-RT::Article # Articles
Ticket CFs are the most common, meaning RT::Queue-RT::Ticket
is the most common LookupType
.
RenderType
Only valid when Type
is "Select". Controls how the CF is displayed when editing it. Valid values are: Select box
, List
, and Dropdown
.
List
is either a list of radio buttons or a list of checkboxes depending on MaxValues
.
MaxValues
Determines whether this CF is a Single or Multiple type. 0 means multiple. 1 means single.
Make sure to set the MaxValues
field appropriately, otherwise you can end up with unsupported CF types like a "Select multiple dates" (it doesn't Just Work).
You can also use old-style Type
s which end with "Single" or "Multiple", for example: SelectSingle, SelectMultiple, FreeformSingle, etc.
Values
Values
should be an array ref (never a single value!) of hashrefs representing new RT::CustomFieldValue objects to create for the new custom field. This only makes sense for "Select" CFs. An example:
my $i = 1;
push @CustomFields, {
LookupType => 'RT::Queue-RT::Ticket', # for Tickets
Name => 'Type of food',
Type => 'SelectSingle', # SelectSingle is the same as: Type => 'Select', MaxValues => 1
RenderType => 'Dropdown',
Values => [
{ Name => 'Fruit', Description => 'Berries, peaches, tomatos, etc', SortOrder => $i++ },
{ Name => 'Vegetable', Description => 'Asparagus, peas, lettuce, etc', SortOrder => $i++ },
# more values as such...
],
};
In order to ensure the same sorting of Values
, set SortOrder
inside each value. A clever way to do this easily is with a simple variable you increment each time (as above with $i
). You can use the same variable throughout the whole file, and don't need one per CF.
BasedOn
Name or ID of another Select Custom Field. This makes the named CF the source of categories for your values.
Pattern
The regular expression text (not qr//
!) used to validate values.
It also accepts an Attributes
key, which is equivalent to pushing its arrayref of values onto @Attributes
, below, with Object
set to the new custom field.
Refer to the documentation and implementation of "Create" in RT::CustomField and "Create" in RT::CustomFieldValue for the full list of available fields and allowed values.
@ACL
@ACL
is very useful for granting rights on your newly created records or setting up a standard system configuration. It is one of the most complex initialdata structures.
Right
sAll ACL definitions expect a key named Right
with the internal right name you want to grant; alternately, it may contain an array reference of right names. The internal right names are visible in RT's admin interface in grey next to the longer descriptions.
After picking a Right
, you need to specify on what object the right is granted. This is different than the user/group/role receiving the right.
CF => 'Name',
LookupType => 'RT::User', # optional, in case you need to disambiguate
Queue => 'Name',
CF => 'Name',
Queue => 'Name',
# This finds the CF named "Name" applied to Articles in the
# "Responses" class
CF => 'Name',
LookupType => RT::Article->CustomFieldLookupType,
ObjectId => 'Responses',
ObjectType => 'RT::Class',
ObjectId => 'Name',
Specifying none of the above will get you a global right.
There is currently no way to grant rights on a group or article class level. Note that you can grant rights to a group; see below. If you need to grants rights on a group or article class level, you'll need to write an @Final
subref to handle it using the RT Perl API.
Finally you need to specify to what system group, system/queue role, user defined group, or user you want to grant the right to.
GroupDomain => 'SystemInternal',
GroupType => 'Everyone, Privileged, or Unprivileged'
GroupDomain => 'RT::System-Role',
GroupType => 'Requestor, Owner, AdminCc, or Cc'
GroupDomain => 'RT::Queue-Role',
Queue => 'Name',
GroupType => 'Requestor, Owner, AdminCc, or Cc',
GroupDomain => 'RT::System-Role',
CustomRole => 'Supervisor',
Queue => 'Customer Support',
GroupDomain => 'RT::Queue-Role',
CustomRole => 'Customer',
GroupDomain => 'UserDefined',
GroupId => 'Name'
UserId => 'Name or email or ID'
You're probably looking for definitions like these most of the time.
{ Right => '...',
GroupDomain => 'UserDefined',
GroupId => 'Name' }
{ Queue => 'Name',
Right => '...',
GroupDomain => 'UserDefined',
GroupId => 'Name' }
{ CF => 'Name',
Right => '...',
GroupDomain => 'UserDefined',
GroupId => 'Name' }
Since you often want to grant a list of rights on the same object/level to the same role/group/user, we generally use Perl loops and operators to aid in the generation of @ACL
without repeating ourselves.
# Give Requestors globally the right to see tickets, reply, and see the
# queue their ticket is in
push @ACL, map {
{
Right => $_,
GroupDomain => 'RT::System-Role',
GroupType => 'Requestor',
}
} qw(ShowTicket ReplyToTicket SeeQueue);
The best troubleshooting is often to see how the rights you define in @ACL
show up in the RT admin interface.
@Scrips
Creates a new RT::Scrip for each hashref. Refer to the documentation of "Create" in RT::Scrip for the fields you can use.
Additionally, the Queue
field is specially handled to make it easier to setup the same Scrip on multiple queues:
Queue => 0,
Queue => 'General', # Name or ID
Queue => ['General', 'Helpdesk', 13], # Array ref of Name or ID
@ScripActions
Creates a new RT::ScripAction for each hashref. Refer to the documentation of "Create" in RT::ScripAction for the fields you can use.
@ScripConditions
Creates a new RT::ScripCondition for each hashref. Refer to the documentation of "Create" in RT::ScripCondition for the fields you can use.
@Templates
Creates a new RT::Template for each hashref. Refer to the documentation of "Create" in RT::Template for the fields you can use.
@Attributes
An array of RT::Attributes to create. You likely don't need to mess with this. If you do, know that the key Object
is expected to be an RT::Record object or a subroutine reference that returns an object on which to call AddAttribute
. If you don't provide Object
or it's undefined, RT->System
will be used.
Here is an example of using a subroutine reference as a value for Object:
@Attributes = ({
Name => 'SavedSearch',
Description => 'New Tickets in SomeQueue',
Object => sub {
my $GroupName = 'SomeQueue Group';
my $group = RT::Group->new( RT->SystemUser );
my( $ret, $msg ) = $group->LoadUserDefinedGroup( $GroupName );
die $msg unless $ret;
return $group;
},
Content => {
Format => <<' END_OF_FORMAT',
....
END_OF_FORMAT
Query => "Status = 'new' AND Queue = 'SomeQueue'",
OrderBy => 'id',
Order => 'DESC'
},
});
@Initial
@Final
@Initial
and @Final
are special and let you write your own processing code that runs before anything else or after everything else. They are expected to be arrays of subrefs (usually anonymous) like so:
our @Final = (sub {
RT->Logger->info("Finishing up!");
});
You have the full power of RT's Perl libraries at your disposal. Be sure to do error checking and log any errors with RT->Logger->error("...")
!
There is currently no way, short of writing code in @Final
or @Initial
, to easily create Classes, Topics, or Articles from initialdata files.
/opt/rt5/sbin/rt-setup-database --action insert --datafile /path/to/your/initialdata
This may prompt you for a database password.
All the handling of initialdata files is done in RT::Handle->InsertData
. If you want to know exactly what's happening with each array, your best bet is to start reading the code there.
RT takes care of the ordering so that your new queues are created before it processes the new ACLs for those queues. This lets you refer to new queues you just created by Name.
To configure RT to load JSON-formatted initialdata, add this option:
Set( $InitialdataFormatHandlers,
[
'perl',
'RT::Initialdata::JSON',
]
);
There is a direct one-to-one mapping between the Perl initialdata structures and the JSON file data structures, with the exception of how the top-level elements are composed. In the Perl file, each array is named separately, like this:
@Queues = ( {...}, {...} );
@Scrips = ( {...}, {...} );
To represent this in JSON, the root-level element is a JSON object--a key/value structure that is analogous to a perl hash. The key is the name of the array you would normally type as @Queues
, and the value is a JSON array:
{
"Queues":[ {...}, {...} ],
"Scrips":[ {...}, {...} ]
}
You can find details on JSON formatting rules at http://json.org.
There is a JSON file with examples in the RT test files here:
F<t/data/initialdata/initialdata.json>
The JSON initialdata format cannot support the full functionality of the perl format, as the perl format allows executable code. Specifically, these elements cannot be used, and if present, will be ignored:
@Initial
No Initial
elements will be used.
@Final
No Final
elements will be used.