Request Tracker Wiki - User contributions [en]

Talk:AutogeneratedPassword/@comment-BillCole-20140423222528

2014-04-23T22:25:28Z

BillCole: Created page with "It seems to me that while $Transaction->CreatorObj will be the right user when a ticket is created via email, this would be better (and maybe safer) if the code checked to ass..."

It seems to me that while $Transaction->CreatorObj will be the right user when a ticket is created via email, this would be better (and maybe safer) if the code checked to assure that there is only one member in $Ticket->Requestors and conditionally set the password for ''that'' user if they don't already have one. Referencing the Requestor instead of the Creator eliminates the edge cases that are hinted at by the current code checking for Nobody and Privileged status.

I believe that rework would make the password generation happen when a Privileged (i.e. support staff) user creates a ticket (i.e. in the web interface) with a single Requestor whose account lacks a password.

Demo

2012-09-11T15:35:58Z

BillCole: Reverted edits by 115.254.78.226 (talk | block) to last version by BillCole

If you want to try RT, you can find demonstrations sites here: http://rt.easter-eggs.org/demos/.

FindingAnswersAboutRT

2012-09-10T13:43:27Z

BillCole: Reverted edits by 88.173.209.40 (talk | block) to last version by Jibsheet

=== Introduction ===

Becoming familiar with RT and the resources available to answer your questions can be difficult at first. Frequently you get no answers or very terse answers which don't seem to provide enough guidance. This can be frustrating; it can seem like no one wants to help you when quite often they do.

=== First, do the legwork ===

There are a number of places to start your research before you post to the mailing list or send a note to someone who maintains some extension of RT. Here are a few searchable places, listed in order of likely usefulness:

# [http://wiki.bestpractical.com This Wiki] (the place with lots of answers)
# [[MailingListArchives]] (searchable list archives)
# http://www.google.com/ (I generally start "+RT +MostUniqueErrMsg")

Search there for answers to your questions. Very frequently you'll find just what you're looking for and perhaps more.

=== Ask the Right People ===

If you can't find information on the wiki or in the mailing list archives, you should generally direct your questions to one of the RT [[MailingLists]]. Generally, you'll want to direct your questions to the rt-users mailing list, as that's the right place for them (and nearly everyone on rt-devel is also on rt-users). Posting to rt-users allows you the benefit of experienced RT admins' knowledge, which will likely solve your problem much more quickly than any other approach.

The rt-devel list is for development issues such as "I'm thinking of implementing thus-and-such and wonder how I should go about it" or "I found a bug and fixed it; here's a patch" and the like.

While it's often tempting to think you've got a bug or critical issue and should immediately send it to rt-devel, most of the time it's not a bug, but a misconfiguration on your part, which results in a terse note pointing this out and directing you to do the legwork (as mentioned below).

'''''Please don't create a wiki page to ask a question or add a question to the body of a wiki page.''''' A wiki isn't a support group, it is an information repository. It may be reasonable in some cases to ask a question related to the specific topic of a wiki page in its "Talk" sub-page (particularly if the page content is unclear or incorrect) but as a practical matter that is unlikely to be as productive towards getting a good answer as aking your question on the rt-users mailing list, where there is a broad audience of people following the discussion. The time to create a wiki page is '''''after''''' you have an answer that could be useful to others in the future.

'''''Please don't send email directly to the bestpractical.com developers'''''. This may seem callous, but consider this: anyone with a bestpractical.com email address is trying to make a living working on RT; the rest of us have a full-time day job and voluntarily contribute to RT as we can. None of us wants to give up precious development time in order to do your initial legwork; conversely, we're happy to help once you've done it and still have questions.

=== Ask a good question well ===

Note that there's an extensive treatise on the art of asking good questions well at http://www.catb.org/~esr/faqs/smart-questions.html

Good questions are clear, concise, and demonstrate that you've done the legwork as mentioned above. They also show an presumption of ignorance on your part unless *you're absolutely certain you really understand exactly what's going on*. I've been working with RT for six years off- and-on and I still learn new things ... usually starting with an incorrect assumption on my part ;]

A bit of an aside: nothing blows your credibility and diminishes interest in replying quite like an it's-all-screwed-up-and-must-be-a-bug message. RT is a large, complex, mature software system and you're probably not the first person to want to use feature X. It's very likely that there are many people using that feature and they'd be happy to help you join them.

Also, choose a descriptive subject; it's your first impression and will determine who reads your message. Get the good bits early in the subject (you don't know how many characters I'll see in my mailreader). Here are some good ones (chosen randomly from recent postings):

Can rt users come from LDAP?
Installing RT on Fedora Core 4
RT VMWare Appliance
Show stalled on AtAGlance list?

Each of these gives clear guidance to the topic at hand. If it's a subject I might have unique knowledge on or a distinct interest in, I'll definitely make time to read it.

Here are some horrible ones (chosen randomly from long ago to minimize embarassment):

RT questions
Lost information
Headings
Great Program!

As you can see from these last, I have no chance to know what problems lie inside the email or whether I can provide uniquely useful information. On a slow day, I might read one of these to see if I can help. One a busy day, these go straight to the trash.

Here's a decent framework to hang your question on:

Subject: FOO config problems while trying to BAR

I'm having problems properly configuring FOO. I thought I knew
how it worked, but my attempts have all failed and searching both
the wiki and the mailing list archives hasn't improved my
understanding enough to make it work.

I'm trying to use FOO to BAR [insert concise statement of purpose]

So far, I've tried to [insert concise summary of the saga]

I'm using RT [version] on [OS and version] with [all pertinent
web server details like apache version, mod_perl/fast_cgi, etc.]

Can anyone point me in the right direction?

=== Give A Little Bit ===

If you've come up with the answer to a sticky problem, consider giving back to the community either by summarizing to the mailing list or into the wiki. That'll help the next generation of new RT admins ... and save you answering their questions on the list over and over again. ;]

OnCreateSetDeptHeadCc

2012-08-21T03:44:38Z

BillCole: Reverted edits by 208.70.50.7 (talk | block) to last version by Best Practical

= Overview =

Dept heads need to see and reply to tickets opened by their staff. This is accomplished by giving the global 'Cc' group [[ShowTicket]] perms and automatically making the dept head a Cc on the ticket.

On create in the case that [[CustomField]].Department = 'Foo' then add group 'Head Foo' as a Cc. Be sure to first check that the Requestor is not in the 'Head Foo' group. That may be problematic for odd departments or units with more than one member in a 'Head x' group. (See also [[OnCreateAddGroupCc]].)

= Scrip =

All tickets have a Department custom field mapping the ticket to a dept. I globally grant the Cc role [[ShowTicket]] and [[ReplyToTicket]] permission and then add the department head as Cc on their staff's tickets. This way they can add comments and be aware of issues in their department. I do not yet wish to give them powers such as [[ModifyTicket]], so they can't monkey with priorities etc. Therefore, I felt Cc more appropriate than [[AdminCc]] even after granting extra rights to Cc.

* <nowiki>Description: ''</nowiki>[[OnCreateSetDeptHeadCc]]<nowiki>'' </nowiki>
* <nowiki>Condition: ''User Defined'' </nowiki>
* <nowiki>Action: ''User Defined'' </nowiki>
* <nowiki>Template: ''Global template: Blank'' </nowiki>
* <nowiki>Stage: ''</nowiki>[[TransactionCreate]]<nowiki>'' </nowiki>

* Custom Condition:

<nowiki># make sure we are called from a on create condition and
# make sure department is filled out
if (
(
($self->TransactionObj->Type eq "Create")
|| ($self->TransactionObj->Type eq "CustomField")
) && (
$self->TicketObj->FirstCustomFieldValue('Department')
&& ($self->TicketObj->FirstCustomFieldValue('Department') ne 'None')
)
) {
#$RT::Logger->info("Met User Defined OnCreateSetDeptHeadCc Condition #".
# $self->TicketObj->id ." ".
# $self->TicketObj->FirstCustomFieldValue('Department') );
return 1;
} else {
#$RT::Logger->info("Did Not Meet User Defined OnCreateSetDeptHeadCc Condition #".
# $self->TicketObj->id ." ". $self->TicketObj->FirstCustomFieldValue('Department') );
return undef;
}

</nowiki>

* Custom action preparation code:

<nowiki># example: for 'Systems' the group is 'Head Systems'
my $derivedGroupName = 'Head ' . $self->TicketObj->FirstCustomFieldValue('Department');

# instantiated a group object
my $groupObj = RT::Group->new($RT::SystemUser);
$groupObj->LoadUserDefinedGroup($derivedGroupName);
return undef unless $groupObj;

# one doesn't want to be a requestor and a Cc on the same ticket.
# don't add group as CC if requestor is in that group
# this could certainly be a problem if there are multiple members in a group
my $requestorsGroupObj = $self->TicketObj->Requestors;
# UMO grabs group members in subgroups too it is recursive
my $requestorsMembersObj = $requestorsGroupObj->UserMembersObj;

my $userObj;
while ($userObj = $requestorsMembersObj->Next) {
if ($groupObj->HasMember($userObj->PrincipalObj)) {
$RT::Logger->info("Requestor '" . $userObj->Name .
"' is in group '$derivedGroupName' not adding Cc on ticket #" .
$self->TicketObj->id );

return undef;
}
}

# add group as Cc on ticket. see Ticket_Overlay.pm
$RT::Logger->info("Add group '$derivedGroupName' as Cc on ticket #" .
$self->TicketObj->id );
my ($success, $msg)= $self->TicketObj->AddWatcher(
Type => "Cc",
PrincipalId => $groupObj->PrincipalId);

if (! $success) {
$RT::Logger->info($msg);
return undef;
} else {
return 1;
}
</nowiki>

* Custom action cleanup code:

<nowiki># blank

</nowiki>

== Include CC Tickets in SelfService ==

After the Department head has been made CC on a ticket they need an easy way to view all such tickets. So, let's modify [[SelfService]] to show them.

Put the pieces in place:

[root@lakshmi Elements]# mkdir -p /usr/local/rt/html/SelfService/Elements
[root@lakshmi Elements]# cp MyRequests /usr/local/rt/html/SelfService/Elements

Make one small change.

[root@lakshmi Elements]# diff -u MyRequests /usr/local/rt/html/SelfService/Elements/MyRequests
--- MyRequests 2005-02-01 06:20:40.000000000 -0800
+++ /usr/local/rt/html/SelfService/Elements/MyRequests 2006-02-27 11:00:31.000000000 -0800
@@ -70,7 +70,7 @@
$title ||= loc("My [_1] tickets", $friendly_status);
my $MyTickets;
$MyTickets = new RT::Tickets ($session{'CurrentUser'});
-$MyTickets->LimitWatcher(TYPE => 'Requestor', VALUE => $session{'CurrentUser'}->EmailAddress);
+$MyTickets->LimitWatcher(VALUE => $session{'CurrentUser'}->EmailAddress);
$MyTickets->OrderBy(FIELD => 'id', ORDER => 'ASC');

foreach my $status (@status) {

= Bugs in Solution =

* If there is more than one user in a 'Head X' group and one user opens a ticket, the other user will not become a Cc.

This would in an issue in departments with more than one "head". We can worry about that later. (Also see [[OnCreateAddGroupCc]].)

* If the Department changes during the life of the ticket, the new Cc will be added, but the old Cc will not be removed.

* How can send the [[AutoReply]] to the department head as well as the requestor?

Schema

2012-08-21T03:41:28Z

BillCole: Reverted edits by 89.190.196.121 (talk | block) to last version by Tsibley

==RT 4==
On the left is a quick export generated by dbVisualizer. This is just tables and columns; there are no enforced relational integrity constraints at the database levels.

On the right is a diagram of the relationships between tables, generated from the schema.dot file which ships with RT 4 under the docs/ directory.

<gallery captionalign="left">
rt_schema.svg|RT4 Schema
Rt4-schema-relationships.svg|RT 4 schema relationships
</gallery>

==RT 3.x==

Look at the file 'docs/rt-schema-relationships.dot', included in the RT 3.x distribution (download page: http://www.bestpractical.com/rt/download.html ).

Or, browse http://svn.bestpractical.com/cgi-bin/index.cgi/bps/browse/rt/branches/ , choose the link to the relevant RT version, then click on the 'docs' link, then on 'rt3-schema-relationships.dot'.

== How to visualize 'dot' format ==

* dbdesigner4, see http://www.fabforce.net/dbdesigner4/ (sooner or later will be [[MySQL]] Workbench. See: [http://www.fabforce.net/forum/ The FabForce Forum])
* graphviz, see http://www.research.att.com/sw/tools/graphviz/

== Existing visualizations ==

* [http://bestpractical.com/rt/3.4-schema.png Official RT 3.4 schema] by [[JesseVincent]]

(Warning: these may be out of date. You can always download dotty or other visualizer and apply it to your .dot file to see the latest).

Demo

2012-07-25T16:24:37Z

BillCole: Reverted edits by 84.14.180.66 (talk | block) to last version by BillCole

If you want to try RT, you can find demonstrations sites here: http://rt.easter-eggs.org/demos/.

FindingAnswersAboutRT

2012-06-28T18:32:47Z

BillCole: Fixed wiki link, added exhortation not to clutter the wiki

=== Introduction ===

Becoming familiar with RT and the resources available to answer your questions can be difficult at first. Frequently you get no answers or very terse answers which don't seem to provide enough guidance. This can be frustrating; it can seem like no one wants to help you when quite often they do.

=== First, do the legwork ===

There are a number of places to start your research before you post to the mailing list or send a note to someone who maintains some extension of RT. Here are a few searchable places, listed in order of likely usefulness:

# [http://requesttracker.wikia.com This Wiki] (the place with lots of answers)
# [[MailingListArchives]] (searchable list archives)
# http://www.google.com/ (I generally start "+RT +MostUniqueErrMsg")

Search there for answers to your questions. Very frequently you'll find just what you're looking for and perhaps more.

=== Ask the Right People ===

If you can't find information on the wiki or in the mailing list archives, you should generally direct your questions to one of the RT [[MailingLists]]. Generally, you'll want to direct your questions to the rt-users mailing list, as that's the right place for them (and nearly everyone on rt-devel is also on rt-users). Posting to rt-users allows you the benefit of experienced RT admins' knowledge, which will likely solve your problem much more quickly than any other approach.

The rt-devel list is for development issues such as "I'm thinking of implementing thus-and-such and wonder how I should go about it" or "I found a bug and fixed it; here's a patch" and the like.

While it's often tempting to think you've got a bug or critical issue and should immediately send it to rt-devel, most of the time it's not a bug, but a misconfiguration on your part, which results in a terse note pointing this out and directing you to do the legwork (as mentioned below).

'''''Please don't create a wiki page to ask a question or add a question to the body of a wiki page.''''' A wiki isn't a support group, it is an information repository. It may be reasonable in some cases to ask a question related to the specific topic of a wiki page in its "Talk" sub-page (particularly if the page content is unclear or incorrect) but as a practical matter that is unlikely to be as productive towards getting a good answer as aking your question on the rt-users mailing list, where there is a broad audience of people following the discussion. The time to create a wiki page is '''''after''''' you have an answer that could be useful to others in the future.

'''''Please don't send email directly to the bestpractical.com developers'''''. This may seem callous, but consider this: anyone with a bestpractical.com email address is trying to make a living working on RT; the rest of us have a full-time day job and voluntarily contribute to RT as we can. None of us wants to give up precious development time in order to do your initial legwork; conversely, we're happy to help once you've done it and still have questions.

=== Ask a good question well ===

Note that there's an extensive treatise on the art of asking good questions well at http://www.catb.org/~esr/faqs/smart-questions.html

Good questions are clear, concise, and demonstrate that you've done the legwork as mentioned above. They also show an presumption of ignorance on your part unless *you're absolutely certain you really understand exactly what's going on*. I've been working with RT for six years off- and-on and I still learn new things ... usually starting with an incorrect assumption on my part ;]

A bit of an aside: nothing blows your credibility and diminishes interest in replying quite like an it's-all-screwed-up-and-must-be-a-bug message. RT is a large, complex, mature software system and you're probably not the first person to want to use feature X. It's very likely that there are many people using that feature and they'd be happy to help you join them.

Also, choose a descriptive subject; it's your first impression and will determine who reads your message. Get the good bits early in the subject (you don't know how many characters I'll see in my mailreader). Here are some good ones (chosen randomly from recent postings):

Can rt users come from LDAP?
Installing RT on Fedora Core 4
RT VMWare Appliance
Show stalled on AtAGlance list?

Each of these gives clear guidance to the topic at hand. If it's a subject I might have unique knowledge on or a distinct interest in, I'll definitely make time to read it.

Here are some horrible ones (chosen randomly from long ago to minimize embarassment):

RT questions
Lost information
Headings
Great Program!

As you can see from these last, I have no chance to know what problems lie inside the email or whether I can provide uniquely useful information. On a slow day, I might read one of these to see if I can help. One a busy day, these go straight to the trash.

Here's a decent framework to hang your question on:

Subject: FOO config problems while trying to BAR

I'm having problems properly configuring FOO. I thought I knew
how it worked, but my attempts have all failed and searching both
the wiki and the mailing list archives hasn't improved my
understanding enough to make it work.

I'm trying to use FOO to BAR [insert concise statement of purpose]

So far, I've tried to [insert concise summary of the saga]

I'm using RT [version] on [OS and version] with [all pertinent
web server details like apache version, mod_perl/fast_cgi, etc.]

Can anyone point me in the right direction?

=== Give A Little Bit ===

If you've come up with the answer to a sticky problem, consider giving back to the community either by summarizing to the mailing list or into the wiki. That'll help the next generation of new RT admins ... and save you answering their questions on the list over and over again. ;]

Demo

2012-06-28T17:57:34Z

BillCole: Reversing multiple random pointless bogus category additions

If you want to try RT, you can find demonstrations sites here: http://rt.easter-eggs.org/demos/.

Demo

2012-06-28T17:52:12Z

BillCole: Reverted edits by 99.27.183.131 (talk | block) to last version by 86.1.241.82

If you want to try RT, you can find demonstrations sites here: http://rt.easter-eggs.org/demos/.
[[Category:test]]
[[Category:Test]]
[[Category:skjdfklsjdlfsjlfj]]
[[Category:bbvbv]]

Documentation

2012-05-18T23:46:37Z

BillCole: Cleanup weird stray brackets

This page describes how to do various tasks. These are mainly articles that were written by the RT community.

If you haven't installed RT then you should read [[InstallationGuides]]. You may also want to see the wiki pages [[FAQ]] and [[UserManual]]

== Configuration ==

* [[SiteConfig]] - All about configuring RT using RT_SiteConfig.pm file.

* [[ApacheConfig]] - Apache configuration tips, for first time configuration read [[ManualApacheConfig]].
* [[ActiveDirectory]] - Several authentication techniques.
* [[CustomStatuses]] - How to add custom statuses and reasons why you don't want to do this.
* [[FastCGIConfiguration]]
* [[LockLessSessionsMySQL]] - How to configure sessions in mysql without locks
* [[MultipleInstances]] - Run multiple RT instances, mixing-and-matching versions of RT and local modification.
* [[PerformanceTuning]] - RT can run fast!
* [[PrivilegedUsers]] - So you know who should be privileged in your RT.
* [[RenameInstance]] - How to change the name of an RT instance
* [[Rights]] - Descriptions of most rights in RT.
* [[RightsQuickStart]] - Getting started using RT Rights.
* [[SomeProblems]] - Easy, uncommon problems and their solutions.

== Email Interface ==

This section is about [[MTAs]] and handling of incoming and transferring outgoing emails. See also section about scrips below to get ideas how to configure notifications and its content.

[[EmailInterface]] - all things about handling emails in one place

== Web User Interface ==

* [[AddCustomStyleSheet]] - How to add a css file using a callback
* [[ChangeDefaultRTAtAGlance]] - How to change the default RT At A Glance page in RT 3.5.x
* [[ChangeLogo]] - How to change the RT logo from the default Best Practical logo.
* [[DisplayCustomFieldsInTicketSearch]]
* [[HideConfigurationTab]] - Hide the configuration tab from regular users.
* [[PersistentSessions]] - Making users' sessions persistent
* [[ReverseHistoryOrder]] - Reverse the order of transactions on a ticket's history page.
* [[RssFeed]] - How to use RT's RSS feeds.
* [[SearchOnDates]] - Describes how powerful a search on dates can be.
* [[TicketDates]] - Describes all date fields [[Ticket]] has
* [[TicketSQL]] - Pseudo SQL used in the Query Builder and API
* [[Dashboards]] - A collection of saved searches that are run on a schedule you define and emailed to you.
* [[UpdatevsSaveChanges]] - Difference between "Update" and "Save Changes" button in UI

== Service tasks and RT system maintenance ==

See also [[EmailInterface]] and configuration section above

* [[CleanupSessions]] - in the most cases you should do it
* [[ConfigureEscalation]]
* [[RecoverRootPassword]]
* [[RecoverSuperUserRights]]
* [[RenameInstance]] - How to change the name of an RT instance
* [[TimedNotifications]] - Use RT-Crontool to automatically send ticket-related notifications.
* [[UseRtCrontool]] - Description of rt-crontool usage.
* [[UseRtReminder]] - Description of contrib rt-remind script.
* [[UseRtTool]] - Description of the <code>bin/rt</code> command line tool.

== RT for Bug tracking ==

* [[SeverityCodes]]

== Scrips ==

Everything related to [[Scrip]]s, [[ScripAction]]s, [[ScripCondition]]s and [[Template]]s. See also "Customization & Internals" below.

* [[AddNewNotifyActions]] - How to add new notify actions with <code>Action::Notify</code> module (part of RT)
* [[ApprovalCreation]] - An attempt at an easier description of the Approval mechanism.
* [[ApproximateSeparateQueues]] - A description of one method using LDAP and custom fields to approximate separate queues.
* [[AutogeneratedPassword]] - Send users an autogenerated password on ticket submission.
* [[ChooseTemplateByUserLang]] - On the fly choose alternative template according to user's language.
* [[CodeSnippets]]
* [[NotifyOwner]] - Send ticket owners notification that they now own a ticket.
* [[ScripExecOrder]]
* [[UniqueAutoReplies]] - How to Generate a different Auto-Reply for each Queue.
* [[WorkFlow]] - Modeling a simple workflow with RT
* [[WorkFlow2]] - Slightly different workflow with RT
* [[WriteCustomAction]] - Article about custom actions writing.
* [[WriteCustomCondition]] - Article about custom conditions writing.

== Migrate ==

* [[PgToMySQL]] - migration process from PostgreSQL to MySQL.
* [[MySQLToPg]] - migration process from MySQL to PostgreSQL.
* [[MigrateToNewServer]] - migration from one server to another.
* [[MySQLToOracle]] - migration process from MySQL to !Oracle

== RT database ==

* [[AddDatabaseRecords]] - adding records into DB without code or SQL
* [[DBSchema]]
* [[DatabaseAdmin]]
* [[SetStartingId]] - how to set starting id in the RT table, for example id of the tickets
* [[GetWatcherInfoByTicket]] - SQL query that SELECT [[Requestor]]s, [[Cc]]s, [[AdminCc]]s info by [[Ticket]] id.
* [[GetTicketInfoByWatcher]] - SQL query that SELECT [[Ticket]]s info by [[Requestor]]s, [[Cc]]s or [[AdminCc]]s id.
* [[AttachmentsSizeSQL]]

== Customization & Internals ==

* [[AutomatedTests]] - How to write RT automated tests.
* [[ClassObjectsMethods]] - Definition of the Class, Objects and Methods used in the RT (useful to do scrips)
* [[Customizing]] - introduction to RT's customization features.
* [[Debug]] - How to enable debug output in RT, Apache, and your database server.
* [[GetSoftwareVersions]] - Discovering which versions of software you have installed.
* [[GlobalObjects]] - Global variables and objects that can be used in your code.
* [[ObjectModel]] - overview of the RT API.
* [[ScripExecOrder]]
* [[TransactionBatchStage]]

== Other ==

* [[AccentBug]] - How to work around UTF/accent bug if using Perl < 5.8.3
* [[CliBasics]] - A basic example on writing a CLI program to add tickets with custom fields.
* [[CompilingPerl]]

Demo

2012-01-05T13:28:52Z

BillCole: Reverted edits by 84.250.185.29 (talk | block) to last version by BillCole

If you want to try RT, you can find demonstrations sites here: http://rt.easter-eggs.org/demos/.

Demo

2011-12-26T15:38:48Z

BillCole: Reverted edits by 46.161.92.204 (talk | block) to last version by BillCole

If you want to try RT, you can find demonstrations sites here: http://rt.easter-eggs.org/demos/.

Demo

2011-12-23T05:17:24Z

BillCole: Undo revision 6787 by 94.198.48.35 (talk)

If you want to try RT, you can find demonstrations sites here: http://rt.easter-eggs.org/demos/.

Demo

2011-12-23T05:15:57Z

BillCole: Reverted edits by 204.155.172.22 (talk | block) to last version by 94.198.48.35

If you want to try RT, you can find demonstrations sites here: http://rt.easter-eggs.org/demos/.
[[Category:214234]]

RTConfig382

2011-12-15T19:46:41Z

BillCole: Reverted edits by 92.160.55.19 (talk | block) to last version by Best Practical

NAME

RT::Config

use RT::Config;

WARNING

NEVER EDIT RT_Config.pm.

Instead, copy any sections you want to change to RT_SiteConfig.pm and edit them there.

Base Configuration

$rtname
$rtname is the string that RT will look for in mail messages to figure out what ticket a new piece of mail belongs to.

Your domain name is recommended, so as not to pollute the namespace. once you start using a given tag, you should probably never change it. (otherwise, mail for existing tickets won't get put in the right place)

$EmailSubjectTagRegex
This regexp controls what subject tags RT recognizes as its own. If you're not dealing with historical $rtname values, you'll likely never have to enable this feature.

Be VERY CAREFUL with it. Note that it overrides $rtname for subject token matching and that you should use only "non-capturing" parenthesis grouping. For example:

"Set($EmailSubjectTagRegex, qr/(?:example.com|example.org)/i );"

and NOT

"Set($EmailSubjectTagRegex, qr/(example.com|example.org)/i );"

This setting would make RT behave exactly as it does without the setting enabled.

$Organization
You should set this to your organization's DNS domain. For example, fsck.com or asylum.arkham.ma.us. It's used by the linking interface to guarantee that ticket URIs are unique and easy to construct.

$MinimumPasswordLength
$MinimumPasswordLength defines the minimum length for user passwords. Setting it to 0 disables this check.

$Timezone
$Timezone is used to convert times entered by users into GMT and back again It should be set to a timezone recognized by your local unix box.

Database Configuration

$DatabaseType
Database driver being used; case matters.

Valid types are "mysql", "Oracle" and "Pg"

$DatabaseHost, $DatabaseRTHost
The domain name of your database server.

If you're running mysql and it's on localhost, leave it blank for enhanced performance

$DatabasePort
The port that your database server is running on. Ignored unless it's a positive integer. It's usually safe to leave this blank

$DatabaseUser
The name of the database user (inside the database)

$DatabasePassword
Password the $DatabaseUser should use to access the database

$DatabaseName
The name of the RT's database on your database server

$DatabaseRequireSSL
If you're using Postgres and have compiled in SSL support, set $DatabaseRequireSSL to 1 to turn on SSL communication

$UseSQLForACLChecks
In RT for ages ACL are checked after search what in some situtations result in empty search pages and wrong count of tickets.

Set $UseSQLForACLChecks to 1 to use SQL and get rid of these problems.

However, this option is beta. In some cases it result in performance improvements, but some setups can not handle it.

Incoming Mail Gateway Configuration

$OwnerEmail
$OwnerEmail is the address of a human who manages RT. RT will send errors generated by the mail gateway to this address. This address should _not_ be an address that's managed by your RT instance.

$LoopsToRTOwner
If $LoopsToRTOwner is defined, RT will send mail that it believes might be a loop to $OwnerEmail

$StoreLoops
If $StoreLoops is defined, RT will record messages that it believes to be part of mail loops.

As it does this, it will try to be careful not to send mail to the sender of these messages

$MaxAttachmentSize
$MaxAttachmentSize sets the maximum size (in bytes) of attachments stored in the database.

For mysql and oracle, we set this size at 10 megabytes. If you're running a postgres version earlier than 7.1, you will need to drop this to 8192. (8k)

$TruncateLongAttachments
$TruncateLongAttachments: if this is set to a non-undef value, RT will truncate attachments longer than $MaxAttachmentSize.

$DropLongAttachments
$DropLongAttachments: if this is set to a non-undef value, RT will silently drop attachments longer than "MaxAttachmentSize".

$ParsenewMessageForTicketCcs
If $ParseNewMessageForTicketCcs is true, RT will attempt to divine Ticket 'Cc' watchers from the To and Cc lines of incoming messages Be forewarned that if you have _any_ addresses which forward mail to RT
automatically and you enable this option without modifying $RTAddressRegexp below, you will get yourself into a heap of trouble.

$RTAddressRegexp
$RTAddressRegexp is used to make sure RT doesn't add itself as a ticket CC if the setting above is enabled.

$CanonicalizeEmailAddressMatch, $CanonicalizeEmailAddressReplace
RT provides functionality which allows the system to rewrite incoming email addresses. In its simplest form, you can substitute the value in $<CanonicalizeEmailAddressReplace> for the value in
$<CanonicalizeEmailAddressMatch> (These values are passed to the $<CanonicalizeEmailAddress> subroutine in
RT/User.pm)

By default, that routine performs a "s/$Match/$Replace/gi" on any address passed to it.

$CanonicalizeEmailAddressMatch
Set this to true and the create new user page will use the values that you enter in the form but use the function CanonicalizeUserInfo in RT/User_Local.pm

$SenderMustExistInExternalDatabase
If $SenderMustExistInExternalDatabase is true, RT will refuse to create non-privileged accounts for unknown users if you are using the $LookupSenderInExternalDatabase option. Instead, an error message will be mailed
and RT will forward the message to $RTOwner.

If you are not using $LookupSenderInExternalDatabase, this option has no effect.

If you define an AutoRejectRequest template, RT will use this template for the rejection message.

@MailPlugins
@MailPlugins is a list of auth plugins for RT::Interface::Email to use; see rt-mailgate

$UnsafeEmailCommands
$UnsafeEmailCommands, if set to true, enables 'take' and 'resolve' as possible actions via the mail gateway. As its name implies, this is very unsafe, as it allows email with a forged sender to possibly resolve
arbitrary tickets!

$ExtractSubjectTagMatch, $ExtractSubjectTagNoMatch
The default "extract remote tracking tags" scrip settings; these detect when your RT is talking to another RT, and adjusts the subject accordingly.

Outgoing Mail Configuration

$MailCommand
$MailCommand defines which method RT will use to try to send mail. We know that 'sendmailpipe' works fairly well. If 'sendmailpipe' doesn't work well for you, try 'sendmail'. Other options are 'smtp' or 'qmail'.

Note that you should remove the '-t' from $SendmailArguments if you use 'sendmail' rather than 'sendmailpipe'

Sendmail Configuration

These options only take effect if $MailCommand is 'sendmail' or 'sendmailpipe'

$SendmailArguments
$SendmailArguments defines what flags to pass to $SendmailPath If you picked 'sendmailpipe', you MUST add a -t flag to $SendmailArguments These options are good for most sendmail wrappers and workalikes

These arguments are good for sendmail brand sendmail 8 and newer "Set($SendmailArguments,"-oi -t -ODeliveryMode=b -OErrorMode=m");"

$SendmailBounceArguments
$SendmailBounceArguments defines what flags to pass to $Sendmail assuming RT needs to send an error (ie. bounce).

$SendmailPath
If you selected 'sendmailpipe' above, you MUST specify the path to your sendmail binary in $SendmailPath.

SMTP Configuration

These options only take effect if $MailCommand is 'smtp'

$SMTPServer
$SMTPServer should be set to the hostname of the SMTP server to use

$SMTPFrom
$SMTPFrom should be set to the 'From' address to use, if not the email's 'From'

$SMTPDebug
$SMTPDebug should be set to true to debug SMTP mail sending

Other Mailer Configuration

@MailParams
@MailParams defines a list of options passed to $MailCommand if it is not 'sendmailpipe', 'sendmail', or 'smtp'

$CorrespondAddress, $CommentAddress
RT is designed such that any mail which already has a ticket-id associated with it will get to the right place automatically.

$CorrespondAddress and $CommentAddress are the default addresses that will be listed in From: and Reply-To: headers of correspondence and comment mail tracked by RT, unless overridden by a queue-specific address.

$DashboardAddress
The email address from which RT will send dashboards. If none is set, then $OwnerEmail will be used.

$UseFriendlyFromLine
By default, RT sets the outgoing mail's "From:" header to "SenderName via RT". Setting $UseFriendlyFromLine to 0 disables it.

$FriendlyFromLineFormat
"sprintf()" format of the friendly 'From:' header; its arguments are SenderName and SenderEmailAddress.

$UseFriendlyToLine
RT can optionally set a "Friendly" 'To:' header when sending messages to Ccs or AdminCcs (rather than having a blank 'To:' header.

This feature DOES NOT WORK WITH SENDMAIL[tm] BRAND SENDMAIL If you are using sendmail, rather than postfix, qmail, exim or some other MTA, you _must_ disable this option.

$FriendlyToLineFormat
"sprintf()" format of the friendly 'From:' header; its arguments are WatcherType and TicketId.

$NotifyActor
By default, RT doesn't notify the person who performs an update, as they already know what they've done. If you'd like to change this behaviour, Set $NotifyActor to 1

$RecordOutgoingEmail
By default, RT records each message it sends out to its own internal database. To change this behavior, set $RecordOutgoingEmail to 0

$VERPPrefix, $VERPPrefix
VERP support (http://cr.yp.to/proto/verp.txt)

uncomment the following two directives to generate envelope senders of the form "${VERPPrefix}${originaladdress}@${VERPDomain}" (i.e. rt-jesse=fsck.com@rt.example.com ).

This currently only works with sendmail and sendmailppie.

$ForwardFromUser
By default, RT forwards a message using queue's address and adds RT's tag into subject of the outgoing message, so recipients' replies go into RT as correspondents.

To change this behavior, set $ForwardFromUser to true value and RT will use address of the current user and leave subject without RT's tag.

$ShowBccHeader
By default RT hides from the web UI information about blind copies user sent on reply or comment.

To change this set the following option to true value.

$DashboardSubject
Lets you set the subject of dashboards. Arguments are the frequency (Daily, Weekly, Monthly) of the dashboard and the dashboard's name. [_1] for the name of the dashboard.

[[GnuPG]] Configuration

A full description of the (somewhat extensive) GnuPG integration can be found by running the command 'perldoc RT::Crypt::GnuPG' (or 'perldoc
lib/RT/Crypt/GnuPG.pm' from your RT install directory).

%GnuPG
Set "OutgoingMessagesFormat" to 'inline' to use inline encryption and signatures instead of 'RFC' (GPG/MIME: RFC3156 and RFC1847) format.

If you want to allow people to encrypt attachments inside the DB then set "AllowEncryptDataInDB" to true

%GnuPGOptions
Options of GnuPG program.

If you override this in your RT_SiteConfig, you should be sure to include a homedir setting.

NOTE that options with '-' character MUST be quoted.

Logging Configuration

The default is to log anything except debugging information to syslog. Check the Log::Dispatch POD for information about how to get things by syslog, mail or anything else, get debugging info in the log, etc.

It might generally make sense to send error and higher by email to some administrator. If you do this, be careful that this email isn't sent to this RT instance. Mail loops will generate a critical log message.

$LogToSyslog, $LogToScreen
The minimum level error that will be logged to the specific device. From lowest to highest priority, the levels are:
debug info notice warning error critical alert emergency

$LogToFile, $LogDir, $LogToFileNamed
Logging to a standalone file is also possible, but note that the file should needs to both exist and be writable by all direct users of the RT API. This generally include the web server, whoever rt-crontool runs as.
Note that as rt-mailgate and the RT CLI go through the webserver, so their users do not need to have write permissions to this file. If you expect to have multiple users of the direct API, Best Practical recommends
using syslog instead of direct file logging.

$LogStackTraces
If set to a log level then logging will include stack traces for messages with level equal to or greater than specified.

@LogToSyslogConf
On Solaris or UnixWare, set to ( socket => 'inet' ). Options here override any other options RT passes to Log::Dispatch::Syslog. Other interesting flags include facility and logopt. (See the Log::Dispatch::Syslog
documentation for more information.) (Maybe ident too, if you have multiple RT installations.)

$StatementLog,
RT has rudimentary SQL statement logging support if you have DBIx-SearchBuilder 1.31_1 or higher; simply set $StatementLog to be the level that you wish SQL statements to be logged at.

Web Interface Configuration

<nowiki>$WebDefaultStylesheet
This determines the default stylesheet the RT web interface will use. RT ships with several themes by default:

web2 The totally new, default layout for RT 3.8
3.5-default RT 3.5 and 3.6 original layout
3.4-compat A 3.4 compatibility stylesheet to make RT look
(mostly) like 3.4

This value actually specifies a directory in share/html/NoAuth/css/ from which RT will try to load the file main.css (which should @import any other files the stylesheet needs). This allows you to easily and cleanly
create your own stylesheets to apply to RT. This option can be overridden by users in their preferences.

$UsernameFormat
This determines how user info is displayed. Concise will show one of either NickName, RealName, Name or EmailAddress, depending on what exists and whether the user is privileged or not. Verbose will show RealName and
EmailAddress.

$WebPath
If you're putting the web ui somewhere other than at the root of your server, you should set $WebPath to the path you'll be serving RT at.

$WebPath requires a leading / but no trailing /.

In most cases, you should leave $WebPath set to '' (an empty value).

$WebPort
If we're running as a superuser, run on port 80 Otherwise, pick a high port for this user.

$WebDomain
you know what domain name is, right? ;)

$WebBaseURL, $WebURL
This is the Scheme, server and port for constructing urls to webrt $WebBaseURL doesn't need a trailing /

$WebImagesURL
$WebImagesURL points to the base URL where RT can find its images. Define the directory name to be used for images in rt web documents.

$LogoURL
$LogoURL points to the URL of the RT logo displayed in the web UI

$WebNoAuthRegex
What portion of RT's URLspace should not require authentication.

$SelfServiceRegex
What portion of RT's URLspace should be accessible to Unprivileged users This does not override the redirect from /Ticket/Display.html to /SelfService/Display.html when Unprivileged users attempt to access ticked
displays

$MessageBoxWidth, $MessageBoxHeight
For message boxes, set the entry box width, height and what type of wrapping to use. These options can be overridden by users in their preferences.

Default width: 72, height: 15

These settings only apply to the non-RichText message box. See below for Rich Text settings.

$MessageBoxWrap
Default wrapping: "HARD" (choices "SOFT", "HARD")

$MessageBoxRichText
Should "rich text" editing be enabled? This option lets your users send html email messages from the web interface.

$MessageBoxRichTextHeight
Height of RichText javascript enabled editing boxes (in pixels)

$MessageBoxIncludeSignature
Should your user's signatures (from their Preferences page) be included in Comments and Replies

$WikiImplicitLinks
Support implicit links in WikiText custom fields? A true value causes InterCapped or ALLCAPS words in WikiText fields to automatically become links to searches for those words. If used on RTFM articles, it links to
the RTFM article with that name.

$TrustHTMLAttachments
if "TrustHTMLAttachments" is not defined, we will display them as text. This prevents malicious HTML and javascript from being sent in a request (although there is probably more to it than that)

$RedistributeAutoGeneratedMessages
Should RT redistribute correspondence that it identifies as machine generated? A true value will do so; setting this to '0' will cause no such messages to be redistributed. You can also use 'privileged' (the default),
which will redistribute only to privileged users. This helps to protect against malformed bounces and loops caused by autocreated requestors with bogus addresses.

$PreferRichText
If $PreferRichText is set to a true value, RT will show HTML/Rich text messages in preference to their plaintext alternatives. RT "scrubs" the html to show only a minimal subset of HTML to avoid possible contamination
by cross-site-scripting attacks.

$WebExternalAuth
If $WebExternalAuth is defined, RT will defer to the environment's REMOTE_USER variable.

$WebFallbackToInternalAuth
If $WebFallbackToInternalAuth is undefined, the user is allowed a chance of fallback to the login screen, even if REMOTE_USER failed.

$WebExternalGecos
$WebExternalGecos means to match 'gecos' field as the user identity); useful with mod_auth_pwcheck and IIS Integrated Windows logon.

$WebExternalAuto
$WebExternalAuto will create users under the same name as REMOTE_USER upon login, if it's missing in the Users table.

$AutoCreate
If $WebExternalAuto is true, $AutoCreate will be passed to User's Create method. Use it to set defaults, such as creating Unprivileged users with "{ Privileged =" 0 }> ( Must be a hashref of arguments )

$WebSessionClass
$WebSessionClass is the class you wish to use for managing Sessions. It defaults to use your SQL database, but if you are using MySQL 3.x and plans to use non-ascii Queue names, uncomment and add this line to
RT_SiteConfig.pm will prevent session corruption.

$AutoLogoff
By default, RT's user sessions persist until a user closes his or her browser. With the $AutoLogoff option you can setup session lifetime in minutes. A user will be logged out if he or she doesn't send any requests to
RT for the defined time.

$WebSecureCookies
By default, RT's session cookie isn't marked as "secure" Some web browsers will treat secure cookies more carefully than non-secure ones, being careful not to write them to disk, only send them over an SSL secured
connection and so on. To enable this behaviour, set $WebSecureCookies to a true value. NOTE: You probably don't want to turn this on _unless_ users are only connecting via SSL encrypted HTTP connections.

$WebFlushDbCacheEveryRequest
By default, RT clears its database cache after every page view. This ensures that you've always got the most current information when working in a multi-process (mod_perl or FastCGI) Environment Setting
$WebFlushDbCacheEveryRequest to '0' will turn this off, which will speed RT up a bit, at the expense of a tiny bit of data accuracy.

$MaxInlineBody
$MaxInlineBody is the maximum attachment size that we want to see inline when viewing a transaction. RT will inline any text if value is undefined or 0. This option can be overridden by users in their preferences.

$DefaultSummaryRows
$DefaultSummaryRows is default number of rows displayed in for search results on the frontpage.

$OldestTransactionsFirst
By default, RT shows newest transactions at the bottom of the ticket history page, if you want see them at the top set this to '0'. This option can be overridden by users in their preferences.

$ShowTransactionImages
By default, RT shows images attached to incoming (and outgoing) ticket updates inline. Set this variable to 0 if you'd like to disable that behaviour

$PlainTextPre
Normally plaintext attachments are displayed as HTML with line breaks preserved. This causes space- and tab-based formatting not to be displayed correctly. By setting $PlainTextPre they'll be displayed using <pre>
instead so such formatting works, but they'll use a monospaced font.

$ShowUnreadMessageNotifications
By default, RT will prompt users when there are new, unread messages on tickets they are viewing.

Set $ShowUnreadMessageNotifications to a false value to disable this feature.

$HomepageComponents
$HomepageComponents is an arrayref of allowed components on a user's customized homepage ("RT at a glance").

@MasonParameters
@MasonParameters is the list of parameters for the constructor of HTML::Mason's Apache or CGI Handler. This is normally only useful for debugging, eg. profiling individual components with:

use MasonX::Profiler; # available on CPAN
Set(@MasonParameters, (preamble => 'my $p = MasonX::Profiler->new($m, $r);'));

$DefaultSearchResultFormat
$DefaultSearchResultFormat is the default format for RT search results

$SuppressInlineTextFiles
If $SuppressInlineTextFiles is set to a true value, then uploaded text files (text-type attachments with file names) are prevented from being displayed in-line when viewing a ticket's history.

$DontSearchFileAttachments
If $DontSearchFileAttachments is set to a true value, then uploaded files (attachments with file names) are not searched during full-content ticket searches.

$ChartFont
The GD module (which RT uses for graphs) uses a builtin font that doesn't have full Unicode support. You can use a particular TrueType font by setting $ChartFont to the absolute path of that font. Your GD library must
have support for TrueType fonts to use this option.

@Active_MakeClicky
MakeClicky detects various formats of data in headers and email messages, and extends them with supporting links. By default, RT provides two formats:

* 'httpurl': detects http:// and https:// URLs and adds '[Open URL]'
link after the URL.

* 'httpurl_overwrite': also detects URLs as 'httpurl' format, but
replace URL with link and *adds spaces* into text if it's longer
then 30 chars. This allow browser to wrap long URLs and avoid
horizontal scrolling.

See share/html/Elements/MakeClicky for documentation on how to add your own.

$DefaultQueue
Use this to select the default queue name that will be used for creating new tickets. You may use either the queue's name or its ID. This only affects the queue selection boxes on the web interface.

</nowiki>

Net::Server (rt-server) Configuration

$StandaloneMinServers, $StandaloneMaxServers
The absolute minimum and maximum number of servers that will be created to handle requests. Having multiple servers means that serving a slow page will affect other users less.

$StandaloneMinSpareServers, $StandaloneMaxSpareServers
These next two options can be used to scale up and down the number of servers to adjust to load. These two options will respect the $StandaloneMinServers and "$StandaloneMaxServers options".

$StandaloneMaxRequests
This sets the absolute maximum number of requests a single server will serve. Setting this would be useful if, for example, memory usage slowly crawls up every hit.

%NetServerOptions
%NetServerOptions is a hash of additional options to use for "DEFAULT ARGUMENTS" in Net::Server. For example, you could set reverse_lookups to get the hostnames for all users with:

"Set(%NetServerOptions, (reverse_lookups =" 1));>

UTF-8 Configuration

@LexiconLanguages
An array that contains languages supported by RT's internationalization interface. Defaults to all *.po lexicons; setting it to "qw(en ja)" will make RT bilingual instead of multilingual, but will save some memory.

@EmailInputEncodings
An array that contains default encodings used to guess which charset an attachment uses if not specified. Must be recognized by Encode::Guess.

$EmailOutputEncoding
The charset for localized email. Must be recognized by Encode.

Date Handling Configuration

$DateTimeFormat
You can choose date and time format. See "Output formatters" section in perldoc lib/RT/Date.pm for more options. This option can be overridden by users in their preferences. Some examples:

"Set($DateTimeFormat, { Format =" 'ISO', Seconds => 0 });> "Set($DateTimeFormat, 'RFC2822');" "Set($DateTimeFormat, { Format =" 'RFC2822', Seconds => 0, DayOfWeek => 0 });>

$DateDayBeforeMonth
Set this to 1 if your local date convention looks like "dd/mm/yy" instead of "mm/dd/yy".

$AmbiguousDayInPast, $AmbiguousDayInFuture
Should an unspecified day or year in a date refer to a future or a past value? For example, should a date of "Tuesday" default to mean the date for next Tuesday or last Tuesday? Should the date "March 1" default to the
date for next March or last March?

Set $<AmbiguousDayInPast> for the last date, or $<$AmbiguousDayInFuture> for the next date.

The default is usually good.

Miscellaneous Configuration

@ActiveStatus, @InactiveStatus
You can define new statuses and even reorder existing statuses here. WARNING. DO NOT DELETE ANY OF THE DEFAULT STATUSES. If you do, RT will break horribly. The statuses you add must be no longer than 10 characters.

$LinkTransactionsRun1Scrip
RT-3.4 backward compatibility setting. Add/Delete Link used to record one transaction and run one scrip. Set this value to 1 if you want only one of the link transactions to have scrips run.

$StrictLinkACL
When this feature is enabled a user needs ModifyTicket rights on both tickets to link them together, otherwise he can have rights on either of them.

$PreviewScripMessages
Set $PreviewScripMessages to 1 if the scrips preview on the ticket reply page should include the content of the messages to be sent.

$UseTransactionBatch
Set $UseTransactionBatch to 1 to execute transactions in batches, such that a resolve and comment (for example) would happen simultaneously, instead of as two transactions, unaware of each others' existence.

@CustomFieldValuesSources
Set @CustomFieldValuesSources to a list of class names which extend RT::CustomFieldValues::External. This can be used to pull lists of custom field values from external sources at runtime.

$CanonicalizeRedirectURLs
Set $CanonicalizeRedirectURLs to 1 to use $"WebURL" when redirecting rather than the one we get from %ENV.

If you use RT behind a reverse proxy, you almost certainly want to enable this option.

$EnableReminders
Hide links/portlets related to Reminders by setting this to 0

Development Configuration

$DevelMode
RT comes with a "Development mode" setting. This setting, as a convenience for developers, turns on all sorts of development options that you most likely don't want in production:

* Turns off Mason's 'static_source' directive. By default, you can't
edit RT's web ui components on the fly and have RT magically pick up
your changes. (It's a big performance hit)

* More to come

Deprecated Options

$AlwaysUseBase64
Encode blobs as base64 in DB (?)

$TicketBaseURI
Base URI to tickets in this system; used when loading (?)

$UseCodeTickets
This option is exists for backwards compatibility. Don't use it.

Demo

2011-11-18T19:28:52Z

BillCole: Reverted edits by 109.247.144.131 (talk | block) to last version by BillCole

If you want to try RT, you can find demonstrations sites here: http://rt.easter-eggs.org/demos/.

Demo

2011-10-28T13:55:23Z

BillCole: Reverted edits by 82.207.170.50 (talk | block) to last version by BillCole

If you want to try RT, you can find demonstrations sites here: http://rt.easter-eggs.org/demos/.

ScripExecutionOrder

2011-10-20T19:23:15Z

BillCole: Content was flat-out wrong. Scrip execution is correctly documented by ScripExecOrder

#REDIRECT [[ScripExecOrder]]

ShowStatusInColor

2011-07-25T17:43:07Z

BillCole: Reverted edits by LissaLamb (talk | block) to last version by Best Practical

Colorize ticket links based on status or, as in one example below, by priority.

== RT 3.8.2 ==

=== Simple ===

Below is a modified local/html/Elements/ShowLink. It will display inter-ticket links colored to match the status of the ticket with the same color scheme used in graphs, via inline CSS. --Jerrad

<nowiki><a href="<%$URI->Resolver->HREF%>">
% if ($URI->IsLocal) {
% my $member = $URI->Object;
% if (UNIVERSAL::isa($member, "RT::Ticket")) {

#Customization
<%perl>
require RT::Graph::Tickets;
my $status = $member->Status;
my $class = $member->QueueObj->IsInactiveStatus($status)?'ticket-inactive':'';
my $color = $RT::Graph::Tickets::ticket_status_style{$status}->{'fontcolor'};
</%perl>
<span class="<% $class %>" style="color: <% $color %>">

<%$member->Id%>: (<%$member->OwnerObj->Name%>) <%$member->Subject%> [<% loc($member->Status) %>]
</span>

% } elsif ( UNIVERSAL::can($member, 'Name')) {
<%$URI->Resolver->AsString%>: <%$member->Name%>
% } else {
<%$URI->Resolver->AsString%>
% }
% } else {
<%$URI->Resolver->AsString%>
% }
</a>
<%ARGS>
$URI => undef
</%ARGS>
</nowiki>

=== Full-featured ===

by Dan Cook, updated with CSS callback dox by Matt Zagrabelny

This is how I've set things up. I have shamelessly robbed most of this from the posts above (Thanks Guys!).

(And Baylink, in turn, moved it to the top; if you're running older code, read on down. In particular, I modified the Colored-Priority code to use inline styles and reverse out the color into the background a bit further down.)

* Create the directory: <[[RTInstallationDir]]>/local/html/Callbacks/[[MyCallbacks]]/Elements/[[RT Ticket|RT__Ticket]]/[[ColumnMap]]

You can do that, in Linux, by typing

# mkdir -p local/html/Callbacks/[[MyCallbacks]]/Elements/[[RT Ticket|RT__Ticket]]/[[ColumnMap]]

from your RT installation directory, which is /opt/rt3 unless someone built it differently.

* Note: There are '''2 underscores''' between RT and Ticket

Then you can

# cd local/html/Callbacks/[[MyCallbacks]]/Elements/[[RT Ticket|RT__Ticket]]/[[ColumnMap]]

to create the file, which is '''also named''' [[ColumnMap]], and should contain this:

------8<-----------------------------8<----------

<%INIT>

sub statusInColor {
my $Ticket = shift;
my $status = $Ticket->Status;
my $css = "status" . lc $status;
my $LastUpdater = $Ticket->LastUpdatedByObj->EmailAddress;
my $TicketRequestors = $Ticket->Requestors->MemberEmailAddressesAsString;
my $TicketCC = $Ticket->Cc->MemberEmailAddressesAsString;

if (($TicketRequestors =~ $LastUpdater) || ($TicketCC =~ $LastUpdater))
{
$css = "status" . lc "reply";
$status = "<div class=\"$css\">$status REP</div>";
}
else {
$status = "<div class=\"$css\">$status</div>";
}

return \"$status";
}

$COLUMN_MAP->{Status}->{value} = \&statusInColor;

</%INIT>
<%ARGS>
$COLUMN_MAP => undef
</%ARGS>

------8<-----------------------------8<----------

* Onto the next part...
* RT 3.8 and up use a different CSS theme. Web2 is the default theme.
* If you use other themes you will need to do the following steps for each theme you use.
* Create the directory: <[[RTInstallationDir]]>/local/html/Callbacks/<[[SiteCallbacks]]>/[[NoAuth]]/css/web2/main.css
* Create the file: <[[RTInstallationDir]]>/local/html/Callbacks/<[[SiteCallbacks]]>/[[NoAuth]]/css/web2/main.css/End

And in that file, put:

@import "statuscolor.css";

* In the directory just created '<[[RTInstallationDir]]>/local/html/[[NoAuth]]/css/web2' you will need to create a new file.
* Name the file statuscolor.css and place the following content in it.

/* Status Colours */

.statusnew {
color: #bb0000;
text-align: left;
font-weight: bold;
}

.statusopen {
color: #0000bb;
text-align: left;
font-weight: bold;
}

.statusreply {
color: #00bb00;
text-align: left;
font-weight: bold;
}

.statusresolved {
color: #888888;
text-align: left;
font-weight: bold;
}

.statusrejected {
color: #884444;
text-align: left;
font-weight: bold;
}

* Don't forget to clear your Mason cache (apache restart, unless you've enabled $[[DevelMode]] in [[RT SiteConfig|RT_SiteConfig]].pm) and perform a "hard" refresh in your browser (Shift + Ctrl + R) to clear your local CSS cache.

So basically what you will get from the above is the status' listed in the statuscolor.css file will be colored. You may edit the statuscolor.css file to suit your needs. Just make sure you follow the convention of the file format i.e. to color status stalled you would use something like:

.statusstalled {

color: #884422;
text-align: left;
font-weight: bold;

}

and so on so forth. Next thing to note is that along with coloring the status this also puts an REP flag next to any tickets where the last reply is by the requestor or cc (i.e. not the staff) (Thanks Johan Baarman !)

----

== RT 3.8.x ==

==== Full featured ColumnMap script ====

by Alex Young

Confirmed working with 3.8.2, 3.8.6, 3.8.8.

I have combined the scripts on this wiki page to work in 3.8.x, so thanks to all the people that did all the hard work! Only the [[ColumnMap]] file is different from the other guides on this page.

Changes from the other scripts

* Changes REP flag to New Reply.
* Doesn't display New Reply when the current user is the last to comment.
* New Reply tag is displayed in its own colour, while keeping the default status colours.
* New Reply tag links to the last unread message and can mark the messages as read.
* New Reply tag isn't displayed if there are no unread messages.
* Changed colours for Priorities. Removed light colours that prevented the text from being easily read on a white background.
* Updated Extended Status code to display number of pending tickets.

This uses the statuscolor.css file found elsewhere on this page. Follow those instructions for setup.

The files should map to your system like so:

<RTInstallationDir>/local/html/
`-- MyCallbacks
|-- Elements
| `-- RT__Ticket
| `-- ColumnMap
| `-- ColumnMap
`-- NoAuth
`-- css
`-- web2
`-- main.css
`-- End
<RTInstallationDir>/local/html/
`-- NoAuth/
`-- css
`-- web2
`-- statuscolor.css

Here's the complete <RTInstallationDir>/local/html/Callbacks/MyCallbacks/Elements/RT__Ticket/ColumnMap/[[ColumnMap]] script.

<nowiki><%INIT>

# Show status in colour.
sub statusInColor {
my $Ticket = shift;
my $status = $Ticket->Status;
my $css = "status" . lc $status;
my $cssreply = "status" . lc "reply";
my $LastUpdater = $Ticket->LastUpdatedByObj->EmailAddress;
my $TicketRequestors = $Ticket->Requestors->MemberEmailAddressesAsString;
my $TicketCC = $Ticket->Cc->MemberEmailAddressesAsString;
my $CurrentUser = $session{'CurrentUser'}->EmailAddress;

# Added $CurentUser ne $LastUpdater to prevent showing New Reply tag when the last updater is the current user.
if (($CurrentUser ne $LastUpdater) && ($TicketRequestors =~ $LastUpdater) || ($TicketCC =~ $LastUpdater))
{
my $txn = $Ticket->SeenUpTo or return \"<div class=\"$css\">$status</div>";
# my $TicketLink = RT->Config->Get('WebPath') ."/Ticket/Display.html?id=". $Ticket->id. "#txn-".$txn->id;
# Comment out the line above and uncomment the following line to mark posts as seen when following link.
my $TicketLink = RT->Config->Get('WebPath') ."/Ticket/Display.html?id=". $Ticket->id ."&MarkAsSeen=1". "#txn-".$txn->id;
$status = "<div class=\"$css\">$status <a href=\"$TicketLink\"><span class=\"$cssreply\">New Reply</span></a></div>";
}
else {
$status = "<div class=\"$css\">$status</div>";
}

return \"$status";

}

# Show extended status in colour. This will change the front page and other search pages where the ExtendedStatus is displayed.
sub extStatusInColor {
my $Ticket = shift;
if ( my $count = $Ticket->HasUnresolvedDependencies ) {
my $status;

if ( $Ticket->HasUnresolvedDependencies( Type => 'approval' )
or $Ticket->HasUnresolvedDependencies( Type => 'code' ) ) {
$status = "<em>" . loc('(pending approval)') . "</em>";
} else {
$status = "<em>" . loc('(pending [quant,_1,other ticket])',$count) . "</em>";
}
return \$status;
} else {
return statusInColor($Ticket);

}
}

# Set the priority numbers to a colour.
sub PriorityInColor {
my $Ticket = shift;

my $priority = $Ticket->Priority;
my $colors = undef;

# Change priority numbers to reflect your priority system.
if ($priority >= '50') {
$colors = "#FF0000";
} elsif ($priority >= '45') {
$colors = "#FF2000";
} elsif ($priority >= '40') {
$colors = "#FF4000";
} elsif ($priority >= '35') {
$colors = "#FF6A00";
} elsif ($priority >= '30') {
$colors = "#FF6600";
} elsif ($priority >= '25') {
$colors = "#FFA000";
} elsif ($priority >= '20') {
$colors = "#0033CC";
} elsif ($priority >= '15') {
$colors = "#809FFE";
} elsif ($priority >= '10') {
$colors = "#004600";
} elsif ($priority >= '5') {
$colors = "#006400";
} elsif ($priority >= '0') {
$colors = "#009000";
}

if ($colors) {
$priority = "<div style=\"color: $colors;\">$priority</div>"
}

return \"<b>$priority</b>";
}

# Comment out any line to disable colour change.
$COLUMN_MAP->{Priority}->{value} = \&PriorityInColor;
$COLUMN_MAP->{Status}->{value} = \&statusInColor;
$COLUMN_MAP->{ExtendedStatus}->{value} = \&extStatusInColor;

</%INIT>
<%ARGS>
$COLUMN_MAP => undef
</%ARGS>
</nowiki>

----

=== Earlier forms ===

* Tested and works in RT 3.2.x
* Results in a a reference error in 3.2.2
* Error in 3.4.1 - http://lists.bestpractical.com/pipermail/rt-users/2005-May/030943.html
* Works in 3.4.2, small change needed - http://lists.bestpractical.com/pipermail/rt-users/2005-August/033080.html
* Works in 3.6.1, added localization support (2007/5/11)
* Changes for 3.6.5, see below (2008/2/5)
* Working as below in 3.8.2 - 2009-Feb-12 Baylink

(Baylink reads further down... wow. Everyone else already did this. :-)

Simply do the following:

* Create the directory: <[[RTInstallationDir]]>/local/html/Callbacks/[[MyCallbacks]]/Elements/[[RT Ticket|RT__Ticket]]/[[ColumnMap]]
* Put the contents of the following file into the file: <[[RTInstallationDir]]>/local/html/Callbacks/[[MyCallbacks]]/Elements/[[RT Ticket|RT__Ticket]]/[[ColumnMap]]/[[ColumnMap]]

Note: in debian the right path is /usr/local/share/request-tracker3.6/html/Callbacks/[[MyCallbacks]]/Elements/[[RT Ticket|RT__Ticket]]/[[ColumnMap]]/[[ColumnMap]]

----

<%INIT>

sub statusInColor {
my $Ticket = shift;
my $status = $Ticket->Status;
my $color = undef;

if ($status eq 'new') {
$color = "900000";
} elsif ($status eq 'open') {
$color = "#AA8000";
} elsif ($status eq 'stalled') {
$color = "#000090";
} elsif ($status eq 'rejected') {
$color = "#999999";
} elsif ($status eq 'resolved') {
$color = "009000";
}

$status = loc($status);

if ( $Ticket->HasUnresolvedDependencies ) {
$status = "<i>$status<i>"
}

if ($color) {
$status = "<font color=$color>$status</font>"
}

return \"<b>$status</b>";
}

sub extStatusInColor {
my $Ticket = shift;

if ( $Ticket->HasUnresolvedDependencies ) {
my $status;
if ( $Ticket->HasUnresolvedDependencies( Type => 'approval' )
or $Ticket->HasUnresolvedDependencies( Type => 'code' ) ) {
$status = "<em>" . loc('(pending approval)') . "</em>";
} else {
$status = "<em>" . loc('(pending other Collection)') . "</em>";
}
return \$status;
} else {
return statusInColor($Ticket);
}
}

$COLUMN_MAP->{Status}->{value} = \&statusInColor;
$COLUMN_MAP->{ExtendedStatus}->{value} = \&extStatusInColor;

</%INIT>
<%ARGS>
$COLUMN_MAP => undef
</%ARGS>

===== Priority color =====

by Riccardo Capecchi

My users wanted also the priority coloured in shade of red and yellow based on priority (red = big problem), i used the above code and added these lines to show a coloured field priority. You must add these lines with or without the above code into the file: <[[RTInstallationDir]]>/local/html/Callbacks/[[MyCallbacks]]/Elements/[[RT Ticket|RT__Ticket]]/[[ColumnMap]]/[[ColumnMap]]

edit: $priority is an integer, not a string. I've used >= operator instead of ge operator.

----

sub PriorityInColor {
my $Ticket = shift;

my $priority = $Ticket->Priority;
my $colors = undef;

if ($priority >= 90) {
$colors = "#FF0000";
} elsif ($priority >= 80) {
$colors = "#FF2000";
} elsif ($priority >= 70) {
$colors = "#FF4000";
} elsif ($priority >= 60) {
$colors = "#FF6000";
} elsif ($priority >= 50) {
$colors = "#FF8000";
} elsif ($priority >= 40) {
$colors = "#FFA000";
} elsif ($priority >= 30) {
$colors = "#FFC000";
} elsif ($priority >= 20) {
$colors = "#FFE000";
} elsif ($priority >= 10) {
$colors = "#FFFF00";
} elsif ($priority >= 0) {
$colors = "009000";
}

if ($colors) {
$priority = "<font style=\"color:black;background-color:$colors\">&nbsp;$priority&nbsp;</font>"
}

return \"<b>$priority</b>";
}
$COLUMN_MAP->{Priority}->{value} = \&PriorityInColor;

(This one also works in 3.8.2 as of 2009-Feb-12; I've modified it slightly to colorize the '''background''', and also to use inline CSS instead of deprecated tags. If you use both, put this one '''inside''' the other one's %INIT tags. --Baylink)

==== Using CSS For Styling ====

by Graham Briggs

As an alternative to the above, you might choose to use CSS to define styling of the Status field. I have the following setup:

In file $RT_HOME/local/html/Callbacks/[[MyCallbacks]]/Elements/[[RT Ticket|RT__Ticket]]/[[ColumnMap]]/[[ColumnMap]] replace the above status[[InColor]] method with the following:

sub statusInColor {
my $Ticket = shift;
my $status = $Ticket->Status;
my $css = "status" . lc $status;
$css =~ s/[\W]//g;

if ( $Ticket->HasUnresolvedDependencies ) {
$status = "<i>$status<i>";
}

$status = "<div class=\"$css\">$status</div>";

return \"$status";
}

In file $RT_HOME/local/html/Callbacks/[[MyCallbacks]]/[[NoAuth]]/webrt.css/Default

/* Status Colours */

.statusnew {
color: #bb0000;
text-align: center;
font-weight: bold;
}

.statusopen {
color: #0000bb;
text-align: center;
font-weight: bold;
}

.statustesting {
color: #00bb00;
text-align: center;
font-weight: bold;
}

.statusresolved {
color: #888888;
text-align: center;
font-weight: bold;
}

.statusrejected {
color: #884444;
text-align: center;
font-weight: bold;
}

== RT 3.6.5 (and up?) ==

Thanks Johan Baarman for the solution.

The problem with newer version is that the CSS file is not read from the directory mentioned above. Follow the steps below to solve it:

Create a directory $RT_HOME/local/html/[[NoAuth]]/css/3.5-default/ and copy $RT_HOME/share/html/[[NoAuth]]/css/3.5-default/main.css to it. Now edit the local main.css file and add the following line at the end: import "statuscolor.css"; Create a new local file $RT_HOME/local/html/[[NoAuth]]/css/3.5-default/statuscolor.css and populate it with the above css tags. I've also changed the .statustesting above to .statusreply in my statuscolor.css file in order to color replies.

In addition to coloring the status, the following alternative status[[InColor]] function will set a "REP" flag for each status to indicate a ticket that had been updated by anyone else than the staff, i.e. requestor or any of the [[CCs]], in case any of the users are colorblind.

sub statusInColor {
my $Ticket = shift;
my $status = $Ticket->Status;
my $css = "status" . lc $status;
my $LastUpdater = $Ticket->LastUpdatedByObj->EmailAddress;
my $TicketRequestors = $Ticket->Requestors->MemberEmailAddressesAsString;
my $TicketCC = $Ticket->Cc->MemberEmailAddressesAsString;

if (($TicketRequestors =~ $LastUpdater) || ($TicketCC =~ $LastUpdater))
{
$css = "status" . lc "reply";
$status = "<div class=\"$css\">$status REP</div>";
}
else {
$status = "<div class=\"$css\">$status</div>";
}

return \"$status";
}

Demo

2011-06-21T17:03:52Z

BillCole: Reverted edits by 161.148.171.9 (talk | block) to last version by BillCole

If you want to try RT, you can find demonstrations sites here: http://rt.easter-eggs.org/demos/.

Demo

2011-06-11T04:20:25Z

BillCole: Undo revision 6356 by 69.169.190.15 (talk)

If you want to try RT, you can find demonstrations sites here: http://rt.easter-eggs.org/demos/.

Demo

2011-06-11T04:18:02Z

BillCole: Reverted edits by 88.207.2.225 (talk | block) to last version by 69.169.190.15

If you want to try RT, you can find demonstrations sites here: http://rt.easter-eggs.org/demos/.
[[Category:sdfsdfas]]

Demo

2011-06-05T22:16:01Z

BillCole: Cleaning up addition of nonexistent categories

If you want to try RT, you can find demonstrations sites here: http://rt.easter-eggs.org/demos/.

Demo

2011-06-05T22:14:22Z

BillCole: Reverted edits by 190.182.71.115 (talk | block) to last version by 122.183.221.42

If you want to try RT, you can find demonstrations sites here: http://rt.easter-eggs.org/demos/.
[[Category:FirstCategory]]
[[Category:Second Category]]

HomePage

2011-06-02T03:30:33Z

BillCole: Reverted edits by Helenhall (talk | block) to last version by BillCole

== RT ==

RT is an open source issue tracking and workflow platform. This wiki site is a free resource for RT users. RT doesn't come with a formal formatted users or administrators guide, but it's likely most of what you need to know to use and run it is contained somewhere within this wiki, so look around a little, be patient... and try not to install RT on a Sunday night when you need to run it in production on Monday: it's '''big''', and learning how to set it up can take some time.

Please: [[UpdateTheWiki]], post your hints, tricks, tips and tools about how to get the most out of RT. If you currently use RT, please head over to [[RTUsers]] and add yourself and your organization to the user list.

== Announcements ==

=== Production Releases ===

* [http://blog.bestpractical.com/2011/04/rt-400-released.html RT 4.0.0 released]
* [http://blog.bestpractical.com/2011/04/security-vulnerabilities-in-rt.html Security vulnerabilities in RT]

=== Development Releases and Status ===

* [http://blog.bestpractical.com/2010/09/rt-4-an-update.html RT 4 - An update.]
* [http://blog.bestpractical.com/2010/09/rt-394-first-development-release-leading-to-rt-400.html RT 3.9.4 - first development release leading to RT 4.0.0.]
* [http://blog.bestpractical.com/2010/09/rtir-260-release-candidate-1.html RTIR 2.6.0 Release Candidate 1.]

[http://blog.bestpractical.com/announcements/ Other Announcements from Best Practical.]

(Note: the newest versions of RTFM and RTIR require a fairly new version of RT as well, if not the absolute newest; be careful which versions you're using.)

== Sections ==

You can go through these pretty much in order if you're starting from scratch, but please plan to spend some quality time with the [[UserManual]] before you try to go live; RT is big and hairy, and you probably can't get your head around all of it in one sitting.

* [[FAQ]], [[FindingAnswersAboutRT]] and "Common Problems" below.
* [[BugReporting]]
* [[HowToHelp]], [[Translation]]
* [[Demo]]
* [[UserManual]], [[RTGlossary]] & [[Documentation]]
* [[InstallationGuides]], [[RTTutorials]]
* [[RT Config|RT_Config]] & [[RT SiteConfig|RT_SiteConfig]]

* [[Extensions]] to RT available as installable plugins
* [[Contributions]] by the community to customize RT
* [[RTIR]] RT for Incident Response
* [[RTFM]] RT FAQ Manager

* [[RTHistory]]
* [[InThePress]]
* [[REST]] API
* Customizing with [[CustomizingWithCallbacks|Callbacks]]

=== Common problems ===

* [[CantLocateObject]] - Can't locate object method "new" via package "<code>RT::Handle</code>" at rt3/lib/RT.pm
* [[NoConnectionToSyslog]] - no connection to syslog
* [[NoRecipFound]] - No recipients found. Not sending
* Getting information out of RT3 for [[reporting]] or inclusion elsewhere.
* [[PermissionDenied]] emails|

== Wish lists ==

* [[WikiWishList]] - wish list for this wiki
* [[WishList]] - wish list for the RT
* [[RT3StatisticsPackageWishList]]

__NOTOC__

HomePage

2011-05-25T16:35:50Z

BillCole: Reverted edits by Allensmith (talk | block) to last version by Jibsheet

RT 3.999 Jifty Experimental

2011-05-12T05:32:29Z

BillCole: RT4 ain't what it used to be...

= '''THIS PAGE DESCRIBES THE FORMER PLANS FOR RT4. THE RT4 RELEASED IN EARLY 2011 IS A MORE EVOLUTIONARY ADVANCEMENT OF RT3.8''' =
= RT4 =

RT4 is a major effort to update and modernize the RT codebase, making it easier to add new features and to customize existing features.

The major new features users should expect in RT 4.0.0 are a replacement for the Scrips system and a new ticket lifecycle engine.

Once released, the application will be known as "RT 4.0" or "Request Tracker 4.0"

= Source code =

The code is accessible with Git:

git clone git://github.com/bestpractical/rt.git
git checkout 3.999-trunk

A web-based browser for the code is available at:

http://github.com/bestpractical/rt/tree/3.999-trunk

= Get RT 4 up and running =

== Prerequisites ==

RT 4 is bleeding edge and requires up-to-date versions of:

* Jifty (0.90701)
* Jifty DBI (SVN)
* Lorzy (SVN)

== Installation ==

The installation isn't yet supported. You can use it right from checkout of code.

== Running ==

Just run "jifty server" from the toplevel source directory.

= Status =

RT4 is currently in active development. [[APIs]] are subject to change. Features are subject to removal or backwards-incompatible change with no notice. <u>*DO NOT USE RT4 IN PRODUCTION*</u>

= Work to date =

* RT has been ported to the Jifty web framework
* RT's API has been partially rototilled to meet more modern naming guidelines
* The porting and rototilling has incorporated changes from RT through version 3.8.1
* The rights "delegation" system has been removed.
* A new "Status schemas" system has been introduced to allow customized issue lifecycles.

= Completed work for 4.0 alpha 1 (Target date: 15 February 2009) =

* Merge of RT 3.8.2 to RT4 ([[sunnavy]])
* [[StatusSchemas]] ([[RuslanZakirov]])
* Role groups on demand ([[RuslanZakirov]])
* switch to the [[DateTime]] modules ([[Sartak]])

= Upcoming work for 4.0 alpha 1 (Target date: 15 February 2009) =

* Replacement of Scrips with the /lorzy/ workflow engine [[clkao]] - in progress
* Update of administrative ui to use TD/Jifty::Actions
* Full text search ([[RuslanZakirov]]) - in progress
* RT 3.8 -> 4.0 migration tool ([[sunnavy]], [[RuslanZakirov]]) - in progress

= Upcoming work for 4.0 alpha 2 (Target date: 1 April 2009) =

* Replace ticket display/edit/update widgets with Jifty::Action based webforms
* Oracle port (will require small improvements to Jifty)

= Upcoming work for 4.0 alpha 3 (Target date: 15 May 2009) =

= Upcoming work for 4.0 beta 1 =

= Wish List =

[[RT4WishList]]

= See also: =

[[RT4SchemaChanges]]

Rights

2011-04-06T08:16:53Z

BillCole: Reverted edits by 74.55.175.27 (talk | block) to last version by BillCole

This article describes RT security management aspects.

= Introduction =

== Groups ==

RT has different types of [[Group]]s that identify specific groups of system users. For security management, the public (user-defined) groups are the most important.

== Objects ==

RT manipulates different objects: [[Ticket]]s, [[Queue]]s, [[Scrip]]s, [[Template]]s, [[CustomField]]s, Users, [[Group]]s, etc. Each object takes a different place in the object tree. For example, scripts can either be global- or queue-specific, but tickets are always associated with a queue. Each object has a set of defined rights. To perform a particular action on an object, a user must have the appropriate rights. For example, if you want create a ticket in queue A, you should have the [[CreateTicket]] right on queue A (or on all queues). Other types of rights, such as [[AdminGroup]], are not queue-specific.

In general, it is possible to grant each user rights on each small object like a scrip named 'foo' or a Template named 'bar.' But, such a setup would be difficult to maintain, and would require an overly-complex user interface. Instead, the RT user interface gives access to rights that are '''system-wide''', rights that can be assigned on a '''group by group''' basis, and other rights that can be assigned on a '''queue by queue''' basis. All objects have a context. For example, if Scrip A is a global scrip (system-wide), you can grant users rights on this object in the global context. Each right can be tied to more then one context and the interpretation of the right can be different in the different contexts. For example, the [[AdminQueue]] right in two different queues can be given to different groups of users.

'''Note''': I forgot about rights that change behavior in different contexts when I started all this. Maybe I'll recheck this all. Feel free to change descriptions if you <u>know</u> the real situation. --Ruslan

= Descriptions =

* [[QueueSpecificRights]]
* [[GroupSpecificRights]]
* [[GlobalRights]](with full index)

= Working schemas =

This chapter introduces several working schemas which can be used as template in different situations.

== Public support queue ==

Let start from the beginning. We have recently created queue 'support' that is for our public queue and group 'SupportTeam' of which members support our customers. Goto 'Configuration' tab -> '[[Queue]]s' -> 'support' -> '[[Group]] rights' - it's the place where we'll do all the things that are described below. Then follow the step by step descriptions:

* We should grant all users with [[CreateTicket]] on queue 'support'.
* '''Important:''' It's a public queue and users often use different email addresses to reply to same ticket, so if you don't grant [[Everyone]] with [[ReplyToTicket]] right then your users would have problems in such a case.
* You don't need grant other system [[Group]]s with same rights because [[Everyone]] includes all users.
* If some of your internal groups shouldn't have [[ReplyToTicket]] right, then you can assign it to [[Unprivileged]] and some internal groups.

* If you wish to allow public access to the Web UI([[SelfService]]) then you will also want the following rights to be granted to [[Everyone]] [[Group]]:
*# [[SeeQueue]] that allows them to see queue 'support' in select boxes('create ticket in' box, 'search criteria' box and etc).
*# [[ShowTicket]], without this right users can't see tickets in Web UI, but can reply with email. Below we'll see when we don't need this right granted to [[Everyone]].

* Your customers are [[Requestor]]s so grant requestor role with rights:
*# [[ReplyToTicket]]
*# [[ShowTicket]], it's an overhead grant but if we revoke this right from [[Everyone]] some day then requestors still would have ability to see tickets which they had request. Now, with one right([[ShowTicket]] for [[Group]] [[Everyone]]) you can control requestor's ability to see other's requests.

* Scroll to group 'SupportTeam' and grant the following rights:
*# [[SeeQueue]], [[ShowTicket]] same reasons as for group [[Everyone]].
*# [[OwnTicket]], each support team member works only on their own tickets. It's an advantage that RT has over IMAP folders used for public support. Your workers don't spend their time answering the same ticket.
*# [[TakeTicket]], allows group members to take ticket from nobody.
*# [[DeleteTicket]], your public support queue can't live without it in most cases because of spam.

* Now we can use Roles to grant owners with remaining rights. Scroll to Owner role and grant:
*# [[ModifyTicket]], this allows much, see right description, but you need this for ticket status change.

=== Trick with comments ===

RT has comments which allow internal teams disscussion inlined into ticket's body. Grant rights [[ShowTicketComments]] and [[CommentOnTicket]] to 'SupportTeam' [[Group]] and to other groups who can help support team in different cases(for eg 'DevelopmentTeam').

=== Tricks with [CC]s/[AdminCC]s ===

Sometimes it's necessary to watch others' tickets. For example there is now discussion on a problem in some ticket and a worker has their own requests with similar problem then it would be good to watch on that ticket and do other job until it is resolved. Grant support team with [[Watch]] right.

Also you can consider next schema with watchers: Customer sends request. Supporter can't resolve problem(unknown yet) on his own. He does standard things(request for more info, report with spec tool and so on from user), when supporter thinks that user has provided all needed info, he comments on ticket and at the same time adds developer as [[CC]].

Special [[CustomField]] where supporter can setup value which means "awaiting reply from developer" helps a lot too, because developer can search all tickets where he is watcher and ticket wait for his reply/comment. This CF can be filled with other useful ticket states.

[[AdminCC]]s can have more rights, for example reply directly to user with correspondence or modify ticket. It can be other teams who know standard reply forms and can solve particular problems or this role can be given to support department managers. If necessary grant [[Group]]s with [[WatchAsAdminCc]] right.

== Departments of a company as groups ==

[[Group]]s page describe simple example of using groups to manage rights of the stuffs who work in different departments in your company. Let's build more complex and universal variant.

Split your privileged users with top level groups: one for your full time staffs, one for part time and on for privileged clients. '''Don't skip this step''' even if you think all your clients would be unprivileged, once when you will need this it would be able to do in one or two clicks instead of refactoring whole rights schema. This groups could be:

* Team
* External team(part time)
* Clients
* ...add your own

When you have created top level groups you can add groups and users to it, but don't hurry to add users, read more and you will understand that it's better to add user to one particular group. Create group for each department, may be you don't have "strict" departments in your company, but anyway usually people do different tasks: managers, developers, support, sales, PR... This people should see only that info that does make sense for them and helps them do thier job effectively, they shouldn't fill special search conditions to hide tickets that they don't ever want to see. This groups could be:

* DevelopmentTeam
* SupportTeam
* SalesTeam
* ...add your own

Department groups should be member of the "Team" top-level group. This allow you to grant all in your team with particular set of rights. If you don't add department group to the top-level group, then you have to add your new users into two groups at least to mark that user is a team member and works in specific department.

For example RT can be used as mailing list, you just create "internal" queue and use it as internal discussions forum. In this situation "team" group will help you to grant rights on the queue easy. You can use RT-Action-[[NotifyGroup]] module to make this queue looks more like mailing list, you should setup scrip that will notify group 'Team' on any transaction(or some particular transactions if you want).

Department managers usually should be able to do more with department's tickets than other members. Create new groups for managers as members of the departments groups, so your managers would be able to do everything other in department could do, but also you'd be able to grant them additional rights. Additional group for manager(s) allow you to change managers easy, for example if you change manager in XX department then you just disable old manager account or move it to other group and add another user into group and this is all you need to do, you don't need to assign any rights or revoke.

You can notify managers about special events with RT-Action-[[NotifyGroup]] module. For example you can build next workflow: if owner of the ticket is member of the "[[SupportTeam]]" and transaction is correspond notify members of the "[[SupportManagers]]" with template "reply for managers", this template could collect additional info like time gone since last user message, manager(s) get such messages and could control that support team reply to all customers in 48 hours period(or whatever period you use).

Grant your managers with [[DelegateRights]] and [[AdminOwnPersonalGroups]] right, this will allow them to delegate their responsibilities to other users when it's required.

To summarize all thoughts here is example of the groups tree:

* [[Everyone]]
** [[Unprivileged]]
** [[Privileged]]

*** Team(group)
**** SupportTeam(group)
***** team member(user)
***** team member(user)
***** team member(user)
***** ...
***** SupportManagers(group)
****** manager(user)
****** manager(user)
****** ...

**** DevelopmentTeam(group)
***** team member(user)
***** team member(user)
***** team member(user)
***** ...
***** DevelopmentManagers(group)
****** manager(user)
****** manager(user)
****** ...

*** ExternalTeam
*** Clients

= Appendix =

== Glossary ==

Some terms and acronyms which you could meet in this and other articles you can find descriptions for them in [[RTGlossary]]

== Contributors ==

* [[RobHooft]] - cleanups, corrector, original [[SeeQueue]] right description
* Imak - minor spelling cleanup
* [[RuslanZakirov]]

== Epilogue ==

We hope this small article can help you understand concepts which are used in RT to manage user's rights. Feel free to fix spelling, grammar and other glitches and of course add your own solutions and ideas. Good luck.

Rights

2011-03-03T17:36:37Z

BillCole: Reverted edits by 174.37.16.81 (talk | block) to last version by BillCole

Extensions

2011-02-28T21:11:15Z

BillCole: Reverted edits by 112.203.36.64 (talk | block) to last version by BillCole

= Nota Bene =

The Best Practical website now contains a list of standard and known-maintained extensions at http://bestpractical.com/rt/extensions.html. If you know of a maintained extension that doesn't show up there, send mail to webmaster at bestpractical.com.

= Introduction =

Here is a list of RT extensions packaged and available from CPAN or other places.

Most of these extensions are prepared with Module::Install::[[RTx]] module, which allows you to package extension easily and quickly. People who would like to package their extensions should read the module's [http://search.cpan.org/dist/Module-Install-RTx/ documentation].

= Help maintain this page =

Please sort and refactor this list; RT::Extension is a verbose but lexigraphically equivalent form of [[RTx]]. Also note, that links to a particular version of a module on search.cpan may rot when later versions are released, used a perldoc query instead.

= List =

== Asset Tracker ==

* [[AssetTracker]]

== Command by email ==

[http://search.cpan.org/dist/RT-Extension-CommandByMail RT::Extension::CommandByMail] allows you to change metadata of ticket via email:

* [http://search.cpan.org/dist/RT-Extension-CommandByMail/README Supported commands]
* [http://search.cpan.org/dist/RT-Extension-CommandByMail/lib/RT/Extension/CommandByMail.pm Overview]
* [http://search.cpan.org/dist/RT-Extension-CommandByMail/INSTALL Installation instructions]
* requires '''patching''' on [[RTs]] older than 3.6, but works out of the box on modern RT
* Authors: Best Practical
* See also: Extract Custom Field Values

== Extract Custom Field Values ==

Allows to extract CF values from email headers or body.

* [http://search.cpan.org/dist/RT-Extension-ExtractCustomFieldValues/lib/RT/Extension/ExtractCustomFieldValues.pm Overview]
* See also: [[ExtractCustomFieldValues]] and Command by email

== Rights Matrix ==

* [http://search.cpan.org/dist/RTx-RightsMatrix/ Extension root]

== Shredder ==

[http://search.cpan.org/dist/RTx-Shredder/ RTx::Shredder] by [[RuslanZakirov]]

* Version 0.01_01 is the latest that supports RT-3.0.x
* RT 3.2.x is '''unsupported'''
* Versions >= 0.02 works with RT 3.4.x and greater, 3.4.1 requires '''patching'''
* Included in 3.8.x

== Notify users/groups ==

Part of RT 3.8

Helps setup and manage scrip actions that allow you to notify particular groups of users.

* [http://search.cpan.org/dist/RT-Action-NotifyGroup Extension root]

See also [[EmailGroup]]

== External Authentication ==

[http://wiki.bestpractical.com/view/ExternalAuth RT::Authen::ExternalAuth] by [[MikePeachey]]

Allows authentication from any LDAP or DBI-supported data source. Also allows the use of a browser cookie to implement Single Sign-On with other web code using a DBI authentication backend.

For RT-3.8.x

* [http://search.cpan.org/~zordrak/RT-Authen-ExternalAuth-0.08/ RT::Authen::ExternalAuth v0.08]

For RT-3.6.x ('''unsupported''')

* [http://search.cpan.org/~zordrak/RT-Authen-ExternalAuth-0.05/ RT::Authen::ExternalAuth v0.05]
* [http://search.cpan.org/~zordrak/RT-Authen-CookieAuth-0.02/ RT::Authen::CookieAuth v0.02]

== Export search results as XLS ==

This RT Extension allow users to download search results in Microsoft Excel binary format. This typically fix encoding problems for non-ascii chars with the standard TSV export included in RT. [http://search.cpan.org/dist/RT-Extension-SearchResults-XLS/ Extension root]

== Watched queues ==

This RT Extension allow to display the list of queues the user is watcher, in the user configuration tab. [http://search.cpan.org/dist/RT-Extension-WatchedQueue/ Extension root]

== Toggle SuperUser right on/off with a link ==

This RT Extension allow users with [[SuperUser]] right to quickly enable/disable this right with a simple link at the top of each page. This way, they can work like standard users for day to day usage and enable [[SuperUser]] right only when needed. [http://search.cpan.org/dist/RT-Extension-ToggleSuperUser/ Extension root]

== Mandatory subject ==

This RT Extension enforces users to fill the subject when creating a ticket via the web interface. [http://search.cpan.org/dist/RT-Extension-MandatorySubject/ Extension root]

== Mandatory requestor ==

This RT Extension enforces users to fill the requestor when creating a ticket via the web interface. [http://search.cpan.org/dist/RT-Extension-MandatoryRequestor/ Extension root]

== User details ==

This RT Extension allows to quickly display watchers personal details on a ticket. [http://search.cpan.org/dist/RT-Extension-UserDetails/ Extension root]

== Service Level Agreements (SLA) ==

This RT Extension enables the specification and usage of SLA's (Service Level Agreements).

[http://search.cpan.org/dist/RT-Extension-SLA/ RT::Extension::SLA] by [[RuslanZakirov]]

== Workflow Builder ==

This RT Extension is useful for creating Approvals and Workflows.

[http://search.cpan.org/dist/RTx-WorkflowBuilder/ RTx::WorkflowBuilder] by Chia-liang Kao

== Branded Queues ==

Integrated into RT 3.8, read UPGRADING and etc/upgrade/3.8-branded-queues-extension.

RT 3.2-3.6: This extension allows sites to "Brand" individual queues with distinct tokens in the Subject headers of outgoing email messages.

[http://search.cpan.org/dist/RT-Extension-BrandedQueues/ RT::Extension::BrandedQueues] by [[JesseVincent]]

== QuickCalls ==

Quickly create tickets in specific queues with default values [http://search.cpan.org/dist/RT-Extension-QuickCalls/lib/RT/Extension/QuickCalls.pm RT::Extension::QuickCalls] by [[JesseVincent]]

== Other ==

* [[RT3StatisticsPackage]]
** [[RT3StatisticsPackageTimeWorked]] - Generate a report of [[TimeWorked]] for the specified number of days.

* [http://search.cpan.org/dist/RT-OnlineDocs RT-OnlineDocs] - adds a "Developer Documentation" menu to the RT user interface.

* [http://search.cpan.org/dist/RT-Extension-ActivityReports/ RT::Extension::ActivityReports] [[ActivityReportsPostInstall|Adding to Menu]]

* [http://search.cpan.org/dist/RT-Extension-AddAdminCcsOnQueueChange/lib/RT/Extension/AddAdminCcsOnQueueChange.pm RT::Extension::AddAdminCcsOnQueueChange]

* [http://search.cpan.org/dist/RTx-BecomeUser/ RT::Extension::BecomeUser] - This extension for RT 3.6 provides an ability for super user to effectively log on any user in the system for debugging purposes
** [http://search.cpan.org/~jpierce/RTx-BecomeUser-1.10_3/ Unofficial update for 3.8]

* [http://search.cpan.org/dist/RT-BugTracker/ RT::BugTracker] - Adds a UI designed for bug-tracking for developers to RT

* [http://search.cpan.org/dist/RT-BugTracker-Public/ RT::BugTracker::Public] - Adds a public, (hopefully) userfriendly bug tracking UI to RT

* [http://search.cpan.org/dist/RTx-Calendar/ RTx::Calendar] - This extension for RT 3.6+ adds a calendar page, a calendar portlet and iCal feeds of all your tasks and reminers with due date.

* [http://search.cpan.org/dist/RTx-DDMU/ RTx::DDMU] - drop down menu user interface for RT (RT 3.5 or later)

* [http://search.cpan.org/dist/RTx-EmailCompletion/ RTx::EmailCompletion] - This extension uses javascript to add ajax completion on almost all email input field.

* [http://search.cpan.org/dist/RT-Extension-ExtractSubjectTagOnTransaction/ RT::Extension::ExtractSubjectTagOnTransaction]

* [http://search.cpan.org/dist/RTx-From/ RTx::From] - Makes it a bit easier to find users and their tickets.

* [http://search.cpan.org/dist/RT-Extension-MenubarSearches/ RT::Extension::MenubarSearches] - This simple extension for RT 3.x (Tested on 3.4 and newer) adds a dropdown of a user's queues into RT's menubar. Using a tiny bit of javascript, selecting one of these queues will automatically jump to a search showing new, open and stalled tickets in that queue.

* [http://search.cpan.org/dist/RT-Extension-MergeUsers/ RT::Extension::MergeUsers] - adds the ability combine users to via the User Administration page

* [http://search.cpan.org/dist/RT-Extension-QueueWizard/ RT::Extension::QueueWizard] - [[QueueWizard]] allows for fast creation of queues by cloning a pre-existing queue

* [http://search.cpan.org/dist/RT-Extension-rt_cpan_org/ RT::Extension::rt_cpan_org] - The customizations that turn a RT into a RT for rt.cpan.org

* [http://search.cpan.org/dist/RT-Extension-ServiceUpdates/ RT::Extension::ServiceUpdates] - Message of the Day(?)

* [http://search.cpan.org/dist/RTx-S3Invoker/ RTx::S3Invoker] - Allows one to load saved searches (global too!) via [[ManualSimpleSearch]].

* [http://search.cpan.org/dist/RTx-Tags/ RTx::Tags] - Provides functionality to [[ManualSimpleSearch]] custom fields, and a tag cloud (via HTML::TagCloud) of values in the CF Tags.

* [http://search.cpan.org/dist/RTx-Timeline/ RT::Extension::Timeline] - This extension for RT 3.6 uses Timeline http://simile.mit.edu/timeline/ to visualize RT tickets.
** Works in 3.8 with a tweak to /path/to/rt/share/html/Callbacks/Timeline/Ticket/Elements/Tabs/Default to change the tab index from 'j' to something else e.g; 't'. Otherwise, the Bulk Update tab is clobbered.

* [http://search.cpan.org/dist/RTx-WebCronTool/ RTx-WebCronTool] - web interface for the built-in "rt-crontool" utility, allowing scheduled processes to be launched remotely.

* [http://github.com/tbrumm/RT-Extension-SideBySideView RT-Extension-SideBySideView] - a moduled version of [http://wiki.bestpractical.com/view/SideBySideTicketScreen SideBySideTicketScreen] from Stephen Turner

* [http://github.com/tbrumm/RT-Extension-ShowRelations RT-Extension-ShowRelations] - is a Module for RT 3.6/3.8x to Display Ticket Relations as Table based on a Search

* [http://github.com/tbrumm/RT-Extension-FastGroupRights RT-Extension-FastGroupRights] - is a replacement for core [[GroupRights]] Pages with a faster Solution which not loads all available groups with their rights. It will only load the System Groups, Roles and User Defined Groups with already granted rights. Additional it offers a search Field to search for Groups to grant them rights. This is based on an Idea and Code from MIT (Stephen Turner)

* [http://github.com/tbrumm/RT-Extension-QueueDeactivatedScrips RT-Extension-QueueDeactivatedScrips] - is a moduled version of Dirk Pape's [http://page.mi.fu-berlin.de/dirkpape/rt3/HideGlobalScrips/ HideGlobalScrips]

addon for RT 3.6.x

== Writing your own extensions ==

* Homepage Components (Portlets): [[WritingPortlets]]

ManualRequirements

2011-02-19T19:19:02Z

BillCole: Reverted edits by 193.136.124.150 (talk | block) to last version by 12.43.88.121

Prev: [[ManualIntroduction]] --- Up: [[UserManual]] --- Next: [[ManualInstallation]]

= REQUIREMENTS =

RT is a fairly large, complex piece of software. It makes some (ok, '''lots''' of) assumptions about the environment in which it runs, which you will have to fulfill during installation.

If you're working with an already installed RT you don't need to know any of this now.

To properly install RT you'll need some things:

== Knowledge ==

* root access to the server you're going to install it on
* how to add aliases to your mail system
* how to start and stop your web server
* how your distribution mangles the webserver configuration files.

== Make choice ==

In installing an application as large and pervasive as RT, which depends on many other things, you will often have to make the decision "do I provide it a separate version of the thing it requires, or do I upgrade my system's facility to the proper, new-enough version?" This is a difficult question to answer in some cases, as it depends on the level of systems administration experience you have. We can't answer it for you but we'll attempt to make clear what effect the possible choice may have on how you install and run the package. See the Installation Guides - your distro may have a packaged version of RT.

== RT source code ==

The latest version is available at http://www.bestpractical.com/rt/download.html

== Perl ==

'''WARNING:''' For RT 3.0.0 and greater you need '''Perl 5.8.3 or newer'''. It contains significantly enhanced support for Unicode and non-English languages. Perl 5.8.3 fixed major bugs - using prior versions may cause data corruption. If your distribution uses an older Perl version, you can compile your own - see [[CompilingPerl]]. Or you can upgrade your system's version of perl.

Note that if you're using a packaged perl and a packaged Apache, you probably need to use your distribution's packaged Apache::DBI and mod_perl as well, and all of these need to be version compatible with RT -- it's vaguely possible this might mean you need to uninstall '''all''' of the managed packages and build these things from scratch... at which point you might want to reconsider which distribution you want to use.

If you will be running '''RT 3.0.x or earlier''' under FastCGI, you need support for setgid perl scripts. RT 3.2 and later do not need this. See details below and on the [[FastCGIConfiguration]] page. (There really isn't much reason to newly install a version that old, so that's all we'll say about this now.)

== Perl modules ==

If all of that sounds vague, don't worry: a tool included with RT takes care of the installation of most of these automatically (see [[ManualInstallation]]). The tool supplied with RT uses Perl's CPAN system (http://www.cpan.org) to install modules. Some operating systems package some or all of the modules required and you may be better off installing the modules that way.

And, finally, you might find that you'll need to mix these two approaches; on [[SuSE]] 10.3 for example, fixdeps will install everything except Apache::DBI.

Currently (April,2008 - RT 3.6.6) the dependency "HTML::[[FormatText]]" will not install due to a failure in a subdependency: "Font::AFM". The latter fails with a test result: t/afm.....skipped (no reason given). You will need to install this manually with CPAN using the command "force install Font::AFM". Afterwards, the "HTML::[[FormatText]]" module can be installed ok.

=== NCFTP ===

Some platforms, e.g. [[CentOS]] 4.x, will also require the freely available [[NcFTP]] Client (http://www.ncftp.com/ncftp/) in order to satisfy some configuration dependencies for the Perl CPAN system.

You can configure to avoid this requirement during the setup configuration of CPAN by telling the configuration dialog that there is no "ncftp" executable and then selecting only "http" CPAN Mirrors. This may also be advantageous if your system is behind a corporate firewall which does not allow FTP.

== Database backend ==

RT stores its data in a database. You can choose from the following database management systems (DBMS):

* We recommend [http://www.mysql.com MySQL] 4.0.18 or newer *with support for [[InnoDB]]*.
* [http://www.postgresql.org PostgreSQL] 7.4 or later will also work
* Oracle 9iR2 or newer

If your system already has a DBMS engine installed and working, you're probably best to use that one.

== Web server ==

We recommend using [http://httpd.apache.org Apache] version 2.x with [mod_perl] 2 or a webserver with [[FastCGI]] support.

=== mod_perl vs FastCGI ===

You '''don't need both''' mod_perl and [[FastCGI]], you have to install and configure only one thing. You should choose the software you're familiar with, but if you're not familiar with either, don't panic, here are short descriptions of both projects and how well each works with RT.

==== mod_perl ====

[mod_perl] project has two major stable releases: mod_perl 1.x and mod_perl 2.x; in the middle there is development versions mod_perl 1.9x. Let see which releases you can use:

* mod_perl 1.x is supported release, but this mean you '''must use Apache 1.3.x''', because mod_perl 1.x works only with Apache 1.3.x. mod_perl 1.x must be built with <code>EVERYTHING=1</code> option(most distribution packages have this option on). For an excerpt, see [[ManualApache]]. Using mod_perl with Apache 1.3.x could lead to massive stability problems.

* We '''don't recommend''' to use development 1.9x versions, because of development status. Also mod_perl 2.x was released and it's stable branch of the 1.9x development versions, so you wouldn't get much support from mod_perl users and developers if you use mod_perl 1.9x. RT-3.4.4 and greater '''won't work''' with development 1.9x releases.

* mod_perl 2.0 has been released with major API-changes in mod_perl 2.0-RC3 which lead to incompatibities that also affect RT, see this [http://lists.bestpractical.com/pipermail/rt-users/2005-April/030477.html mailing-list message].
** So RT-3.4.3 or any prior versions is '''totally unsupported''' on mod_perl 2.x.
** mod_perl 2.x has been '''marked as supported''' in RT 3.4.4. There is no mentioning of incomplete support in any way. See this [http://www.gossamer-threads.com/lists/rt/announce/48184 mailing list message].
** If you experience issues getting mod_perl 2.x+apache 2.x up and running, consider using apache 1.3.x + mod_perl 1.x or [[FastCGI]] instead, though this is much less likely than it used to be.

For [[CentOS]]-4.6 and RT 3.6.6, you can get a supported Web Stack by enabling the "centosplus" repository in Yum and doing a "yum update". If you try to use mod_perl2 on [[CentOS4]] without "centosplus" you will lose hair.

==== FastCGI ====

You can use [[FastCGI]] with Apache 1.3.x and 2.x. You can use [[FastCGI]] with other HTTP servers, but this functionality is not tested very well (if at all).

In RT versions prior to 3.2, RT's [[FastCGI]] handler runs setgid to the "rt" group to protect RT's database password. You may need to install a special "suidperl" package or reconfigure your perl setup to support "setuid scripts" if you intend to use RT with [[FastCGI]].

* Debian GNU/* 3.0+: the package which installs suidperl is called perl-suid, and should work without any tweaking.
* [[FreeBSD]] 4.2+: the package is called sperl, and should install a suidperl that just works
* Conectiva Linux 6.0+: suidperl is installed by default when perl is installed, but the program /bin/suidperl is not setuid. You must use chmod to make it setuid.

----

Prev: [[ManualIntroduction]] --- Up: [[UserManual]] --- Next: [[ManualInstallation]]
[[Category:RT User Manual]]

Rights

2011-02-06T05:22:37Z

BillCole: Reverted edits by 173.208.45.178 (talk | block) to last version by Jibsheet

User talk:AnneS

2011-02-04T20:05:44Z

BillCole: Wondering about administrative actions

What reason am I not seeing for blocking 68.40.186.204 and rolling back the seemingly valid point made from there on the [http://requesttracker.wikia.com/wiki/Talk:ManualUsingWebInterface Talk:ManualUsingWebInterface] page? It seems to me that the fact that all of the "screenshot" links on that page point to a defunct GeoCities site that now gets redirected to a Yahoo error page in Spanish is a very real problem with the [http://requesttracker.wikia.com/wiki/Talk:ManualUsingWebInterface ManualUsingWebInterface] page. [[User:BillCole|BillCole]] 20:05, February 4, 2011 (UTC)

RT Jifty Experimental Schema Changes

2011-02-04T19:45:05Z

BillCole: Reverted edits by AlexFortran (talk | block) to last version by Best Practical

= Columns renames =

* Columns in all tables have been renamed from [[CamelCase]] to lower_case
* Additional renames:

nick_name => 'nickname',
email_address => 'email',
principal_type => 'type',
immediate_parent_id => 'immediate_parent',

* covered in upgrade script

= Principals =

* ObjectId column has gone, it was always equal to id
** covered in upgrade script

= ACLs =

* Rights delegations gone
** every record where DelegatedBy is not null and is not equal to 0 should be deleted
*** covered in upgrade script
** DelegatedBy and DelegatedFrom columns have gone
*** covered in upgrade script

* PrincipalType is used for Roles only, so records where it is equal to Group or User are replaced with NULL

= Dates =

* All dates around 1970-01-01 that have been used as placeholders for "Not Set" have been replaced with NULLs
** <nowiki>!!! not implemented </nowiki>

...

Extensions

2011-02-04T19:35:07Z

BillCole: Reverted edits by 109.254.49.7 (talk | block) to last version by Gmirandaupc

Talk:RTUsers

2011-01-27T06:04:50Z

BillCole: /* Should this page exist? */

===Should this page exist? ===
With the old wiki, This page served a function as a public user list. On Wikia, there is a [[Special:ListUsers]] page that serves that function. Historically, this page was so heavily targeted by spammers that there were 450 changes in the last 2 months of its existence, when I was trying diligently to just keep the obvious new spam links out, i.e. on a typical day there would be 4 changes to add spam links and 4 removals. That has improved greatly at Wikia, but I'm pretty sure that a large fraction of the 'User' entries are really only here because some time ago a link-spammer put them on the old site and they didn't look spammy enough for anyone to remove them. I don't think it is worthwhile and maybe not even possible to sift out the legitimate personal entries from the bogus ones. even if someone adopted the task and did a reasonable job, would it be better than the [[Special:ListUsers]] page?

That just leaves the organizational user list, which may suffer from a similar problem despite at least one attempt to clean out the certain junk. If it is presumed accurate, is it worthwhile?

IMHO, the individual list should go and the org list swept for dubious cases (Vita-Mix? Really???) Anyone else have thoughts on that?

[[User:BillCole|BillCole]] 20:20, January 26, 2011 (UTC)

: Special:ListUsers is not at all similar to RTUsers. ListUsers is just a list of Wikia registered users who've edited pages here. RTUsers is supposed to be a more extensive list of folks who use RT. Does that make sense? Am I missing something? [[User:Tsibley|Tsibley]] 20:32, January 26, 2011 (UTC)
:: RTUsers is '''''really''''' a list of folks who use RT and have made an edit to the RTUsers page, probably, at some point in the last decade or so. On the other hand, Special:ListUsers can show people who have pages in the RT wiki's User namespace but who have never made any edits. At the Kwiki->Wifty import (June 2007) the list was 266 names long. At the Wifty->MediaWiki/Wikia import the headcount was 435. So even assuming that there are no bogus entries, the majority are pretty old. Beyond that, it isn't clear to me what purpose the list of individual users is supposed to serve, so it isn't clear to me whether it could be cleaned up, pruned, restructured, etc. to make it something useful. It isn't that I '''''want''''' the page gone gone, but more that since the Wikia migration meant I wasn't firefighting against constant vandalism, I noticed that the individual section of the page really may not be providing any particularly useful information worth defending. [[User:BillCole|BillCole]] 06:04, January 27, 2011 (UTC)

Talk:RTUsers

2011-01-26T20:20:34Z

BillCole: Existential doubts

Watch

2011-01-24T18:21:17Z

BillCole: Adding categories

A user with the '''Watch''' right can add or remove <u>himself</u> as requestor or Cc watcher on tickets.

This right can be granted to users in a global context, or on a queue-by-queue basis. In a global context Watch right also gives facility to modify queue watchers.

The [[ModifyTicket]] or [[ModifyQueueWatchers]] right allows a user to add or remove himself as well, next to the other possibilities these rights give to a user.

Another related right is [[WatchAsAdminCc]]

See also: [[Rights]], [[GlobalRights]]
[[Category:Rights]]

ModifyACL

2011-01-24T18:20:44Z

BillCole: Adding categories

A user with the '''Modify''''''ACL''' right can modify the Access Control List of an object.

To be able to modify the ACL on a group, the user will additionally need the [[AdminGroup]] right.

See also: [[Rights]], [[GlobalRights]]

TODO: Link to / Explain what an Access Control List does, exactly
[[Category:Rights]]

DeleteTicket

2011-01-24T18:19:52Z

BillCole: Adding categories

A user with the '''Delete''''''Ticket''' right can change the status from any ticket in a queue to the deleted status (Display a Ticket, choose Respond/Resolve/Comment, select deleted status in combo, then Update).

This right can be granted to users or groups on a global level, or on a queue-by-queue basis.

Deleted tickets are almost impossible to find if you do not know the number. On most RT installations tickets should only be deleted if they should never have been created in the first place; e.g. a spam message coming in via E-mail.

See also: [[Rights]], [[GlobalRights]]
[[Category:Rights]]

Category:Rights

2011-01-24T18:18:34Z

BillCole: Created page with "Pages describing RT "Rights" settings. This category could really use someone with a spare hour or two to find all the pages that should be in it."

Pages describing RT "Rights" settings.

This category could really use someone with a spare hour or two to find all the pages that should be in it.

DelegateRights

2011-01-24T18:16:39Z

BillCole: Adding categories

A user with the '''Delegate''''''Rights''' right can temporarily delegate his own rights to users in specified personal [[Group]]s.

See also: [[AdminOwnPersonalGroups]], [[Rights]], [[GlobalRights]]
[[Category:Rights]]

ModifyTicket

2011-01-24T18:14:37Z

BillCole: Adding categories

A user that has the '''Modify''''''Ticket''' right is allowed to make generic changes to a [[Ticket]].

This right can be granted in the global context, or on a queue-by-queue basis.

This right can be used to:

* ... change any ticket fields
* ... add or delete ticket links
* ... merge tickets, The user needs this right on both tickets!
* ... add or delete ticket custom field values

This right allows very much, but for some of these things there are alternatives or there are restrictions:

To allow a user:

* ... to send a [[Comment]] on a ticket, we can use the [[CommentOnTicket]] right
* ... to add [[Correspondence]] on a ticket, we can use [[ReplyToTicket]]
* ... to add or delete a themselves as <u>ticket</u> watcher ([[Requestor]], [[Cc]] or [[AdminCc]]), we can use [[Watch]] and [[WatchAsAdminCc]]

Restrictions:

* To change the Status from any to 'deleted' the user needs the [[DeleteTicket]] right.
* To change the ticket into another queue, the user also needs [[SeeQueue]] and [[CreateTicket]] in the target queue. The current owner will lose ownership of the ticket if he has no right [[OwnTicket]] in the target queue
* There are restrictions in setting the ownership of the ticket, More info can be found in the [[FAQ]]
[[Category:Rights]]

HomePage

2011-01-24T18:08:07Z

BillCole: Reverted edits by Allensmith (talk | block) to last version by Jibsheet

<div class="rt-notice">
== A new home! ==
The RT wiki is at its new home on Wikia. This move will help us combat spam more effectively and provide the often requested features of a modern wiki. If you notice anything out of place, please feel free to just fix it ;)

A read-only archive of the old wiki is at located at [http://wiki-archive.bestpractical.com wiki-archive.bestpractical.com], and existing wiki.bestpractical.com links will redirect to the new location of the pages.
</div>

== RT ==

RT is an open source issue tracking and workflow platform. This wiki site is a free resource for RT users. RT doesn't come with a formal formatted users or administrators guide, but it's likely most of what you need to know to use and run it is contained somewhere within this wiki, so look around a little, be patient... and try not to install RT on a Sunday night when you need to run it in production on Monday: it's '''big''', and learning how to set it up can take some time.

Please: [[UpdateTheWiki]], post your hints, tricks, tips and tools about how to get the most out of RT. If you currently use RT, please head over to [[RTUsers]] and add yourself and your organization to the user list.

== Announcements ==

=== Production Releases ===

* [http://blog.bestpractical.com/2010/05/rt-388-released.html RT 3.8.8 now available.]
* [http://blog.bestpractical.com/2009/11/rtir-242-now-available.html RTIR 2.4.2 now available.]
* [http://blog.bestpractical.com/2010/12/rtfm-243-released.html RTFM 2.4.3 now available.]

=== Development Releases and Status ===

* [http://blog.bestpractical.com/2010/09/rt-4-an-update.html RT 4 - An update.]
* [http://blog.bestpractical.com/2010/09/rt-394-first-development-release-leading-to-rt-400.html RT 3.9.4 - first development release leading to RT 4.0.0.]
* [http://blog.bestpractical.com/2010/09/rtir-260-release-candidate-1.html RTIR 2.6.0 Release Candidate 1.]

[http://blog.bestpractical.com/announcements/ Other Announcements from Best Practical.]

(Note: the newest versions of RTFM and RTIR require a fairly new version of RT as well, if not the absolute newest; be careful which versions you're using.)

== Sections ==

You can go through these pretty much in order if you're starting from scratch, but please plan to spend some quality time with the [[UserManual]] before you try to go live; RT is big and hairy, and you probably can't get your head around all of it in one sitting.

* [[FAQ]], [[FindingAnswersAboutRT]] and "Common Problems" below.
* [[BugReporting]]
* [[HowToHelp]], [[Translation]]
* [[Demo]]
* [[UserManual]], [[RTGlossary]] & [[Documentation]]
* [[InstallationGuides]], [[RTTutorials]]
* [[RT Config|RT_Config]] & [[RT SiteConfig|RT_SiteConfig]]

* [[Extensions]] to RT available as installable plugins
* [[Contributions]] by the community to customize RT
* [[RTIR]] RT for Incident Response
* [[RTFM]] RT FAQ Manager

* [[RTHistory]]
* [[InThePress]]
* [[REST]] API
* Customizing with [[CustomizingWithCallbacks|Callbacks]]

=== Common problems ===

* [[CantLocateObject]] - Can't locate object method "new" via package "<code>RT::Handle</code>" at rt3/lib/RT.pm
* [[NoConnectionToSyslog]] - no connection to syslog
* [[NoRecipFound]] - No recipients found. Not sending
* Getting information out of RT3 for [[reporting]] or inclusion elsewhere.
* [[PermissionDenied]] emails|

== Wish lists ==

* [[WikiWishList]] - wish list for this wiki
* [[WishList]] - wish list for the RT
* [[RT4WishList]] - wish list for the RT 4
* [[RT3StatisticsPackageWishList]]

__NOTOC__

FreeBSDInstallGuide

2011-01-24T18:05:30Z

BillCole: Warning on broken RT38 port.

= Available Ports =

www/rt36
www/rt38

Installing any of these involves:

cd /usr/ports/www/rtXXX
make install clean

You'll probably want to check out the Fresh Ports site for details on each of these:

http://www.freshports.org/www/rt36 currently shows www/rt36 is vulnerable
http://www.freshports.org/www/rt38 this shows www/rt38 to be most current

<u>'''''BEWARE: THE RT38 PORT HAS A CUSTOMIZED CONFIG.LAYOUT WHICH BREAKS THE STANDARD RT MECHANISM FOR LOCAL CUSTOMIZATION. DO NOT USE THAT PORT IF YOU WANT THE FLEXIBILITY TO CUSTOMIZE RT CLEANLY. '''''</u>

== Build Options ==

{| border="1"
|- valign="top"
| colspan="2" | <strong>RT32</strong>
|- valign="top"
| UPGRADE_RT30
| Upgrading from a RT 3.0 installation
|- valign="top"
| INITIAL_INSTALL
| Do initialize DB (for initial install only)
|}

|WITH_FASTCGI|Use [[FastCGI]] instead of mod_perl|

{| border="1"
|- valign="top"
| WITH_APACHE2
| Use Apache2 as the web server
|}

|DB_TYPE=type|mysql, Oracle, Pg or [[SQLite]] (default: mysql)|

{| border="1"
|- valign="top"
| DB_HOST=hostname
| The database host (default: localhost)
|- valign="top"
| DB_PORT=port
| The database port
|- valign="top"
| DB_DATABASE=port
| The database name (default: rt3)
|- valign="top"
| DB_DBA_USER=username
| Name of database administrator (root)
|- valign="top"
| DB_DBA_PASSWORD=password
| Password of database administrator
|- valign="top"
| DB_USER=username
| Name of database user for RT (default: rt_user)
|- valign="top"
| DB_PASSWORD=password
| Name of database password for RT (default: rt_pass)
|- valign="top"
| colspan="2" | <strong>RT3</strong>
|- valign="top"
| INITIAL_INSTALL
| Do initialize DB (for initial install only)
|}

|WITH_FASTCGI|Use [[FastCGI]] instead of mod_perl|

{| border="1"
|- valign="top"
| WITH_APACHE2
| Use Apache2 as the web server
|}

|DB_TYPE=type|mysql, Oracle, Pg or [[SQLite]] (default: mysql)|

{| border="1"
|- valign="top"
| DB_HOST=hostname
| The database host (default: localhost)
|- valign="top"
| DB_PORT=port
| The database port
|- valign="top"
| DB_DATABASE=database
| The database name (default: rt3)
|- valign="top"
| DB_DBA_USER=username
| Name of database administrator (root)
|- valign="top"
| DB_DBA_PASSWORD=password
| Password of database administrator
|- valign="top"
| DB_USER=username
| Name of database user for RT (default: rt_user)
|- valign="top"
| DB_PASSWORD=password
| Name of database password for RT (default: rt_pass)
|}

----

= Getting Perl Installed =

RT requires Perl-5.8.3 or greater.

For a fresh installation when no other ports of Perl have been installed:

cd /usr/ports/lang/perl5.8
make install clean

Upgrade 5.8.x to the current ports version:

portupgrade perl

Upgrade 5.6.1 to the current ports version:

portupgrade -o lang/perl5.8 perl-5.6.1

Now tell FreeBSD to use Perl-5.8.x instead of the 5.00x version included with the base install.

use.perl port

Which can be reversed with:

use.perl system

Note: if you already had some PERL-modules installed, you'll have to re-install them after you upgraded perl, or you might run into problems. See the UPGRADING-file in /usr/ports/. It should be pointed out that [[FreeBSD]] is probably one of the platforms RT is easiest to install on, if not '''the''' easiest. But this demands that the administrator has some familiarity with the OS and the way "things work" in [[FreeBSD]] land - consult the excellent handbook on the [[FreeBSD]]-website. The reward is an almost painless installation of RT with instant productivity gains.

make clean install

= Configuration =

Section 7 in [[ManualInstallation]] should get you started.

= Upgrading =

These are my notes from when I upgraded from 3.4.2 to 3.8.2 on [[FreeBSD]]: [[FreeBSDupgradeTo3 8 2|FreeBSDupgradeTo3_8_2]]

= Problems and Workarounds =

== Strange Issue ==

After a fresh install on [[FreeBSD]] 5.4, port "rt34 3.4.2", I get the following error upon starting Apache:

Use of uninitialized value in numeric eq (==) at /usr/local/lib/perl5/site_perl/5.8.6/CGI/Cookie.pm line 26.

any ideas? Thanks

== Same here ==

I get the same error overhere on a [[FreeBSD]] 5.3-RELEASE box, port www/rt34 also.

== Workaround For Apache Error ==

I solved my problem with the Cookie.pm error;

Use of uninitialized value in numeric eq (==) at /usr/local/lib/perl5/site_perl/5.8.6/CGI/Cookie.pm line 26.

by modifying the Cookie.pm to look like the below:

# Turn on special checking for Doug [[MacEachern]]'s modperl my $MOD_PERL = 0; if (exists $ENV{MOD_PERL}) {

if (defined($ENV{MOD_PERL_API_VERSION}) &&
$ENV{MOD_PERL_API_VERSION} == 2) {
$MOD_PERL = 2;

== Different Workaround For Apache Error ==

I use Debian, but it will work for you also Got through it by upgrading CGI.pm

* cpan install CGI::Cookie

FreeBSDupgradeTo3 8 2

2011-01-24T17:45:09Z

BillCole: remove spam link

'''WARNING:''' This notes are user experience and don't free you from reading README, UPGRADING and UPGRADING.mysql (if you are on mysql DB) files. You '''MUST''' read them.

Steffan below skipped upgrading mysql DB and most probably has broken attachments and/or malfunctioning RT.

----

My notes on our upgrade of 3.4.2 to 3.8.2. Existing server is running [[FreeBSD]] 5.4 and we used the [[FreeBSDInstallGuide]] to help us get going originally.

Other pages that helped me: [[ManualInstallation]], [[MultipleInstances]], [[FastCGIConfiguration]]

Ok... on with the show:

* Shut down Apache so nobody can get to RT.
* Make DB backup

home [/usr/homex]# mysqldump -p --opt rt3_4 > RT34_Backup.sql
Enter password: xxxxxxxxx

* Download new tar file into /usr/local/src/
* Untar it and fire up configure with all needed options. Look at them closely as you'll likely need to adjust:

./configure '--prefix=/usr/local/rt3' '--enable-layout=RT3' '--with-web-user=nobody' '--with-web-group=nobody' '--with-libs-group=wheel'
'--with-db-host=your.host.here.com' '--with-db-port=' '--with-db-type=mysql' '--with-db-rt-user=rt34' '--with-db-rt-pass=xxxxxxxx '
'--with-db-database=rt_upgrade' '--with-db-dba=root' '--mandir=/usr/local/man' '--infodir=/usr/local/info/' 'CC=cc'
'CFLAGS=-O2' --with-apachectl=/usr/local/apache/bin/apachectl --enable-gd --enable-graphviz

* Fix the needed dependencies (work through the cpan stuff)

[usr/local/src/rt-3.8.2]# make fixdeps

* Had to manual install a few packages:

[/usr/local/src/rt-3.8.2]# wget http://www.libgd.org/releases/gd-latest.tar.gz
[/usr/local/src/rt-3.8.2]# wget http://www.graphviz.org/pub/graphviz/stable/SOURCES/graphviz-2.20.3.tar.gz

* Install them by untaring and doing the standard: ./configure; make install
* RT complained later saying it couldn't find the graphviz exe, so I softlinked it:

[/]# ln -s /usr/local/bin/dot /usr/bin/dot

* Try again and again till no errors

[/usr/local/src/rt-3.8.2]# make fixdep

* Now upgrade your DB:

[/]# /usr/local/rt3/sbin/rt-setup-database --dba root --prompt-for-dba-password --action upgrade
In order to create or update your RT database, this script needs to connect to your mysql instance on your.host.here.com as root
Please specify that user's database password below. If the user has no database
password, just press return.

Password:
Working with:
Type: mysql
Host: your.host.here.com
Name: rt_upgrade
User: rt34
DBA: root
Enter RT version you're upgrading from: 3.4.2

Going to apply following upgrades:
3.5.1
3.7.1
... snip ...
3.8.1
3.8.2

Enter RT version if you want to stop upgrade at some point,
or leave it blank if you want apply above upgrades:

IT'S VERY IMPORTANT TO BACK UP BEFORE THIS STEP

Proceed [y/N]:y
Processing 3.5.1
Now inserting data
Processing 3.7.1
... snip ...
Processing 3.8.2
Now inserting data
[Tue Feb 3 23:29:12 2009] [warning]: Going to add [OLD] prefix to all temlates in approvals queue. If you never used
approvals then you can delete all these templates with [OLD] prefix. Leave new there may be you will want to use approvals
some time. (./etc/upgrade/3.8.2/content:3) [Tue Feb 3 23:29:14 2009] [warning]: IMPORTANT: We're going to delete all
scrips in Approvals queue and save them in 'rt-approvals-scrips-zgcD' file. (./etc/upgrade/3.8.2/content:165)
Done.
[usr/local/src/rt-3.8.2]#

* If it doesn't error you're golden! If it does, restore your DB and start over.

* OK. Now we apply the upgraded code:

[usr/local/src/rt-3.8.2]# make upgrade

* We had to move all of our old customizations out of the way and then rm the original dirs as they were trashing the new layout

[usr/local/src/rt-3.8.2]# cd /usr/local/rt3/local/
[/usr/local/rt3/local/]# cp -pR html html.rt34
[/usr/local/rt3/local/]# cp -pR lib lib.rt34
[/usr/local/rt3/local/]# rm -R html/*
[/usr/local/rt3/local/]# rm -R lib/*

* Time to tweak Apache. We're moving from running RT with /mod_perl/ to /fastcgi/. First we have to install that:

[/]# cd /usr/ports/www/mod_fastcgi
[/usr/ports/www/mod_fastcgi]# make install

... snip....

************************************************************
* Fast-cgi modules was included with your apache *
* configuration file *
* *
* You need to add following lines to your apache *
* configuration file. and restart it ! *
* *
* AddHandler fastcgi-script fcgi fcgi fpl *
* *
************************************************************
===> Registering installation for mod_fastcgi-2.4.2

* we also need the FCGI perl module now that we have fastcgi built:

[/usr/local/src/]# wget http://www.cpan.org/modules/by-module/FCGI/FCGI-0.67.tar.gz
[/usr/local/src/]# tar zxvf FCGI-0.67.tar.gz
[/usr/local/src/FCGI-0.67/]# cd FCGI-0.67
[/usr/local/src/FCGI-0.67/]# perl Makefile.PL
[/usr/local/src/FCGI-0.67/]# make install

* Now tweak the Apache conf file:

[/usr/local/rt3/local/]# cp /usr/local/apache/conf/httpd.conf /usr/local/apache/conf/httpd.conf.preupgrade
[/usr/local/rt3/local/]# vi /usr/local/apache/conf/httpd.conf

* Comment out the following lines:

<nowiki># PerlModule Apache::DBI
# PerlRequire /usr/local/rt3/bin/webmux.pl
# SetHandler perl-script
# PerlHandler RT::Mason
</nowiki>

* Add the following lines:

LoadModule fastcgi_module libexec/mod_fastcgi.so (in upper section next to other LoadModule's )
FastCgiServer /usr/local/rt3/bin/mason_handler.fcgi -idle-timeout 120 -processes 4 (right under above line)
ScriptAlias / /usr/local/rt3/bin/mason_handler.fcgi/ (right after the DocumentRoot statement)

* Restart Apache and give it a whirl
* If Apache refuses to start, check the error logs

Worked for me. Good luck -Steffan

ManualScrips

2010-12-23T00:26:31Z

BillCole: /* Scrips */

Prev: [[ManualRights]] --- Up: [[UserManual]] --- Next: [[ManualApprovals]]

= Appendix 3 =

== Scrips ==

A scrip performs some action when some conditions are met. Many actions use a template. You can read a scrip as a sentence like: When <condition>, do <action> with <template>. When creating a Scrip, it is helpful to make the "Description" field a user-friendly phrase such as "Send replies to Requestor and Cc users" because users see that description in '''bold''' on the ticket update composition page.

=== Table 1: Conditions ===

{| border="1"
|- valign="top"
| Condition Name
| What it means
| Possible Template
|- valign="top"
| User Defined
| A user-defined condition (should be described below)
| User-defined templates
|- valign="top"
| On Create
| When a new ticket is created
| Global template: Autoreply
|- valign="top"
| On Transaction
| When a ticket is updated or changed in any way
| Global template: Transaction
|- valign="top"
| On Reply
| When a watcher replies to a ticket
| Global template: Reply or Global template: Admin Reply
|- valign="top"
| On Comment
| When a watcher comments on a ticket (privately)
| Global template: Admin Comment
|- valign="top"
| On Correspond
| When a watcher corresponds to (replies to) a ticket (publicly)
| Global template: Blank
|- valign="top"
| On Status
| When the ticket's status changes
| Global template: Status Changed
|- valign="top"
| On Owner Change
| When the ticket gets a new owner
| Global template: Transaction
|- valign="top"
| On Queue Change
| When the ticket is put in a different queue
| Global template: Transaction
|- valign="top"
| On Resolve
| When the ticket is resolved (completed)
| Global template: Resolved
|}

Note: don't create a global scrip using the "On Create" condition and the "Create Ticket" scrip action. This will create a loop.

=== Table 2: Actions ===

{| border="1"
|- valign="top"
| Action Name
| What It Means
|- valign="top"
| Auto Reply to Requestors
| Email an Auto Reply template to the ticket's requestor
|- valign="top"
| Notify Requestors
| Email the ticket's requestor
|- valign="top"
| Notify Owner As Comment
| Email the ticket's owner. "As Comment" means the return address of the email is RT's comment address and all responses will be posted as comments not visible to the requestor.
|- valign="top"
| Notify Owner
| Email the ticket's owner.
|- valign="top"
| Notify Admin Ccs As Comment
| Email the ticket's Admin Ccs. "As Comment" means the return address of the email is RT's comment address and all responses will be posted as comments not visible to the requestor.
|- valign="top"
| Notify Admin Ccs
| Email the ticket's Admin Ccs.
|- valign="top"
| Notify Requestors And Ccs As Comment
| Email the ticket's requestor and Ccs. "As Comment" means the return address of the email is RT's comment address and all responses will be posted as comments not visible to the requestor.
|- valign="top"
| Notify Requestors And Ccs
| Email the ticket's requestor and Ccs.
|- valign="top"
| Notify All Watchers As Comment
| Email the ticket's requestor, owner, Ccs, and Admin Ccs. "As Comment" means the return address of the email is RT's comment address and all responses will be posted as comments not visible to the requestor.
|- valign="top"
| Notify All Watchers
| Email the ticket's requestor, owner, Ccs, and Admin Ccs.
|- valign="top"
| Notify Other Recipients As Comment
| Email the addresses in the Cc: and Bcc: fields of a ticket's reply or comment. "As Comment" means the return address of the email is RT's comment address and all responses will be posted as comments not visible to the requestor.
|- valign="top"
| Notify Other Recipients
| Email the addresses in the Cc: and Bcc: fields of a ticket's reply or comment
|- valign="top"
| Open Tickets
| Automatically opens a stalled, resolved, or rejected ticket when anyone replies to it; automatically opens new tickets when anyone except the requestor replies to it. Does not apply to tickets that are already open.
|}

Not clear what the difference is between Auto Reply and Notify Requestors

=== Table 3: Templates ===

{| border="1"
|- valign="top"
| Template name
| What the user sees
|- valign="top"
| Global template: Autoreply
| A form letter saying a ticket has been created and what the ticket's ID is.
|- valign="top"
| Global template: Transaction
| A form letter saying a ticket has been updated or changed in some way.
|- valign="top"
| Global template: Admin Reply
| A form letter saying a watcher sent a message and what the message was. Includes a URL linking to the message in RT.
|- valign="top"
| Global template: Reply
| A form letter saying a watcher sent a message and what the message was.
|- valign="top"
| Global template: Admin Comment
| A form letter saying a watcher sent a message and what the message was. Includes a URL linking to the message in RT and a note that says the requestor cannot see the message.
|- valign="top"
| Global template: Status Changed
| A form letter saying a ticket's status (open, new, stalled, etc.) has been changed.
|- valign="top"
| Global template: Resolved
| A form letter saying a ticket has been resolved.
|}

=== Custom condition ===

You can customize conditions to fit your needs better. It would be good to find some information about the condition syntax.

----

Prev: [[ManualRights]] --- Up: [[UserManual]] --- Next: [[ManualApache]]
[[Category:RT User Manual]]

Scrip

2010-12-23T00:16:47Z

BillCole: link to ManualScrips

'''Scrip''' is the main instrument to customize RT's behavior, implement your own workflow, and extend the logic of things.

Each scrip is a set of [[Condition]], [[ScripAction]], [[Template]] and [[Stage]].

See also: [[Contributions]], [[WriteCustomCondition]], [[WriteCustomAction]], [[ManualScrips]]

QueryBuilder

2010-12-23T00:12:04Z

BillCole: Automating redirect

#redirect [[TicketSQL]]

AdminCcs

2010-12-23T00:06:50Z

BillCole: Automating redirect

#redirect [[AdminCC]]