Master to 4.2.8
[usit-rt.git] / etc / RT_Config.pm
1 #
2 # RT was configured with:
3 #
4 #   $ ./configure --prefix=/www/var/rt/ --with-web-user=httpd --with-web-group=httpd --with-rt-group=uio-rt --with-db-type=Pg --with-db-dba=postgres --disable-gpg
5 #
6
7 package RT;
8
9 #############################  WARNING  #############################
10 #                                                                   #
11 #                     NEVER EDIT RT_Config.pm !                     #
12 #                                                                   #
13 #         Instead, copy any sections you want to change to          #
14 #         RT_SiteConfig.pm and edit them there.  Otherwise,         #
15 #         your changes will be lost when you upgrade RT.            #
16 #                                                                   #
17 #############################  WARNING  #############################
18
19 =head1 NAME
20
21 RT::Config
22
23 =head1 Base configuration
24
25 =over 4
26
27 =item C<$rtname>
28
29 C<$rtname> is the string that RT will look for in mail messages to
30 figure out what ticket a new piece of mail belongs to.
31
32 Your domain name is recommended, so as not to pollute the namespace.
33 Once you start using a given tag, you should probably never change it;
34 otherwise, mail for existing tickets won't get put in the right place.
35
36 =cut
37
38 Set($rtname, "example.com");
39
40 =item C<$Organization>
41
42 You should set this to your organization's DNS domain. For example,
43 I<fsck.com> or I<asylum.arkham.ma.us>. It is used by the linking
44 interface to guarantee that ticket URIs are unique and easy to
45 construct.  Changing it after you have created tickets in the system
46 will B<break> all existing ticket links!
47
48 =cut
49
50 Set($Organization, "example.com");
51
52 =item C<$CorrespondAddress>, C<$CommentAddress>
53
54 RT is designed such that any mail which already has a ticket-id
55 associated with it will get to the right place automatically.
56
57 C<$CorrespondAddress> and C<$CommentAddress> are the default addresses
58 that will be listed in From: and Reply-To: headers of correspondence
59 and comment mail tracked by RT, unless overridden by a queue-specific
60 address.  They should be set to email addresses which have been
61 configured as aliases for F<rt-mailgate>.
62
63 =cut
64
65 Set($CorrespondAddress, '');
66
67 Set($CommentAddress, '');
68
69 =item C<$WebDomain>
70
71 Domain name of the RT server, e.g. 'www.example.com'. It should not
72 contain anything except the server name.
73
74 =cut
75
76 Set($WebDomain, "localhost");
77
78 =item C<$WebPort>
79
80 If we're running as a superuser, run on port 80.  Otherwise, pick a
81 high port for this user.
82
83 443 is default port for https protocol.
84
85 =cut
86
87 Set($WebPort, 80);
88
89 =item C<$WebPath>
90
91 If you're putting the web UI somewhere other than at the root of your
92 server, you should set C<$WebPath> to the path you'll be serving RT
93 at.
94
95 C<$WebPath> requires a leading / but no trailing /, or it can be
96 blank.
97
98 In most cases, you should leave C<$WebPath> set to "" (an empty
99 value).
100
101 =cut
102
103 Set($WebPath, "");
104
105 =item C<$Timezone>
106
107 C<$Timezone> is the default timezone, used to convert times entered by
108 users into GMT, as they are stored in the database, and back again;
109 users can override this.  It should be set to a timezone recognized by
110 your server.
111
112 =cut
113
114 Set($Timezone, "US/Eastern");
115
116 =item C<@Plugins>
117
118 Once a plugin has been downloaded and installed, use C<Plugin()> to add
119 to the enabled C<@Plugins> list:
120
121     Plugin( "RT::Extension::SLA" );
122     Plugin( "RT::Authen::ExternalAuth" );
123
124 =cut
125
126 Set(@Plugins, ());
127
128 =item C<@StaticRoots>
129
130 Set C<@StaticRoots> to serve extra paths with a static handler.  The
131 contents of each hashref should be the the same arguments as
132 L<Plack::Middleware::Static> takes.  These paths will be checked before
133 any plugin or core static paths.
134
135 Example:
136
137     Set( @StaticRoots,
138         {
139             path => qr{^/static/},
140             root => '/local/path/to/static/parent',
141         },
142     );
143
144 =cut
145
146 Set( @StaticRoots, () );
147
148 =back
149
150
151
152
153 =head1 Database connection
154
155 =over 4
156
157 =item C<$DatabaseType>
158
159 Database driver being used; case matters.  Valid types are "mysql",
160 "Oracle", and "Pg".  "SQLite" is also available for non-production use.
161
162 =cut
163
164 Set($DatabaseType, "Pg");
165
166 =item C<$DatabaseHost>, C<$DatabaseRTHost>
167
168 The domain name of your database server.  If you're running MySQL and
169 on localhost, leave it blank for enhanced performance.
170
171 C<DatabaseRTHost> is the fully-qualified hostname of your RT server,
172 for use in granting ACL rights on MySQL.
173
174 =cut
175
176 Set($DatabaseHost,   "localhost");
177 Set($DatabaseRTHost, "localhost");
178
179 =item C<$DatabasePort>
180
181 The port that your database server is running on.  Ignored unless it's
182 a positive integer. It's usually safe to leave this blank; RT will
183 choose the correct default.
184
185 =cut
186
187 Set($DatabasePort, "");
188
189 =item C<$DatabaseUser>
190
191 The name of the user to connect to the database as.
192
193 =cut
194
195 Set($DatabaseUser, "rt_user");
196
197 =item C<$DatabasePassword>
198
199 The password the C<$DatabaseUser> should use to access the database.
200
201 =cut
202
203 Set($DatabasePassword, q{rt_pass});
204
205 =item C<$DatabaseName>
206
207 The name of the RT database on your database server. For Oracle, the
208 SID and database objects are created in C<$DatabaseUser>'s schema.
209
210 =cut
211
212 Set($DatabaseName, q{rt4});
213
214 =item C<$DatabaseRequireSSL>
215
216 If you're using PostgreSQL and have compiled in SSL support, set
217 C<$DatabaseRequireSSL> to 1 to turn on SSL communication with the
218 database.
219
220 =cut
221
222 Set($DatabaseRequireSSL, undef);
223
224 =item C<$DatabaseAdmin>
225
226 The name of the database administrator to connect to the database as
227 during upgrades.
228
229 =cut
230
231 Set($DatabaseAdmin, "postgres");
232
233 =back
234
235
236
237
238 =head1 Logging
239
240 The default is to log anything except debugging information to syslog.
241 Check the L<Log::Dispatch> POD for information about how to get things
242 by syslog, mail or anything else, get debugging info in the log, etc.
243
244 It might generally make sense to send error and higher by email to
245 some administrator.  If you do this, be careful that this email isn't
246 sent to this RT instance.  Mail loops will generate a critical log
247 message.
248
249 =over 4
250
251 =item C<$LogToSyslog>, C<$LogToSTDERR>
252
253 The minimum level error that will be logged to the specific device.
254 From lowest to highest priority, the levels are:
255
256     debug info notice warning error critical alert emergency
257
258 Many syslogds are configured to discard or file debug messages away, so
259 if you're attempting to debug RT you may need to reconfigure your
260 syslogd or use one of the other logging options.
261
262 Logging to your screen affects scripts run from the command line as well
263 as the STDERR sent to your webserver (so these logs will usually show up
264 in your web server's error logs).
265
266 =cut
267
268 Set($LogToSyslog, "info");
269 Set($LogToSTDERR, "info");
270
271 =item C<$LogToFile>, C<$LogDir>, C<$LogToFileNamed>
272
273 Logging to a standalone file is also possible. The file needs to both
274 exist and be writable by all direct users of the RT API. This generally
275 includes the web server and whoever rt-crontool runs as. Note that
276 rt-mailgate and the RT CLI go through the webserver, so their users do
277 not need to have write permissions to this file. If you expect to have
278 multiple users of the direct API, Best Practical recommends using syslog
279 instead of direct file logging.
280
281 You should set C<$LogToFile> to one of the levels documented above.
282
283 =cut
284
285 Set($LogToFile, undef);
286 Set($LogDir, q{var/log});
287 Set($LogToFileNamed, "rt.log");    #log to rt.log
288
289 =item C<$LogStackTraces>
290
291 If set to a log level then logging will include stack traces for
292 messages with level equal to or greater than specified.
293
294 NOTICE: Stack traces include parameters supplied to functions or
295 methods. It is possible for stack trace logging to reveal sensitive
296 information such as passwords or ticket content in your logs.
297
298 =cut
299
300 Set($LogStackTraces, "");
301
302 =item C<@LogToSyslogConf>
303
304 Additional options to pass to L<Log::Dispatch::Syslog>; the most
305 interesting flags include C<facility>, C<logopt>, and possibly C<ident>.
306 See the L<Log::Dispatch::Syslog> documentation for more information.
307
308 =cut
309
310 Set(@LogToSyslogConf, ());
311
312 =back
313
314
315
316 =head1 Incoming mail gateway
317
318 =over 4
319
320 =item C<$EmailSubjectTagRegex>
321
322 This regexp controls what subject tags RT recognizes as its own.  If
323 you're not dealing with historical C<$rtname> values, or historical
324 queue-specific subject tags, you'll likely never have to change this
325 configuration.
326
327 Be B<very careful> with it. Note that it overrides C<$rtname> for
328 subject token matching.
329
330 The setting below would make RT behave exactly as it does without the
331 setting enabled.
332
333 =cut
334
335 # Set($EmailSubjectTagRegex, qr/\Q$rtname\E/i );
336
337 =item C<$OwnerEmail>
338
339 C<$OwnerEmail> is the address of a human who manages RT. RT will send
340 errors generated by the mail gateway to this address; it will also be
341 displayed as the contact person on the RT's login page.  Because RT
342 sends errors to this address, it should I<not> be an address that's
343 managed by your RT instance, to avoid mail loops.
344
345 =cut
346
347 Set($OwnerEmail, 'root');
348
349 =item C<$LoopsToRTOwner>
350
351 If C<$LoopsToRTOwner> is defined, RT will send mail that it believes
352 might be a loop to C<$OwnerEmail>.
353
354 =cut
355
356 Set($LoopsToRTOwner, 1);
357
358 =item C<$StoreLoops>
359
360 If C<$StoreLoops> is defined, RT will record messages that it believes
361 to be part of mail loops.  As it does this, it will try to be careful
362 not to send mail to the sender of these messages.
363
364 =cut
365
366 Set($StoreLoops, undef);
367
368 =item C<$MaxAttachmentSize>
369
370 C<$MaxAttachmentSize> sets the maximum size (in bytes) of attachments
371 stored in the database.  This setting is irrelevant unless one of
372 $TruncateLongAttachments or $DropLongAttachments (below) are set, B<OR>
373 the database is stored in Oracle.  On Oracle, attachments larger than
374 this can be fully stored, but will be truncated to this length when
375 read.
376
377 =cut
378
379 Set($MaxAttachmentSize, 10_000_000);  # 10M
380
381 =item C<$TruncateLongAttachments>
382
383 If this is set to a non-undef value, RT will truncate attachments
384 longer than C<$MaxAttachmentSize>.
385
386 =cut
387
388 Set($TruncateLongAttachments, undef);
389
390 =item C<$DropLongAttachments>
391
392 If this is set to a non-undef value, RT will silently drop attachments
393 longer than C<MaxAttachmentSize>.  C<$TruncateLongAttachments>, above,
394 takes priority over this.
395
396 =cut
397
398 Set($DropLongAttachments, undef);
399
400 =item C<$RTAddressRegexp>
401
402 C<$RTAddressRegexp> is used to make sure RT doesn't add itself as a
403 ticket CC if C<$ParseNewMessageForTicketCcs>, above, is enabled.  It
404 is important that you set this to a regular expression that matches
405 all addresses used by your RT.  This lets RT avoid sending mail to
406 itself.  It will also hide RT addresses from the list of "One-time Cc"
407 and Bcc lists on ticket reply.
408
409 If you have a number of addresses configured in your RT database
410 already, you can generate a naive first pass regexp by using:
411
412     perl etc/upgrade/generate-rtaddressregexp
413
414 If left blank, RT will compare each address to your configured
415 C<$CorrespondAddress> and C<$CommentAddress> before searching for a
416 Queue configured with a matching "Reply Address" or "Comment Address"
417 on the Queue Admin page.
418
419 =cut
420
421 Set($RTAddressRegexp, undef);
422
423 =item C<$CanonicalizeEmailAddressMatch>, C<$CanonicalizeEmailAddressReplace>
424
425 RT provides functionality which allows the system to rewrite incoming
426 email addresses, using L<RT::User/CanonicalizeEmailAddress>.  The
427 default implementation replaces all occurrences of the regular
428 expression in C<CanonicalizeEmailAddressMatch> with
429 C<CanonicalizeEmailAddressReplace>, via C<s/$Match/$Replace/gi>.  The
430 most common use of this is to replace C<@something.example.com> with
431 C<@example.com>.  If more complex noramlization is required,
432 L<RT::User/CanonicalizeEmailAddress> can be overridden to provide it.
433
434 =cut
435
436 # Set($CanonicalizeEmailAddressMatch, '@subdomain\.example\.com$');
437 # Set($CanonicalizeEmailAddressReplace, '@example.com');
438
439 =item C<$CanonicalizeOnCreate>
440
441 Set this to 1 and the create new user page will use the values that
442 you enter in the form but use the function CanonicalizeUserInfo in
443 F<RT/User_Local.pm>
444
445 =cut
446
447 Set($CanonicalizeOnCreate, 0);
448
449 =item C<$ValidateUserEmailAddresses>
450
451 By default C<$ValidateUserEmailAddresses> is 1, and RT will refuse to create
452 users with an invalid email address (as specified in RFC 2822) or with
453 an email address made of multiple email addresses.
454
455 Set this to 0 to skip any email address validation.  Doing so may open up
456 vulnerabilities.
457
458 =cut
459
460 Set($ValidateUserEmailAddresses, 1);
461
462 =item C<@MailPlugins>
463
464 C<@MailPlugins> is a list of authentication plugins for
465 L<RT::Interface::Email> to use; see L<rt-mailgate>
466
467 =cut
468
469 =item C<$UnsafeEmailCommands>
470
471 C<$UnsafeEmailCommands>, if set to 1, enables 'take' and 'resolve'
472 as possible actions via the mail gateway.  As its name implies, this
473 is very unsafe, as it allows email with a forged sender to possibly
474 resolve arbitrary tickets!
475
476 =cut
477
478 =item C<$ExtractSubjectTagMatch>, C<$ExtractSubjectTagNoMatch>
479
480 The default "extract remote tracking tags" scrip settings; these
481 detect when your RT is talking to another RT, and adjust the subject
482 accordingly.
483
484 =cut
485
486 Set($ExtractSubjectTagMatch, qr/\[[^\]]+? #\d+\]/);
487 Set($ExtractSubjectTagNoMatch, ( ${RT::EmailSubjectTagRegex}
488        ? qr/\[(?:${RT::EmailSubjectTagRegex}) #\d+\]/
489        : qr/\[\Q$RT::rtname\E #\d+\]/));
490
491 =item C<$CheckMoreMSMailHeaders>
492
493 Some email clients create a plain text version of HTML-formatted
494 email to help other clients that read only plain text.
495 Unfortunately, the plain text parts sometimes end up with
496 doubled newlines and these can then end up in RT. This
497 is most often seen in MS Outlook.
498
499 Enable this option to have RT check for additional mail headers
500 and attempt to identify email from MS Outlook. When detected,
501 RT will then clean up double newlines. Note that it may
502 clean up intentional double newlines as well.
503
504 =cut
505
506 Set( $CheckMoreMSMailHeaders, 0);
507
508 =back
509
510
511
512 =head1 Outgoing mail
513
514 =over 4
515
516 =item C<$MailCommand>
517
518 C<$MailCommand> defines which method RT will use to try to send mail.
519 We know that 'sendmailpipe' works fairly well.  If 'sendmailpipe'
520 doesn't work well for you, try 'sendmail'.  'qmail' is also a supported
521 value.
522
523 For testing purposes, or to simply disable sending mail out into the
524 world, you can set C<$MailCommand> to 'testfile' which writes all mail
525 to a temporary file.  RT will log the location of the temporary file
526 so you can extract mail from it afterward.
527
528 On shutdown, RT will clean up the temporary file created when using
529 the 'testfile' option. If testing while the RT server is still running,
530 you can find the files in the location noted in the log file. If you run
531 a tool like C<rt-crontool> however, or if you look after stopping the server,
532 the files will have been deleted when the process completed. If you need to
533 keep the files for development or debugging, you can manually set
534 C<< UNLINK => 0 >> where the testfile config is processed in
535 F<lib/RT/Interface/Email.pm>.
536
537 =cut
538
539 Set($MailCommand, "sendmailpipe");
540
541 =item C<$SetOutgoingMailFrom>
542
543 C<$SetOutgoingMailFrom> tells RT to set the sender envelope to the
544 Correspond mail address of the ticket's queue.
545
546 Warning: If you use this setting, bounced mails will appear to be
547 incoming mail to the system, thus creating new tickets.
548
549 If the value contains an C<@>, it is assumed to be an email address and used as
550 a global envelope sender.  Expected usage in this case is to simply set the
551 same envelope sender on all mail from RT, without defining
552 C<$OverrideOutgoingMailFrom>.  If you do define C<$OverrideOutgoingMailFrom>,
553 anything specified there overrides the global value (including Default).
554
555 This option only works if C<$MailCommand> is set to 'sendmailpipe'.
556
557 =cut
558
559 Set($SetOutgoingMailFrom, 0);
560
561 =item C<$OverrideOutgoingMailFrom>
562
563 C<$OverrideOutgoingMailFrom> is used for overwriting the Correspond
564 address of the queue as it is handed to sendmail -f. This helps force
565 the From_ header away from www-data or other email addresses that show
566 up in the "Sent by" line in Outlook.
567
568 The option is a hash reference of queue id/name to email address. If
569 there is no ticket involved, then the value of the C<Default> key will
570 be used.
571
572 This option only works if C<$SetOutgoingMailFrom> is enabled and
573 C<$MailCommand> is set to 'sendmailpipe'.
574
575 =cut
576
577 Set($OverrideOutgoingMailFrom, {
578 #    'Default' => 'admin@rt.example.com',
579 #    'General' => 'general@rt.example.com',
580 });
581
582 =item C<$DefaultMailPrecedence>
583
584 C<$DefaultMailPrecedence> is used to control the default Precedence
585 level of outgoing mail where none is specified.  By default it is
586 C<bulk>, but if you only send mail to your staff, you may wish to
587 change it.
588
589 Note that you can set the precedence of individual templates by
590 including an explicit Precedence header.
591
592 If you set this value to C<undef> then we do not set a default
593 Precedence header to outgoing mail. However, if there already is a
594 Precedence header, it will be preserved.
595
596 =cut
597
598 Set($DefaultMailPrecedence, "bulk");
599
600 =item C<$DefaultErrorMailPrecedence>
601
602 C<$DefaultErrorMailPrecedence> is used to control the default
603 Precedence level of outgoing mail that indicates some kind of error
604 condition. By default it is C<bulk>, but if you only send mail to your
605 staff, you may wish to change it.
606
607 If you set this value to C<undef> then we do not add a Precedence
608 header to error mail.
609
610 =cut
611
612 Set($DefaultErrorMailPrecedence, "bulk");
613
614 =item C<$UseOriginatorHeader>
615
616 C<$UseOriginatorHeader> is used to control the insertion of an
617 RT-Originator Header in every outgoing mail, containing the mail
618 address of the transaction creator.
619
620 =cut
621
622 Set($UseOriginatorHeader, 1);
623
624 =item C<$UseFriendlyFromLine>
625
626 By default, RT sets the outgoing mail's "From:" header to "SenderName
627 via RT".  Setting C<$UseFriendlyFromLine> to 0 disables it.
628
629 =cut
630
631 Set($UseFriendlyFromLine, 1);
632
633 =item C<$FriendlyFromLineFormat>
634
635 C<sprintf()> format of the friendly 'From:' header; its arguments are
636 SenderName and SenderEmailAddress.
637
638 =cut
639
640 Set($FriendlyFromLineFormat, "\"%s via RT\" <%s>");
641
642 =item C<$UseFriendlyToLine>
643
644 RT can optionally set a "Friendly" 'To:' header when sending messages
645 to Ccs or AdminCcs (rather than having a blank 'To:' header.
646
647 This feature DOES NOT WORK WITH SENDMAIL[tm] BRAND SENDMAIL.  If you
648 are using sendmail, rather than postfix, qmail, exim or some other
649 MTA, you _must_ disable this option.
650
651 =cut
652
653 Set($UseFriendlyToLine, 0);
654
655 =item C<$FriendlyToLineFormat>
656
657 C<sprintf()> format of the friendly 'To:' header; its arguments are
658 WatcherType and TicketId.
659
660 =cut
661
662 Set($FriendlyToLineFormat, "\"%s of ". RT->Config->Get('rtname') ." Ticket #%s\":;");
663
664 =item C<$NotifyActor>
665
666 By default, RT doesn't notify the person who performs an update, as
667 they already know what they've done. If you'd like to change this
668 behavior, Set C<$NotifyActor> to 1
669
670 =cut
671
672 Set($NotifyActor, 0);
673
674 =item C<$RecordOutgoingEmail>
675
676 By default, RT records each message it sends out to its own internal
677 database.  To change this behavior, set C<$RecordOutgoingEmail> to 0
678
679 If this is disabled, users' digest mail delivery preferences
680 (i.e. EmailFrequency) will also be ignored.
681
682 =cut
683
684 Set($RecordOutgoingEmail, 1);
685
686 =item C<$VERPPrefix>, C<$VERPDomain>
687
688 Setting these options enables VERP support
689 L<http://cr.yp.to/proto/verp.txt>.
690
691 Uncomment the following two directives to generate envelope senders
692 of the form C<${VERPPrefix}${originaladdress}@${VERPDomain}>
693 (i.e. rt-jesse=fsck.com@rt.example.com ).
694
695 This currently only works with sendmail and sendmailpipe.
696
697 =cut
698
699 # Set($VERPPrefix, "rt-");
700 # Set($VERPDomain, $RT::Organization);
701
702
703 =item C<$ForwardFromUser>
704
705 By default, RT forwards a message using queue's address and adds RT's
706 tag into subject of the outgoing message, so recipients' replies go
707 into RT as correspondents.
708
709 To change this behavior, set C<$ForwardFromUser> to 1 and RT
710 will use the address of the current user and remove RT's subject tag.
711
712 =cut
713
714 Set($ForwardFromUser, 0);
715
716 =back
717
718 =head2 Email dashboards
719
720 =over 4
721
722 =item C<$DashboardAddress>
723
724 The email address from which RT will send dashboards. If none is set,
725 then C<$OwnerEmail> will be used.
726
727 =cut
728
729 Set($DashboardAddress, '');
730
731 =item C<$DashboardSubject>
732
733 Lets you set the subject of dashboards. Arguments are the frequency (Daily,
734 Weekly, Monthly) of the dashboard and the dashboard's name.
735
736 =cut
737
738 Set($DashboardSubject, "%s Dashboard: %s");
739
740 =item C<@EmailDashboardRemove>
741
742 A list of regular expressions that will be used to remove content from
743 mailed dashboards.
744
745 =cut
746
747 Set(@EmailDashboardRemove, ());
748
749 =back
750
751
752
753 =head2 Sendmail configuration
754
755 These options only take effect if C<$MailCommand> is 'sendmail' or
756 'sendmailpipe'
757
758 =over 4
759
760 =item C<$SendmailArguments>
761
762 C<$SendmailArguments> defines what flags to pass to C<$SendmailPath>
763 These options are good for most sendmail wrappers and work-a-likes.
764
765 These arguments are good for sendmail brand sendmail 8 and newer:
766 C<Set($SendmailArguments,"-oi -ODeliveryMode=b -OErrorMode=m");>
767
768 =cut
769
770 Set($SendmailArguments, "-oi");
771
772
773 =item C<$SendmailBounceArguments>
774
775 C<$SendmailBounceArguments> defines what flags to pass to C<$Sendmail>
776 assuming RT needs to send an error (i.e. bounce).
777
778 =cut
779
780 Set($SendmailBounceArguments, '-f "<>"');
781
782 =item C<$SendmailPath>
783
784 If you selected 'sendmailpipe' above, you MUST specify the path to
785 your sendmail binary in C<$SendmailPath>.
786
787 =cut
788
789 Set($SendmailPath, "/usr/sbin/sendmail");
790
791
792 =back
793
794 =head2 Other mailers
795
796 =over 4
797
798 =item C<@MailParams>
799
800 C<@MailParams> defines a list of options passed to $MailCommand if it
801 is not 'sendmailpipe' or 'sendmail';
802
803 =cut
804
805 Set(@MailParams, ());
806
807 =back
808
809
810 =head1 Web interface
811
812 =over 4
813
814 =item C<$WebDefaultStylesheet>
815
816 This determines the default stylesheet the RT web interface will use.
817 RT ships with several themes by default:
818
819   rudder          The default theme for RT 4.2
820   aileron         The default layout for RT 4.0
821   web2            The default layout for RT 3.8
822   ballard         Theme which doesn't rely on JavaScript for menuing
823
824 This value actually specifies a directory in F<share/static/css/>
825 from which RT will try to load the file main.css (which should @import
826 any other files the stylesheet needs).  This allows you to easily and
827 cleanly create your own stylesheets to apply to RT.  This option can
828 be overridden by users in their preferences.
829
830 =cut
831
832 Set($WebDefaultStylesheet, "rudder");
833
834 =item C<$DefaultQueue>
835
836 Use this to select the default queue name that will be used for
837 creating new tickets. You may use either the queue's name or its
838 ID. This only affects the queue selection boxes on the web interface.
839
840 =cut
841
842 # Set($DefaultQueue, "General");
843
844 =item C<$RememberDefaultQueue>
845
846 When a queue is selected in the new ticket dropdown, make it the new
847 default for the new ticket dropdown.
848
849 =cut
850
851 # Set($RememberDefaultQueue, 1);
852
853 =item C<$EnableReminders>
854
855 Hide all links and portlets related to Reminders by setting this to 0
856
857 =cut
858
859 Set($EnableReminders, 1);
860
861 =item C<@CustomFieldValuesSources>
862
863 Set C<@CustomFieldValuesSources> to a list of class names which extend
864 L<RT::CustomFieldValues::External>.  This can be used to pull lists of
865 custom field values from external sources at runtime.
866
867 =cut
868
869 Set(@CustomFieldValuesSources, ());
870
871 =item C<%CustomFieldGroupings>
872
873 This option affects the display of ticket and user custom fields in the
874 web interface. It does not address the sorting of custom fields within
875 the groupings; which is controlled by the Ticket Custom Fields tab in
876 Queue Configuration in the Admin UI.
877
878 A nested datastructure defines how to group together custom fields
879 under a mix of built-in and arbitrary headings ("groupings").
880
881 Set C<%CustomFieldGroupings> to a nested structure similar to the following:
882
883     Set(%CustomFieldGroupings,
884         'RT::Ticket' => [
885             'Grouping Name'     => ['CF Name', 'Another CF'],
886             'Another Grouping'  => ['Some CF'],
887             'Dates'             => ['Shipped date'],
888         ],
889         'RT::User' => [
890             'Phones' => ['Fax number'],
891         ],
892     );
893
894 The first level keys are record types for which CFs may be used, and the
895 values are either hashrefs or arrayrefs -- if arrayrefs, then the
896 ordering is preserved during display, otherwise groupings are displayed
897 alphabetically.  The second level keys are the grouping names and the
898 values are array refs containing a list of CF names.
899
900 There are several special built-in groupings which RT displays in
901 specific places (usually the collapsible box of the same title).  The
902 ordering of these standard groupings cannot be modified.  You may also
903 only append Custom Fields to the list in these boxes, not reorder or
904 remove core fields.
905
906 For C<RT::Ticket>, these groupings are: C<Basics>, C<Dates>, C<Links>, C<People>
907
908 For C<RT::User>: C<Identity>, C<Access control>, C<Location>, C<Phones>
909
910 Extensions may also add their own built-in groupings, refer to the individual
911 extension documentation for those.
912
913 =item C<$CanonicalizeRedirectURLs>
914
915 Set C<$CanonicalizeRedirectURLs> to 1 to use C<$WebURL> when
916 redirecting rather than the one we get from C<%ENV>.
917
918 Apache's UseCanonicalName directive changes the hostname that RT
919 finds in C<%ENV>.  You can read more about what turning it On or Off
920 means in the documentation for your version of Apache.
921
922 If you use RT behind a reverse proxy, you almost certainly want to
923 enable this option.
924
925 =cut
926
927 Set($CanonicalizeRedirectURLs, 0);
928
929 =item C<$CanonicalizeURLsInFeeds>
930
931 Set C<$CanonicalizeURLsInFeeds> to 1 to use C<$WebURL> in feeds
932 rather than the one we get from request.
933
934 If you use RT behind a reverse proxy, you almost certainly want to
935 enable this option.
936
937 =cut
938
939 Set($CanonicalizeURLsInFeeds, 0);
940
941 =item C<@JSFiles>
942
943 A list of additional JavaScript files to be included in head.
944
945 =cut
946
947 Set(@JSFiles, qw//);
948
949 =item C<$JSMinPath>
950
951 Path to the jsmin binary; if specified, it will be used to minify
952 C<JSFiles>.  The default, and the fallback if the binary cannot be
953 found, is to simply concatenate the files.
954
955 jsmin can be installed by running 'make jsmin' from the RT install
956 directory, or from http://www.crockford.com/javascript/jsmin.html
957
958 =cut
959
960 # Set($JSMinPath, "/path/to/jsmin");
961
962 =item C<@CSSFiles>
963
964 A list of additional CSS files to be included in head.
965
966 If you're a plugin author, refer to RT->AddStyleSheets.
967
968 =cut
969
970 Set(@CSSFiles, qw//);
971
972 =item C<$UsernameFormat>
973
974 This determines how user info is displayed. 'concise' will show the
975 first of RealName, Name or EmailAddress that has a value. 'verbose' will
976 show EmailAddress, and the first of RealName or Name which is defined.
977 The default, 'role', uses 'verbose' for unprivileged users, and the Name
978 followed by the RealName for privileged users.
979
980 =cut
981
982 Set($UsernameFormat, "role");
983
984 =item C<$UserSearchResultFormat>
985
986 This controls the display of lists of users returned from the User
987 Summary Search. The display of users in the Admin interface is
988 controlled by C<%AdminSearchResultFormat>.
989
990 =cut
991
992 Set($UserSearchResultFormat,
993          q{ '<a href="__WebPath__/User/Summary.html?id=__id__">__id__</a>/TITLE:#'}
994         .q{,'<a href="__WebPath__/User/Summary.html?id=__id__">__Name__</a>/TITLE:Name'}
995         .q{,__RealName__, __EmailAddress__}
996 );
997
998 =item C<@UserSummaryPortlets>
999
1000 A list of portlets to be displayed on the User Summary page.
1001 By default, we show all of the available portlets.
1002 Extensions may provide their own portlets for this page.
1003
1004 =cut
1005
1006 Set(@UserSummaryPortlets, (qw/ExtraInfo CreateTicket ActiveTickets InactiveTickets/));
1007
1008 =item C<$UserSummaryExtraInfo>
1009
1010 This controls what information is displayed on the User Summary
1011 portal. By default the user's Real Name, Email Address and Username
1012 are displayed. You can remove these or add more as needed. This
1013 expects a Format string of user attributes. Please note that not all
1014 the attributes are supported in this display because we're not
1015 building a table.
1016
1017 =cut
1018
1019 Set($UserSummaryExtraInfo, "RealName, EmailAddress, Name");
1020
1021 =item C<$UserSummaryTicketListFormat>
1022
1023 Control the appearance of the Active and Inactive ticket lists in the
1024 User Summary.
1025
1026 =cut
1027
1028 Set($UserSummaryTicketListFormat, q{
1029        '<B><A HREF="__WebPath__/Ticket/Display.html?id=__id__">__id__</a></B>/TITLE:#',
1030        '<B><A HREF="__WebPath__/Ticket/Display.html?id=__id__">__Subject__</a></B>/TITLE:Subject',
1031        Status,
1032        QueueName,
1033        Owner,
1034        Priority,
1035        '__NEWLINE__',
1036        '',
1037        '<small>__Requestors__</small>',
1038        '<small>__CreatedRelative__</small>',
1039        '<small>__ToldRelative__</small>',
1040        '<small>__LastUpdatedRelative__</small>',
1041        '<small>__TimeLeft__</small>'
1042 });
1043
1044 =item C<$WebBaseURL>, C<$WebURL>
1045
1046 Usually you don't want to set these options. The only obvious reason
1047 is if RT is accessible via https protocol on a non standard port, e.g.
1048 'https://rt.example.com:9999'. In all other cases these options are
1049 computed using C<$WebDomain>, C<$WebPort> and C<$WebPath>.
1050
1051 C<$WebBaseURL> is the scheme, server and port
1052 (e.g. 'http://rt.example.com') for constructing URLs to the web
1053 UI. C<$WebBaseURL> doesn't need a trailing /.
1054
1055 C<$WebURL> is the C<$WebBaseURL>, C<$WebPath> and trailing /, for
1056 example: 'http://www.example.com/rt/'.
1057
1058 =cut
1059
1060 my $port = RT->Config->Get('WebPort');
1061 Set($WebBaseURL,
1062     ($port == 443? 'https': 'http') .'://'
1063     . RT->Config->Get('WebDomain')
1064     . ($port != 80 && $port != 443? ":$port" : '')
1065 );
1066
1067 Set($WebURL, RT->Config->Get('WebBaseURL') . RT->Config->Get('WebPath') . "/");
1068
1069 =item C<$WebImagesURL>
1070
1071 C<$WebImagesURL> points to the base URL where RT can find its images.
1072 Define the directory name to be used for images in RT web documents.
1073
1074 =cut
1075
1076 Set($WebImagesURL, RT->Config->Get('WebPath') . "/static/images/");
1077
1078 =item C<$LogoURL>
1079
1080 C<$LogoURL> points to the URL of the RT logo displayed in the web UI.
1081 This can also be configured via the web UI.
1082
1083 =cut
1084
1085 Set($LogoURL, RT->Config->Get('WebImagesURL') . "bpslogo.png");
1086
1087 =item C<$LogoLinkURL>
1088
1089 C<$LogoLinkURL> is the URL that the RT logo hyperlinks to.
1090
1091 =cut
1092
1093 Set($LogoLinkURL, "http://bestpractical.com");
1094
1095 =item C<$LogoAltText>
1096
1097 C<$LogoAltText> is a string of text for the alt-text of the logo. It
1098 will be passed through C<loc> for localization.
1099
1100 =cut
1101
1102 Set($LogoAltText, "Best Practical Solutions, LLC corporate logo");
1103
1104 =item C<$WebNoAuthRegex>
1105
1106 What portion of RT's URL space should not require authentication.  The
1107 default is almost certainly correct, and should only be changed if you
1108 are extending RT.
1109
1110 =cut
1111
1112 Set($WebNoAuthRegex, qr{^ (?:/+NoAuth/ | /+REST/\d+\.\d+/NoAuth/) }x );
1113
1114 =item C<$SelfServiceRegex>
1115
1116 What portion of RT's URLspace should be accessible to Unprivileged
1117 users This does not override the redirect from F</Ticket/Display.html>
1118 to F</SelfService/Display.html> when Unprivileged users attempt to
1119 access ticked displays.
1120
1121 =cut
1122
1123 Set($SelfServiceRegex, qr!^(?:/+SelfService/)!x );
1124
1125 =item C<$WebFlushDbCacheEveryRequest>
1126
1127 By default, RT clears its database cache after every page view.  This
1128 ensures that you've always got the most current information when
1129 working in a multi-process (mod_perl or FastCGI) Environment.  Setting
1130 C<$WebFlushDbCacheEveryRequest> to 0 will turn this off, which will
1131 speed RT up a bit, at the expense of a tiny bit of data accuracy.
1132
1133 =cut
1134
1135 Set($WebFlushDbCacheEveryRequest, 1);
1136
1137 =item C<%ChartFont>
1138
1139 The L<GD> module (which RT uses for graphs) ships with a built-in font
1140 that doesn't have full Unicode support. You can use a given TrueType
1141 font for a specific language by setting %ChartFont to (language =E<gt>
1142 the absolute path of a font) pairs. Your GD library must have support
1143 for TrueType fonts to use this option. If there is no entry for a
1144 language in the hash then font with 'others' key is used.
1145
1146 RT comes with two TrueType fonts covering most available languages.
1147
1148 =cut
1149
1150 Set(
1151     %ChartFont,
1152     'zh-cn'  => "$RT::BasePath/share/fonts/DroidSansFallback.ttf",
1153     'zh-tw'  => "$RT::BasePath/share/fonts/DroidSansFallback.ttf",
1154     'ja'     => "$RT::BasePath/share/fonts/DroidSansFallback.ttf",
1155     'others' => "$RT::BasePath/share/fonts/DroidSans.ttf",
1156 );
1157
1158 =item C<$ChartsTimezonesInDB>
1159
1160 RT stores dates using the UTC timezone in the DB, so charts grouped by
1161 dates and time are not representative. Set C<$ChartsTimezonesInDB> to 1
1162 to enable timezone conversions using your DB's capabilities. You may
1163 need to do some work on the DB side to use this feature, read more in
1164 F<docs/customizing/timezones_in_charts.pod>.
1165
1166 At this time, this feature only applies to MySQL and PostgreSQL.
1167
1168 =cut
1169
1170 Set($ChartsTimezonesInDB, 0);
1171
1172 =item C<@ChartColors>
1173
1174 An array of 6-digit hexadecimal RGB color values used for chart series.  By
1175 default there are 12 distinct colors.
1176
1177 =cut
1178
1179 Set(@ChartColors, qw(
1180     66cc66 ff6666 ffcc66 663399
1181     3333cc 339933 993333 996633
1182     33cc33 cc3333 cc9933 6633cc
1183 ));
1184
1185 =back
1186
1187
1188
1189 =head2 Home page
1190
1191 =over 4
1192
1193 =item C<$DefaultSummaryRows>
1194
1195 C<$DefaultSummaryRows> is default number of rows displayed in for
1196 search results on the front page.
1197
1198 =cut
1199
1200 Set($DefaultSummaryRows, 10);
1201
1202 =item C<$HomePageRefreshInterval>
1203
1204 C<$HomePageRefreshInterval> is default number of seconds to refresh
1205 the RT home page. Choose from [0, 120, 300, 600, 1200, 3600, 7200].
1206
1207 =cut
1208
1209 Set($HomePageRefreshInterval, 0);
1210
1211 =item C<$HomepageComponents>
1212
1213 C<$HomepageComponents> is an arrayref of allowed components on a
1214 user's customized homepage ("RT at a glance").
1215
1216 =cut
1217
1218 Set(
1219     $HomepageComponents,
1220     [
1221         qw(QuickCreate Quicksearch MyAdminQueues MySupportQueues MyReminders RefreshHomepage Dashboards SavedSearches FindUser) # loc_qw
1222     ]
1223 );
1224
1225 =back
1226
1227
1228
1229
1230 =head2 Ticket search
1231
1232 =over 4
1233
1234 =item C<$UseSQLForACLChecks>
1235
1236 Historically, ACLs were checked on display, which could lead to empty
1237 search pages and wrong ticket counts.  Set C<$UseSQLForACLChecks> to 0
1238 to go back to this method; this will reduce the complexity of the
1239 generated SQL statements, at the cost of the aforementioned bugs.
1240
1241 =cut
1242
1243 Set($UseSQLForACLChecks, 1);
1244
1245 =item C<$TicketsItemMapSize>
1246
1247 On the display page of a ticket from search results, RT provides links
1248 to the first, next, previous and last ticket from the results.  In
1249 order to build these links, RT needs to fetch the full result set from
1250 the database, which can be resource-intensive.
1251
1252 Set C<$TicketsItemMapSize> to number of tickets you want RT to examine
1253 to build these links. If the full result set is larger than this
1254 number, RT will omit the "last" link in the menu.  Set this to zero to
1255 always examine all results.
1256
1257 =cut
1258
1259 Set($TicketsItemMapSize, 1000);
1260
1261 =item C<$SearchResultsRefreshInterval>
1262
1263 C<$SearchResultsRefreshInterval> is default number of seconds to
1264 refresh search results in RT. Choose from [0, 120, 300, 600, 1200,
1265 3600, 7200].
1266
1267 =cut
1268
1269 Set($SearchResultsRefreshInterval, 0);
1270
1271 =item C<$DefaultSearchResultFormat>
1272
1273 C<$DefaultSearchResultFormat> is the default format for RT search
1274 results
1275
1276 =cut
1277
1278 Set ($DefaultSearchResultFormat, qq{
1279    '<B><A HREF="__WebPath__/Ticket/Display.html?id=__id__">__id__</a></B>/TITLE:#',
1280    '<B><A HREF="__WebPath__/Ticket/Display.html?id=__id__">__Subject__</a></B>/TITLE:Subject',
1281    Status,
1282    QueueName,
1283    Owner,
1284    Priority,
1285    '__NEWLINE__',
1286    '__NBSP__',
1287    '<small>__Requestors__</small>',
1288    '<small>__CreatedRelative__</small>',
1289    '<small>__ToldRelative__</small>',
1290    '<small>__LastUpdatedRelative__</small>',
1291    '<small>__TimeLeft__</small>'});
1292
1293 =item C<$DefaultSearchResultOrderBy>
1294
1295 What Tickets column should we order by for RT Ticket search results.
1296
1297 =cut
1298
1299 Set($DefaultSearchResultOrderBy, 'id');
1300
1301 =item C<$DefaultSearchResultOrder>
1302
1303 When ordering RT Ticket search results by C<$DefaultSearchResultOrderBy>,
1304 should the sort be ascending (ASC) or descending (DESC).
1305
1306 =cut
1307
1308 Set($DefaultSearchResultOrder, 'ASC');
1309
1310 =item C<$DefaultSelfServiceSearchResultFormat>
1311
1312 C<$DefaultSelfServiceSearchResultFormat> is the default format of
1313 searches displayed in the SelfService interface.
1314
1315 =cut
1316
1317 Set($DefaultSelfServiceSearchResultFormat, qq{
1318    '<B><A HREF="__WebPath__/SelfService/Display.html?id=__id__">__id__</a></B>/TITLE:#',
1319    '<B><A HREF="__WebPath__/SelfService/Display.html?id=__id__">__Subject__</a></B>/TITLE:Subject',
1320    Status,
1321    Requestors,
1322    Owner});
1323
1324 =item C<%FullTextSearch>
1325
1326 Full text search (FTS) without database indexing is a very slow
1327 operation, and is thus disabled by default.
1328
1329 Before setting C<Indexed> to 1, read F<docs/full_text_indexing.pod> for
1330 the full details of FTS on your particular database.
1331
1332 It is possible to enable FTS without database indexing support, simply
1333 by setting the C<Enable> key to 1, while leaving C<Indexed> set to 0.
1334 This is not generally suggested, as unindexed full-text searching can
1335 cause severe performance problems.
1336
1337 =cut
1338
1339 Set(%FullTextSearch,
1340     Enable  => 0,
1341     Indexed => 0,
1342 );
1343
1344 =item C<$DontSearchFileAttachments>
1345
1346 If C<$DontSearchFileAttachments> is set to 1, then uploaded files
1347 (attachments with file names) are not searched during content
1348 search.
1349
1350 Note that if you use indexed FTS then named attachments are still
1351 indexed by default regardless of this option.
1352
1353 =cut
1354
1355 Set($DontSearchFileAttachments, undef);
1356
1357 =item C<$OnlySearchActiveTicketsInSimpleSearch>
1358
1359 When query in simple search doesn't have status info, use this to only
1360 search active ones.
1361
1362 =cut
1363
1364 Set($OnlySearchActiveTicketsInSimpleSearch, 1);
1365
1366 =item C<$SearchResultsAutoRedirect>
1367
1368 When only one ticket is found in search, use this to redirect to the
1369 ticket display page automatically.
1370
1371 =cut
1372
1373 Set($SearchResultsAutoRedirect, 0);
1374
1375 =back
1376
1377
1378
1379 =head2 Ticket display
1380
1381 =over 4
1382
1383 =item C<$ShowMoreAboutPrivilegedUsers>
1384
1385 This determines if the 'More about requestor' box on
1386 Ticket/Display.html is shown for Privileged Users.
1387
1388 =cut
1389
1390 Set($ShowMoreAboutPrivilegedUsers, 0);
1391
1392 =item C<$MoreAboutRequestorTicketList>
1393
1394 This can be set to Active, Inactive, All or None.  It controls what
1395 ticket list will be displayed in the 'More about requestor' box on
1396 Ticket/Display.html.  This option can be controlled by users also.
1397
1398 =cut
1399
1400 Set($MoreAboutRequestorTicketList, "Active");
1401
1402 =item C<$MoreAboutRequestorTicketListFormat>
1403
1404 Control the appearance of the ticket lists in the 'More About Requestors' box.
1405
1406 =cut
1407
1408 Set($MoreAboutRequestorTicketListFormat, q{
1409        '<a href="__WebPath__/Ticket/Display.html?id=__id__">__id__</a>',
1410        '__Owner__',
1411        '<a href="__WebPath__/Ticket/Display.html?id=__id__">__Subject__</a>',
1412        '__Status__',
1413 });
1414
1415
1416 =item C<$MoreAboutRequestorExtraInfo>
1417
1418 By default, the 'More about requestor' box on Ticket/Display.html
1419 shows the Requestor's name and ticket list.  If you would like to see
1420 extra information about the user, this expects a Format string of user
1421 attributes.  Please note that not all the attributes are supported in
1422 this display because we're not building a table.
1423
1424 Example:
1425 C<Set($MoreAboutRequestorExtraInfo,"Organization, Address1")>
1426
1427 =cut
1428
1429 Set($MoreAboutRequestorExtraInfo, "");
1430
1431 =item C<$MoreAboutRequestorGroupsLimit>
1432
1433 By default, the 'More about requestor' box on Ticket/Display.html
1434 shows all the groups of the Requestor.  Use this to limit the number
1435 of groups; a value of undef removes the group display entirely.
1436
1437 =cut
1438
1439 Set($MoreAboutRequestorGroupsLimit, 0);
1440
1441 =item C<$UseSideBySideLayout>
1442
1443 Should the ticket create and update forms use a more space efficient
1444 two column layout.  This layout may not work in narrow browsers if you
1445 set a MessageBoxWidth (below).
1446
1447 =cut
1448
1449 Set($UseSideBySideLayout, 1);
1450
1451 =item C<$EditCustomFieldsSingleColumn>
1452
1453 When displaying a list of Ticket Custom Fields for editing, RT
1454 defaults to a 2 column list.  If you set this to 1, it will instead
1455 display the Custom Fields in a single column.
1456
1457 =cut
1458
1459 Set($EditCustomFieldsSingleColumn, 0);
1460
1461 =item C<$ShowUnreadMessageNotifications>
1462
1463 If set to 1, RT will prompt users when there are new,
1464 unread messages on tickets they are viewing.
1465
1466 =cut
1467
1468 Set($ShowUnreadMessageNotifications, 0);
1469
1470 =item C<$AutocompleteOwners>
1471
1472 If set to 1, the owner drop-downs for ticket update/modify and the query
1473 builder are replaced by text fields that autocomplete.  This can
1474 alleviate the sometimes huge owner list for installations where many
1475 users have the OwnTicket right.
1476
1477 Autocompleter is automatically turned on if list contains more than
1478 50 users, but penalty of executing potentially slow query is still paid.
1479
1480 Drop down doesn't show unprivileged users. If your setup allows unprivileged
1481 to own ticket then you have to enable autocompleting.
1482
1483 =cut
1484
1485 Set($AutocompleteOwners, 0);
1486
1487 =item C<$AutocompleteOwnersForSearch>
1488
1489 If set to 1, the owner drop-downs for the query builder are always
1490 replaced by text field that autocomplete and C<$AutocompleteOwners>
1491 is ignored. Helpful when owners list is huge in the query builder.
1492
1493 =cut
1494
1495 Set($AutocompleteOwnersForSearch, 0);
1496
1497 =item C<$UserSearchFields>
1498
1499 Used by the User Autocompleter as well as the User Search.
1500
1501 Specifies which fields of L<RT::User> to match against and how to match
1502 each field when autocompleting users.  Valid match methods are LIKE,
1503 STARTSWITH, ENDSWITH, =, and !=.  Valid search fields are the core User
1504 fields, as well as custom fields, which are specified as "CF.1234" or
1505 "CF.Name"
1506
1507 =cut
1508
1509 Set($UserSearchFields, {
1510     EmailAddress => 'STARTSWITH',
1511     Name         => 'STARTSWITH',
1512     RealName     => 'LIKE',
1513 });
1514
1515 =item C<$AllowUserAutocompleteForUnprivileged>
1516
1517 Should unprivileged users be allowed to autocomplete users.  Setting
1518 this option to 1 means unprivileged users will be able to search all
1519 your users.
1520
1521 =cut
1522
1523 Set($AllowUserAutocompleteForUnprivileged, 0);
1524
1525 =item C<$TicketAutocompleteFields>
1526
1527 Specifies which fields of L<RT::Ticket> to match against and how to match each
1528 field when autocompleting users.  Valid match methods are LIKE, STARTSWITH,
1529 ENDSWITH, C<=>, and C<!=>.
1530
1531 Not all Ticket fields are publically accessible and hence won't work for
1532 autocomplete unless you override their accessibility using a local overlay or a
1533 plugin.  Out of the box the following fields are public: id, Subject.
1534
1535 =cut
1536
1537 Set( $TicketAutocompleteFields, {
1538     id      => 'STARTSWITH',
1539     Subject => 'LIKE',
1540 });
1541
1542 =item C<$DisplayTicketAfterQuickCreate>
1543
1544 Enable this to redirect to the created ticket display page
1545 automatically when using QuickCreate.
1546
1547 =cut
1548
1549 Set($DisplayTicketAfterQuickCreate, 0);
1550
1551 =item C<$WikiImplicitLinks>
1552
1553 Support implicit links in WikiText custom fields?  Setting this to 1
1554 causes InterCapped or ALLCAPS words in WikiText fields to automatically
1555 become links to searches for those words.  If used on Articles, it links
1556 to the Article with that name.
1557
1558 =cut
1559
1560 Set($WikiImplicitLinks, 0);
1561
1562 =item C<$PreviewScripMessages>
1563
1564 Set C<$PreviewScripMessages> to 1 if the scrips preview on the ticket
1565 reply page should include the content of the messages to be sent.
1566
1567 =cut
1568
1569 Set($PreviewScripMessages, 0);
1570
1571 =item C<$SimplifiedRecipients>
1572
1573 If C<$SimplifiedRecipients> is set, a simple list of who will receive
1574 B<any> kind of mail will be shown on the ticket reply page, instead of a
1575 detailed breakdown by scrip.
1576
1577 =cut
1578
1579 Set($SimplifiedRecipients, 0);
1580
1581 =item C<$HideResolveActionsWithDependencies>
1582
1583 If set to 1, this option will skip ticket menu actions which can't be
1584 completed successfully because of outstanding active Depends On tickets.
1585
1586 By default, all ticket actions are displayed in the menu even if some of
1587 them can't be successful until all Depends On links are resolved or
1588 transitioned to another inactive status.
1589
1590 =cut
1591
1592 Set($HideResolveActionsWithDependencies, 0);
1593
1594 =back
1595
1596
1597
1598 =head2 Articles
1599
1600 =over 4
1601
1602 =item C<$ArticleOnTicketCreate>
1603
1604 Set this to 1 to display the Articles interface on the Ticket Create
1605 page in addition to the Reply/Comment page.
1606
1607 =cut
1608
1609 Set($ArticleOnTicketCreate, 0);
1610
1611 =item C<$HideArticleSearchOnReplyCreate>
1612
1613 Set this to 1 to hide the search and include boxes from the Article
1614 UI.  This assumes you have enabled Article Hotlist feature, otherwise
1615 you will have no access to Articles.
1616
1617 =cut
1618
1619 Set($HideArticleSearchOnReplyCreate, 0);
1620
1621 =back
1622
1623
1624
1625 =head2 Message box properties
1626
1627 =over 4
1628
1629 =item C<$MessageBoxWidth>, C<$MessageBoxHeight>
1630
1631 For message boxes, set the entry box width, height and what type of
1632 wrapping to use.  These options can be overridden by users in their
1633 preferences.
1634
1635 When the width is set to undef, no column count is specified and the
1636 message box will take up 100% of the available width.  Combining this
1637 with HARD messagebox wrapping (below) is not recommended, as it will
1638 lead to inconsistent width in transactions between browsers.
1639
1640 These settings only apply to the non-RichText message box.  See below
1641 for Rich Text settings.
1642
1643 =cut
1644
1645 Set($MessageBoxWidth, undef);
1646 Set($MessageBoxHeight, 15);
1647
1648 =item C<$MessageBoxRichText>
1649
1650 Should "rich text" editing be enabled? This option lets your users
1651 send HTML email messages from the web interface.
1652
1653 =cut
1654
1655 Set($MessageBoxRichText, 1);
1656
1657 =item C<$MessageBoxRichTextHeight>
1658
1659 Height of rich text JavaScript enabled editing boxes (in pixels)
1660
1661 =cut
1662
1663 Set($MessageBoxRichTextHeight, 200);
1664
1665 =item C<$MessageBoxIncludeSignature>
1666
1667 Should your users' signatures (from their Preferences page) be
1668 included in Comments and Replies.
1669
1670 =cut
1671
1672 Set($MessageBoxIncludeSignature, 1);
1673
1674 =item C<$MessageBoxIncludeSignatureOnComment>
1675
1676 Should your users' signatures (from their Preferences page) be
1677 included in Comments. Setting this to 0 overrides
1678 C<$MessageBoxIncludeSignature>.
1679
1680 =cut
1681
1682 Set($MessageBoxIncludeSignatureOnComment, 1);
1683
1684 =back
1685
1686
1687 =head2 Transaction display
1688
1689 =over 4
1690
1691 =item C<$OldestTransactionsFirst>
1692
1693 By default, RT shows newest transactions at the bottom of the ticket
1694 history page, if you want see them at the top set this to 0.  This
1695 option can be overridden by users in their preferences.
1696
1697 =cut
1698
1699 Set($OldestTransactionsFirst, 1);
1700
1701 =item C<$ShowHistory>
1702
1703 This option controls how history is shown on the ticket display page.  It
1704 accepts one of three possible modes and is overrideable on a per-user
1705 preference level.  If you regularly deal with long tickets and don't care much
1706 about the history, you may wish to change this option to C<click>.
1707
1708 =over
1709
1710 =item C<delay> (the default)
1711
1712 When set to C<delay>, history is loaded via javascript after the rest of the
1713 page has been loaded.  This speeds up apparent page load times and generally
1714 provides a smoother experience.  You may notice slight delays before the ticket
1715 history appears on very long tickets.
1716
1717 =item C<click>
1718
1719 When set to C<click>, history is loaded on demand when a placeholder link is
1720 clicked.  This speeds up ticket display page loads and history is never loaded
1721 if not requested.
1722
1723 =item C<always>
1724
1725 When set to C<always>, history is loaded before showing the page.  This ensures
1726 history is always available immediately, but at the expense of longer page load
1727 times.  This behaviour was the default in RT 4.0.
1728
1729 =back
1730
1731 =cut
1732
1733 Set($ShowHistory, 'delay');
1734
1735 =item C<$ShowBccHeader>
1736
1737 By default, RT hides from the web UI information about blind copies
1738 user sent on reply or comment.
1739
1740 =cut
1741
1742 Set($ShowBccHeader, 0);
1743
1744 =item C<$TrustHTMLAttachments>
1745
1746 If C<TrustHTMLAttachments> is not defined, we will display them as
1747 text. This prevents malicious HTML and JavaScript from being sent in a
1748 request (although there is probably more to it than that)
1749
1750 =cut
1751
1752 Set($TrustHTMLAttachments, undef);
1753
1754 =item C<$AlwaysDownloadAttachments>
1755
1756 Always download attachments, regardless of content type. If set, this
1757 overrides C<TrustHTMLAttachments>.
1758
1759 =cut
1760
1761 Set($AlwaysDownloadAttachments, undef);
1762
1763 =item C<$PreferRichText>
1764
1765 By default, RT shows rich text (HTML) messages if possible.  If
1766 C<$PreferRichText> is set to 0, RT will show plain text messages in
1767 preference to any rich text alternatives.
1768
1769 As a security precaution, RT limits the HTML that is displayed to a
1770 known-good subset -- as allowing arbitrary HTML to be displayed exposes
1771 multiple vectors for XSS and phishing attacks.  If
1772 L</$TrustHTMLAttachments> is enabled, the original HTML is available for
1773 viewing via the "Download" link.
1774
1775 If the optional L<HTML::Gumbo> dependency is installed, RT will leverage
1776 this to allow a broader set of HTML through, including tables.
1777
1778 =cut
1779
1780 Set($PreferRichText, 1);
1781
1782 =item C<$MaxInlineBody>
1783
1784 C<$MaxInlineBody> is the maximum attachment size that we want to see
1785 inline when viewing a transaction.  RT will inline any text if the
1786 value is undefined or 0.  This option can be overridden by users in
1787 their preferences.
1788
1789 =cut
1790
1791 Set($MaxInlineBody, 12000);
1792
1793 =item C<$ShowTransactionImages>
1794
1795 By default, RT shows images attached to incoming (and outgoing) ticket
1796 updates inline. Set this variable to 0 if you'd like to disable that
1797 behavior.
1798
1799 =cut
1800
1801 Set($ShowTransactionImages, 1);
1802
1803 =item C<$ShowRemoteImages>
1804
1805 By default, RT doesn't show remote images attached to incoming (and outgoing)
1806 ticket updates inline.  Set this variable to 1 if you'd like to enable remote
1807 image display.  Showing remote images may allow spammers and other senders to
1808 track when messages are viewed and see referer information.
1809
1810 Note that this setting is independent of L</$ShowTransactionImages> above.
1811
1812 =cut
1813
1814 Set($ShowRemoteImages, 0);
1815
1816 =item C<$PlainTextMono>
1817
1818 Normally plaintext attachments are displayed as HTML with line breaks
1819 preserved.  This causes space- and tab-based formatting not to be
1820 displayed correctly.  Set C<$PlainTextMono> to 1 to use a monospaced
1821 font and preserve formatting.
1822
1823 =cut
1824
1825 Set($PlainTextMono, 0);
1826
1827 =item C<$SuppressInlineTextFiles>
1828
1829 If C<$SuppressInlineTextFiles> is set to 1, then uploaded text files
1830 (text-type attachments with file names) are prevented from being
1831 displayed in-line when viewing a ticket's history.
1832
1833 =cut
1834
1835 Set($SuppressInlineTextFiles, undef);
1836
1837
1838 =item C<@Active_MakeClicky>
1839
1840 MakeClicky detects various formats of data in headers and email
1841 messages, and extends them with supporting links.  By default, RT
1842 provides two formats:
1843
1844 * 'httpurl': detects http:// and https:// URLs and adds '[Open URL]'
1845   link after the URL.
1846
1847 * 'httpurl_overwrite': also detects URLs as 'httpurl' format, but
1848   replaces the URL with a link.  Enabled by default.
1849
1850 See F<share/html/Elements/MakeClicky> for documentation on how to add
1851 your own styles of link detection.
1852
1853 =cut
1854
1855 Set(@Active_MakeClicky, qw(httpurl_overwrite));
1856
1857 =item C<$QuoteFolding>
1858
1859 Quote folding is the hiding of old replies in transaction history.
1860 It defaults to on.  Set this to 0 to disable it.
1861
1862 =cut
1863
1864 Set($QuoteFolding, 1);
1865
1866 =item C<$AllowLoginPasswordAutoComplete>
1867
1868 Allow browsers to remember the user's password on login (in case the
1869 browser can do so, and has the appropriate setting enabled). Default
1870 is 0.
1871
1872 =cut
1873
1874 Set($AllowLoginPasswordAutoComplete, 0);
1875
1876 =back
1877
1878
1879 =head1 Application logic
1880
1881 =over 4
1882
1883 =item C<$ParseNewMessageForTicketCcs>
1884
1885 If C<$ParseNewMessageForTicketCcs> is set to 1, RT will attempt to
1886 divine Ticket 'Cc' watchers from the To and Cc lines of incoming
1887 messages that create new Tickets. This option does not apply to replies
1888 or comments on existing Tickets. Be forewarned that if you have I<any>
1889 addresses which forward mail to RT automatically and you enable this
1890 option without modifying C<$RTAddressRegexp> below, you will get
1891 yourself into a heap of trouble.
1892
1893 =cut
1894
1895 Set($ParseNewMessageForTicketCcs, undef);
1896
1897 =item C<$UseTransactionBatch>
1898
1899 Set C<$UseTransactionBatch> to 1 to execute transactions in batches,
1900 such that a resolve and comment (for example) would happen
1901 simultaneously, instead of as two transactions, unaware of each
1902 others' existence.
1903
1904 =cut
1905
1906 Set($UseTransactionBatch, 1);
1907
1908 =item C<$StrictLinkACL>
1909
1910 When this feature is enabled a user needs I<ModifyTicket> rights on
1911 both tickets to link them together; otherwise, I<ModifyTicket> rights
1912 on either of them is sufficient.
1913
1914 =cut
1915
1916 Set($StrictLinkACL, 1);
1917
1918 =item C<$RedistributeAutoGeneratedMessages>
1919
1920 Should RT redistribute correspondence that it identifies as machine
1921 generated?  A 1 will do so; setting this to 0 will cause no
1922 such messages to be redistributed.  You can also use 'privileged' (the
1923 default), which will redistribute only to privileged users. This helps
1924 to protect against malformed bounces and loops caused by auto-created
1925 requestors with bogus addresses.
1926
1927 =cut
1928
1929 Set($RedistributeAutoGeneratedMessages, "privileged");
1930
1931 =item C<$ApprovalRejectionNotes>
1932
1933 Should rejection notes from approvals be sent to the requestors?
1934
1935 =cut
1936
1937 Set($ApprovalRejectionNotes, 1);
1938
1939 =item C<$ForceApprovalsView>
1940
1941 Should approval tickets only be viewed and modified through the standard
1942 approval interface?  With this setting enabled (by default), any attempt to use
1943 the normal ticket display and modify page for approval tickets will be
1944 redirected.
1945
1946 For example, with this option set to 1 and an approval ticket #123:
1947
1948     /Ticket/Display.html?id=123
1949
1950 is redirected to
1951
1952     /Approval/Display.html?id=123
1953
1954 With this option set to 0, the redirect won't happen.
1955
1956 =back
1957
1958 =cut
1959
1960 Set($ForceApprovalsView, 1);
1961
1962 =head1 Extra security
1963
1964 This is a list of extra security measures to enable that help keep your RT
1965 safe.  If you don't know what these mean, you should almost certainly leave the
1966 defaults alone.
1967
1968 =over 4
1969
1970 =item C<$DisallowExecuteCode>
1971
1972 If set to 1, the C<ExecuteCode> right will be removed from
1973 all users, B<including> the superuser.  This is intended for when RT is
1974 installed into a shared environment where even the superuser should not
1975 be allowed to run arbitrary Perl code on the server via scrips.
1976
1977 =cut
1978
1979 Set($DisallowExecuteCode, 0);
1980
1981 =item C<$Framebusting>
1982
1983 If set to 0, framekiller javascript will be disabled and the
1984 X-Frame-Options: DENY header will be suppressed from all responses.
1985 This disables RT's clickjacking protection.
1986
1987 =cut
1988
1989 Set($Framebusting, 1);
1990
1991 =item C<$RestrictReferrer>
1992
1993 If set to 0, the HTTP C<Referer> (sic) header will not be
1994 checked to ensure that requests come from RT's own domain.  As RT allows
1995 for GET requests to alter state, disabling this opens RT up to
1996 cross-site request forgery (CSRF) attacks.
1997
1998 =cut
1999
2000 Set($RestrictReferrer, 1);
2001
2002 =item C<$RestrictLoginReferrer>
2003
2004 If set to 0, RT will allow the user to log in from any link
2005 or request, merely by passing in C<user> and C<pass> parameters; setting
2006 it to 1 forces all logins to come from the login box, so the
2007 user is aware that they are being logged in.  The default is off, for
2008 backwards compatability.
2009
2010 =cut
2011
2012 Set($RestrictLoginReferrer, 0);
2013
2014 =item C<@ReferrerWhitelist>
2015
2016 This is a list of hostname:port combinations that RT will treat as being
2017 part of RT's domain. This is particularly useful if you access RT as
2018 multiple hostnames or have an external auth system that needs to
2019 redirect back to RT once authentication is complete.
2020
2021  Set(@ReferrerWhitelist, qw(www.example.com:443  www3.example.com:80));
2022
2023 If the "RT has detected a possible cross-site request forgery" error is triggered
2024 by a host:port sent by your browser that you believe should be valid, you can copy
2025 the host:port from the error message into this list.
2026
2027 Simple wildcards, similar to SSL certificates, are allowed.  For example:
2028
2029     *.example.com:80    # matches foo.example.com
2030                         # but not example.com
2031                         #      or foo.bar.example.com
2032
2033     www*.example.com:80 # matches www3.example.com
2034                         #     and www-test.example.com
2035                         #     and www.example.com
2036
2037 =cut
2038
2039 Set(@ReferrerWhitelist, qw());
2040
2041
2042 =item C<$BcryptCost>
2043
2044 This sets the default cost parameter used for the C<bcrypt> key
2045 derivation function.  Valid values range from 4 to 31, inclusive, with
2046 higher numbers denoting greater effort.
2047
2048 =cut
2049
2050 Set($BcryptCost, 10);
2051
2052 =back
2053
2054
2055
2056 =head1 Authorization and user configuration
2057
2058 =over 4
2059
2060 =item C<$WebRemoteUserAuth>
2061
2062 If C<$WebRemoteUserAuth> is defined, RT will defer to the environment's
2063 REMOTE_USER variable, which should be set by the webserver's
2064 authentication layer.
2065
2066 =cut
2067
2068 Set($WebRemoteUserAuth, undef);
2069
2070 =item C<$WebRemoteUserContinuous>
2071
2072 If C<$WebRemoteUserContinuous> is defined, RT will check for the
2073 REMOTE_USER on each access.  If you would prefer this to only happen
2074 once (at initial login) set this to 0.  The default
2075 setting will help ensure that if your webserver's authentication layer
2076 deauthenticates a user, RT notices as soon as possible.
2077
2078 =cut
2079
2080 Set($WebRemoteUserContinuous, 1);
2081
2082 =item C<$WebFallbackToRTLogin>
2083
2084 If C<$WebFallbackToRTLogin> is defined, the user is allowed a
2085 chance of fallback to the login screen, even if REMOTE_USER failed.
2086
2087 =cut
2088
2089 Set($WebFallbackToRTLogin, undef);
2090
2091 =item C<$WebRemoteUserGecos>
2092
2093 C<$WebRemoteUserGecos> means to match 'gecos' field as the user
2094 identity; useful with C<mod_auth_external>.
2095
2096 =cut
2097
2098 Set($WebRemoteUserGecos, undef);
2099
2100 =item C<$WebRemoteUserAutocreate>
2101
2102 C<$WebRemoteUserAutocreate> will create users under the same name as
2103 REMOTE_USER upon login, if they are missing from the Users table.
2104
2105 =cut
2106
2107 Set($WebRemoteUserAutocreate, undef);
2108
2109 =item C<$UserAutocreateDefaultsOnLogin>
2110
2111 If C<$WebRemoteUserAutocreate> is set to 1, C<$UserAutocreateDefaultsOnLogin>
2112 will be passed to L<RT::User/Create>.  Use it to set defaults, such as
2113 creating unprivileged users with C<<{ Privileged => 0 }>>.  This must be
2114 a hashref.
2115
2116 =cut
2117
2118 Set($UserAutocreateDefaultsOnLogin, undef);
2119
2120 =item C<$WebSessionClass>
2121
2122 C<$WebSessionClass> is the class you wish to use for storing sessions.  On
2123 MySQL, Pg, and Oracle it defaults to using your database, in other cases
2124 sessions are stored in files using L<Apache::Session::File>. Other installed
2125 Apache::Session::* modules can be used to store sessions.
2126
2127     Set($WebSessionClass, "Apache::Session::File");
2128
2129 =cut
2130
2131 Set($WebSessionClass, undef);
2132
2133 =item C<%WebSessionProperties>
2134
2135 C<%WebSessionProperties> is the hash to configure class L</$WebSessionClass>
2136 in case custom class is used. By default it's empty and values are picked
2137 depending on the class. Make sure that it's empty if you're using DB as session
2138 backend.
2139
2140 =cut
2141
2142 Set( %WebSessionProperties );
2143
2144 =item C<$AutoLogoff>
2145
2146 By default, RT's user sessions persist until a user closes his or her
2147 browser. With the C<$AutoLogoff> option you can setup session lifetime
2148 in minutes. A user will be logged out if he or she doesn't send any
2149 requests to RT for the defined time.
2150
2151 =cut
2152
2153 Set($AutoLogoff, 0);
2154
2155 =item C<$LogoutRefresh>
2156
2157 The number of seconds to wait after logout before sending the user to
2158 the login page. By default, 1 second, though you may want to increase
2159 this if you display additional information on the logout page.
2160
2161 =cut
2162
2163 Set($LogoutRefresh, 1);
2164
2165 =item C<$WebSecureCookies>
2166
2167 By default, RT's session cookie isn't marked as "secure". Some web
2168 browsers will treat secure cookies more carefully than non-secure
2169 ones, being careful not to write them to disk, only sending them over
2170 an SSL secured connection, and so on. To enable this behavior, set
2171 C<$WebSecureCookies> to 1.  NOTE: You probably don't want to turn this
2172 on I<unless> users are only connecting via SSL encrypted HTTPS
2173 connections.
2174
2175 =cut
2176
2177 Set($WebSecureCookies, 0);
2178
2179 =item C<$WebHttpOnlyCookies>
2180
2181 Default RT's session cookie to not being directly accessible to
2182 javascript.  The content is still sent during regular and AJAX requests,
2183 and other cookies are unaffected, but the session-id is less
2184 programmatically accessible to javascript.  Turning this off should only
2185 be necessary in situations with odd client-side authentication
2186 requirements.
2187
2188 =cut
2189
2190 Set($WebHttpOnlyCookies, 1);
2191
2192 =item C<$MinimumPasswordLength>
2193
2194 C<$MinimumPasswordLength> defines the minimum length for user
2195 passwords. Setting it to 0 disables this check.
2196
2197 =cut
2198
2199 Set($MinimumPasswordLength, 5);
2200
2201 =back
2202
2203
2204 =head1 Internationalization
2205
2206 =over 4
2207
2208 =item C<@LexiconLanguages>
2209
2210 An array that contains languages supported by RT's
2211 internationalization interface.  Defaults to all *.po lexicons;
2212 setting it to C<qw(en ja)> will make RT bilingual instead of
2213 multilingual, but will save some memory.
2214
2215 =cut
2216
2217 Set(@LexiconLanguages, qw(*));
2218
2219 =item C<@EmailInputEncodings>
2220
2221 An array that contains default encodings used to guess which charset
2222 an attachment uses, if it does not specify one explicitly.  All
2223 options must be recognized by L<Encode::Guess>.  The first element may
2224 also be '*', which enables encoding detection using
2225 L<Encode::Detect::Detector>, if installed.
2226
2227 =cut
2228
2229 Set(@EmailInputEncodings, qw(utf-8 iso-8859-1 us-ascii));
2230
2231 =item C<$EmailOutputEncoding>
2232
2233 The charset for localized email.  Must be recognized by Encode.
2234
2235 =cut
2236
2237 Set($EmailOutputEncoding, "utf-8");
2238
2239 =back
2240
2241
2242
2243
2244
2245
2246
2247 =head1 Date and time handling
2248
2249 =over 4
2250
2251 =item C<$DateTimeFormat>
2252
2253 You can choose date and time format.  See the "Output formatters"
2254 section in perldoc F<lib/RT/Date.pm> for more options.  This option
2255 can be overridden by users in their preferences.
2256
2257 Some examples:
2258
2259 C<Set($DateTimeFormat, "LocalizedDateTime");>
2260 C<Set($DateTimeFormat, { Format => "ISO", Seconds => 0 });>
2261 C<Set($DateTimeFormat, "RFC2822");>
2262 C<Set($DateTimeFormat, { Format => "RFC2822", Seconds => 0, DayOfWeek => 0 });>
2263
2264 =cut
2265
2266 Set($DateTimeFormat, "DefaultFormat");
2267
2268 # Next two options are for Time::ParseDate
2269
2270 =item C<$DateDayBeforeMonth>
2271
2272 Set this to 1 if your local date convention looks like "dd/mm/yy"
2273 instead of "mm/dd/yy". Used only for parsing, not for displaying
2274 dates.
2275
2276 =cut
2277
2278 Set($DateDayBeforeMonth, 1);
2279
2280 =item C<$AmbiguousDayInPast>, C<$AmbiguousDayInFuture>
2281
2282 Should an unspecified day or year in a date refer to a future or a
2283 past value? For example, should a date of "Tuesday" default to mean
2284 the date for next Tuesday or last Tuesday? Should the date "March 1"
2285 default to the date for next March or last March?
2286
2287 Set C<$AmbiguousDayInPast> for the last date, or
2288 C<$AmbiguousDayInFuture> for the next date; the default is usually
2289 correct.  If both are set, C<$AmbiguousDayInPast> takes precedence.
2290
2291 =cut
2292
2293 Set($AmbiguousDayInPast, 0);
2294 Set($AmbiguousDayInFuture, 0);
2295
2296 =item C<$DefaultTimeUnitsToHours>
2297
2298 Use this to set the default units for time entry to hours instead of
2299 minutes.  Note that this only effects entry, not display.
2300
2301 =cut
2302
2303 Set($DefaultTimeUnitsToHours, 0);
2304
2305 =item C<$TimeInICal>
2306
2307 By default, events in the iCal feed on the ticket search page
2308 contain only dates, making them all day calendar events. Set
2309 C<$TimeInICal> if you have start or due dates on tickets that
2310 have significant time values and you want those times to be
2311 included in the events in the iCal feed.
2312
2313 This option can also be set as an individual user preference.
2314
2315 =cut
2316
2317 Set($TimeInICal, 0);
2318
2319 =back
2320
2321
2322
2323 =head1 Cryptography
2324
2325 A complete description of RT's cryptography capabilities can be found in
2326 L<RT::Crypt>. At this moment, GnuPG (PGP) and SMIME security protocols are
2327 supported.
2328
2329 =over 4
2330
2331 =item C<%Crypt>
2332
2333 The following options apply to all cryptography protocols.
2334
2335 By default, all enabled security protocols will analyze each incoming
2336 email. You may set C<Incoming> to a subset of this list, if some enabled
2337 protocols do not apply to incoming mail; however, this is usually
2338 unnecessary. Note that for any verification or decryption to occur for
2339 incoming mail, the C<Auth::Crypt> mail plugin must be added to
2340 L</@MailPlugins> as specified in L<RT::Crypt/Handling incoming messages>.
2341
2342 For outgoing emails, the first security protocol from the above list is
2343 used. Use the C<Outgoing> option to set a security protocol that should
2344 be used in outgoing emails.  At this moment, only one protocol can be
2345 used to protect outgoing emails.
2346
2347 Set C<RejectOnUnencrypted> to 1 if all incoming email must be
2348 properly encrypted.  All unencrypted emails will be rejected by RT.
2349
2350 Set C<RejectOnMissingPrivateKey> to 0 if you don't want to reject
2351 emails encrypted for key RT doesn't have and can not decrypt.
2352
2353 Set C<RejectOnBadData> to 0 if you don't want to reject letters
2354 with incorrect data.
2355
2356 If you want to allow people to encrypt attachments inside the DB then
2357 set C<AllowEncryptDataInDB> to 1.
2358
2359 Set C<Dashboards> to a hash with Encrypt and Sign keys to control
2360 whether dashboards should be encrypted and/or signed correspondingly.
2361 By default they are not encrypted or signed.
2362
2363 =back
2364
2365 =cut
2366
2367 Set( %Crypt,
2368     Incoming                  => undef, # ['GnuPG', 'SMIME']
2369     Outgoing                  => undef, # 'SMIME'
2370
2371     RejectOnUnencrypted       => 0,
2372     RejectOnMissingPrivateKey => 1,
2373     RejectOnBadData           => 1,
2374
2375     AllowEncryptDataInDB      => 0,
2376
2377     Dashboards => {
2378         Encrypt => 0,
2379         Sign    => 0,
2380     },
2381 );
2382
2383 =head2 SMIME configuration
2384
2385 A full description of the SMIME integration can be found in
2386 L<RT::Crypt::SMIME>.
2387
2388 =over 4
2389
2390 =item C<%SMIME>
2391
2392 Set C<Enable> to 0 or 1 to disable or enable SMIME for
2393 encrypting and signing messages.
2394
2395 Set C<OpenSSL> to path to F<openssl> executable.
2396
2397 Set C<Keyring> to directory with key files.  Key and certificates should
2398 be stored in a PEM file in this directory named named, e.g.,
2399 F<email.address@example.com.pem>.
2400
2401 Set C<CAPath> to either a PEM-formatted certificate of a single signing
2402 certificate authority, or a directory of such (including hash symlinks
2403 as created by the openssl tool C<c_rehash>).  Only SMIME certificates
2404 signed by these certificate authorities will be treated as valid
2405 signatures.  If left unset (and C<AcceptUntrustedCAs> is unset, as it is
2406 by default), no signatures will be marked as valid!
2407
2408 Set C<AcceptUntrustedCAs> to allow arbitrary SMIME certificates, no
2409 matter their signing entities.  Such mails will be marked as untrusted,
2410 but signed; C<CAPath> will be used to mark which mails are signed by
2411 trusted certificate authorities.  This configuration is generally
2412 insecure, as it allows the possibility of accepting forged mail signed
2413 by an untrusted certificate authority.
2414
2415 Setting C<AcceptUntrustedCAs> also allows encryption to users with
2416 certificates created by untrusted CAs.
2417
2418 Set C<Passphrase> to a scalar (to use for all keys), an anonymous
2419 function, or a hash (to look up by address).  If the hash is used, the
2420 '' key is used as a default.
2421
2422 See L<RT::Crypt::SMIME> for details.
2423
2424 =back
2425
2426 =cut
2427
2428 Set( %SMIME,
2429     Enable => 0,
2430     OpenSSL => 'openssl',
2431     Keyring => q{var/data/smime},
2432     CAPath => undef,
2433     AcceptUntrustedCAs => undef,
2434     Passphrase => undef,
2435 );
2436
2437 =head2 GnuPG configuration
2438
2439 A full description of the (somewhat extensive) GnuPG integration can
2440 be found by running the command `perldoc L<RT::Crypt::GnuPG>` (or
2441 `perldoc lib/RT/Crypt/GnuPG.pm` from your RT install directory).
2442
2443 =over 4
2444
2445 =item C<%GnuPG>
2446
2447 Set C<Enable> to 0 or 1 to disable or enable GnuPG interfaces
2448 for encrypting and signing outgoing messages.
2449
2450 Set C<GnuPG> to the name or path of the gpg binary to use.
2451
2452 Set C<Passphrase> to a scalar (to use for all keys), an anonymous
2453 function, or a hash (to look up by address).  If the hash is used, the
2454 '' key is used as a default.
2455
2456 Set C<OutgoingMessagesFormat> to 'inline' to use inline encryption and
2457 signatures instead of 'RFC' (GPG/MIME: RFC3156 and RFC1847) format.
2458
2459 =cut
2460
2461 Set(%GnuPG,
2462     Enable                 => 0,
2463     GnuPG                  => 'gpg',
2464     Passphrase             => undef,
2465     OutgoingMessagesFormat => "RFC", # Inline
2466 );
2467
2468 =item C<%GnuPGOptions>
2469
2470 Options to pass to the GnuPG program.
2471
2472 If you override this in your RT_SiteConfig, you should be sure to
2473 include a homedir setting.
2474
2475 Note that options with '-' character MUST be quoted.
2476
2477 =cut
2478
2479 Set(%GnuPGOptions,
2480     homedir => q{var/data/gpg},
2481
2482 # URL of a keyserver
2483 #    keyserver => 'hkp://subkeys.pgp.net',
2484
2485 # enables the automatic retrieving of keys when encrypting
2486 #    'auto-key-locate' => 'keyserver',
2487
2488 # enables the automatic retrieving of keys when verifying signatures
2489 #    'keyserver-options' => 'auto-key-retrieve',
2490 );
2491
2492 =back
2493
2494
2495
2496 =head1 Lifecycles
2497
2498 =head2 Lifecycle definitions
2499
2500 Each lifecycle is a list of possible statuses split into three logic
2501 sets: B<initial>, B<active> and B<inactive>. Each status in a
2502 lifecycle must be unique. (Statuses may not be repeated across sets.)
2503 Each set may have any number of statuses.
2504
2505 For example:
2506
2507     default => {
2508         initial  => ['new'],
2509         active   => ['open', 'stalled'],
2510         inactive => ['resolved', 'rejected', 'deleted'],
2511         ...
2512     },
2513
2514 Status names can be from 1 to 64 ASCII characters.  Statuses are
2515 localized using RT's standard internationalization and localization
2516 system.
2517
2518 =over 4
2519
2520 =item initial
2521
2522 You can define multiple B<initial> statuses for tickets in a given
2523 lifecycle.
2524
2525 RT will automatically set its B<Started> date when you change a
2526 ticket's status from an B<initial> state to an B<active> or
2527 B<inactive> status.
2528
2529 =item active
2530
2531 B<Active> tickets are "currently in play" - they're things that are
2532 being worked on and not yet complete.
2533
2534 =item inactive
2535
2536 B<Inactive> tickets are typically in their "final resting state".
2537
2538 While you're free to implement a workflow that ignores that
2539 description, typically once a ticket enters an inactive state, it will
2540 never again enter an active state.
2541
2542 RT will automatically set the B<Resolved> date when a ticket's status
2543 is changed from an B<Initial> or B<Active> status to an B<Inactive>
2544 status.
2545
2546 B<deleted> is still a special status and protected by the
2547 B<DeleteTicket> right, unless you re-defined rights (read below). If
2548 you don't want to allow ticket deletion at any time simply don't
2549 include it in your lifecycle.
2550
2551 =back
2552
2553 Statuses in each set are ordered and listed in the UI in the defined
2554 order.
2555
2556 Changes between statuses are constrained by transition rules, as
2557 described below.
2558
2559 =head2 Default values
2560
2561 In some cases a default value is used to display in UI or in API when
2562 value is not provided. You can configure defaults using the following
2563 syntax:
2564
2565     default => {
2566         ...
2567         defaults => {
2568             on_create => 'new',
2569             on_resolve => 'resolved',
2570             ...
2571         },
2572     },
2573
2574 The following defaults are used.
2575
2576 =over 4
2577
2578 =item on_create
2579
2580 If you (or your code) doesn't specify a status when creating a ticket,
2581 RT will use the this status. See also L</Statuses available during
2582 ticket creation>.
2583
2584 =item on_merge
2585
2586 When tickets are merged, the status of the ticket that was merged
2587 away is forced to this value.  It should be one of inactive statuses;
2588 'resolved' or its equivalent is most probably the best candidate.
2589
2590 =item approved
2591
2592 When an approval is accepted, the status of depending tickets will
2593 be changed to this value.
2594
2595 =item denied
2596
2597 When an approval is denied, the status of depending tickets will
2598 be changed to this value.
2599
2600 =item reminder_on_open
2601
2602 When a reminder is opened, the status will be changed to this value.
2603
2604 =item reminder_on_resolve
2605
2606 When a reminder is resolved, the status will be changed to this value.
2607
2608 =back
2609
2610 =head2 Transitions between statuses and UI actions
2611
2612 A B<Transition> is a change of status from A to B. You should define
2613 all possible transitions in each lifecycle using the following format:
2614
2615     default => {
2616         ...
2617         transitions => {
2618             ''       => [qw(new open resolved)],
2619             new      => [qw(open resolved rejected deleted)],
2620             open     => [qw(stalled resolved rejected deleted)],
2621             stalled  => [qw(open)],
2622             resolved => [qw(open)],
2623             rejected => [qw(open)],
2624             deleted  => [qw(open)],
2625         },
2626         ...
2627     },
2628
2629 The order of items in the listing for each transition line affects
2630 the order they appear in the drop-down. If you change the config
2631 for 'open' state listing to:
2632
2633     open     => [qw(stalled rejected deleted resolved)],
2634
2635 then the 'resolved' status will appear as the last item in the drop-down.
2636
2637 =head3 Statuses available during ticket creation
2638
2639 By default users can create tickets with a status of new,
2640 open, or resolved, but cannot create tickets with a status of
2641 rejected, stalled, or deleted. If you want to change the statuses
2642 available during creation, update the transition from '' (empty
2643 string), like in the example above.
2644
2645 =head3 Protecting status changes with rights
2646
2647 A transition or group of transitions can be protected by a specific
2648 right.  Additionally, you can name new right names, which will be added
2649 to the system to control that transition.  For example, if you wished to
2650 create a lesser right than ModifyTicket for rejecting tickets, you could
2651 write:
2652
2653     default => {
2654         ...
2655         rights => {
2656             '* -> deleted'  => 'DeleteTicket',
2657             '* -> rejected' => 'RejectTicket',
2658             '* -> *'        => 'ModifyTicket',
2659         },
2660         ...
2661     },
2662
2663 This would create a new C<RejectTicket> right in the system which you
2664 could assign to whatever groups you choose.
2665
2666 On the left hand side you can have the following variants:
2667
2668     '<from> -> <to>'
2669     '* -> <to>'
2670     '<from> -> *'
2671     '* -> *'
2672
2673 Valid transitions are listed in order of priority. If a user attempts
2674 to change a ticket's status from B<new> to B<open> then the lifecycle
2675 is checked for presence of an exact match, then for 'any to B<open>',
2676 'B<new> to any' and finally 'any to any'.
2677
2678 If you don't define any rights, or there is no match for a transition,
2679 RT will use the B<DeleteTicket> or B<ModifyTicket> as appropriate.
2680
2681 =head3 Labeling and defining actions
2682
2683 For each transition you can define an action that will be shown in the
2684 UI; each action annotated with a label and an update type.
2685
2686 Each action may provide a default update type, which can be
2687 B<Comment>, B<Respond>, or absent. For example, you may want your
2688 staff to write a reply to the end user when they change status from
2689 B<new> to B<open>, and thus set the update to B<Respond>.  Neither
2690 B<Comment> nor B<Respond> are mandatory, and user may leave the
2691 message empty, regardless of the update type.
2692
2693 This configuration can be used to accomplish what
2694 $ResolveDefaultUpdateType was used for in RT 3.8.
2695
2696 Use the following format to define labels and actions of transitions:
2697
2698     default => {
2699         ...
2700         actions => [
2701             'new -> open'     => { label => 'Open it', update => 'Respond' },
2702             'new -> resolved' => { label => 'Resolve', update => 'Comment' },
2703             'new -> rejected' => { label => 'Reject',  update => 'Respond' },
2704             'new -> deleted'  => { label => 'Delete' },
2705
2706             'open -> stalled'  => { label => 'Stall',   update => 'Comment' },
2707             'open -> resolved' => { label => 'Resolve', update => 'Comment' },
2708             'open -> rejected' => { label => 'Reject',  update => 'Respond' },
2709
2710             'stalled -> open'  => { label => 'Open it' },
2711             'resolved -> open' => { label => 'Re-open', update => 'Comment' },
2712             'rejected -> open' => { label => 'Re-open', update => 'Comment' },
2713             'deleted -> open'  => { label => 'Undelete' },
2714         ],
2715         ...
2716     },
2717
2718 In addition, you may define multiple actions for the same transition.
2719 Alternately, you may use '* -> x' to match more than one transition.
2720 For example:
2721
2722     default => {
2723         ...
2724         actions => [
2725             ...
2726             'new -> rejected' => { label => 'Reject', update => 'Respond' },
2727             'new -> rejected' => { label => 'Quick Reject' },
2728             ...
2729             '* -> deleted' => { label => 'Delete' },
2730             ...
2731         ],
2732         ...
2733     },
2734
2735 =head2 Moving tickets between queues with different lifecycles
2736
2737 Unless there is an explicit mapping between statuses in two different
2738 lifecycles, you can not move tickets between queues with these
2739 lifecycles -- even if both use the exact same set of statuses.
2740 Such a mapping is defined as follows:
2741
2742     __maps__ => {
2743         'from lifecycle -> to lifecycle' => {
2744             'status in left lifecycle' => 'status in right lifecycle',
2745             ...
2746         },
2747         ...
2748     },
2749
2750 =cut
2751
2752 Set(%Lifecycles,
2753     default => {
2754         initial         => [ 'new' ],
2755         active          => [ 'open', 'stalled' ],
2756         inactive        => [ 'resolved', 'rejected', 'deleted' ],
2757
2758         defaults => {
2759             on_create => 'new',
2760             on_merge  => 'resolved',
2761             approved  => 'open',
2762             denied    => 'rejected',
2763             reminder_on_open     => 'open',
2764             reminder_on_resolve  => 'resolved',
2765         },
2766
2767         transitions => {
2768             ""       => [qw(new open resolved)],
2769
2770             # from   => [ to list ],
2771             new      => [qw(    open stalled resolved rejected deleted)],
2772             open     => [qw(new      stalled resolved rejected deleted)],
2773             stalled  => [qw(new open         rejected resolved deleted)],
2774             resolved => [qw(new open stalled          rejected deleted)],
2775             rejected => [qw(new open stalled resolved          deleted)],
2776             deleted  => [qw(new open stalled rejected resolved        )],
2777         },
2778         rights => {
2779             '* -> deleted'  => 'DeleteTicket',
2780             '* -> *'        => 'ModifyTicket',
2781         },
2782         actions => [
2783             'new -> open'      => { label  => 'Open It', update => 'Respond' }, # loc{label}
2784             'new -> resolved'  => { label  => 'Resolve', update => 'Comment' }, # loc{label}
2785             'new -> rejected'  => { label  => 'Reject',  update => 'Respond' }, # loc{label}
2786             'new -> deleted'   => { label  => 'Delete',                      }, # loc{label}
2787             'open -> stalled'  => { label  => 'Stall',   update => 'Comment' }, # loc{label}
2788             'open -> resolved' => { label  => 'Resolve', update => 'Comment' }, # loc{label}
2789             'open -> rejected' => { label  => 'Reject',  update => 'Respond' }, # loc{label}
2790             'stalled -> open'  => { label  => 'Open It',                     }, # loc{label}
2791             'resolved -> open' => { label  => 'Re-open', update => 'Comment' }, # loc{label}
2792             'rejected -> open' => { label  => 'Re-open', update => 'Comment' }, # loc{label}
2793             'deleted -> open'  => { label  => 'Undelete',                    }, # loc{label}
2794         ],
2795     },
2796 # don't change lifecyle of the approvals, they are not capable to deal with
2797 # custom statuses
2798     approvals => {
2799         initial         => [ 'new' ],
2800         active          => [ 'open', 'stalled' ],
2801         inactive        => [ 'resolved', 'rejected', 'deleted' ],
2802
2803         defaults => {
2804             on_create => 'new',
2805             on_merge => 'resolved',
2806             reminder_on_open     => 'open',
2807             reminder_on_resolve  => 'resolved',
2808         },
2809
2810         transitions => {
2811             ''       => [qw(new open resolved)],
2812
2813             # from   => [ to list ],
2814             new      => [qw(open stalled resolved rejected deleted)],
2815             open     => [qw(new stalled resolved rejected deleted)],
2816             stalled  => [qw(new open rejected resolved deleted)],
2817             resolved => [qw(new open stalled rejected deleted)],
2818             rejected => [qw(new open stalled resolved deleted)],
2819             deleted  => [qw(new open stalled rejected resolved)],
2820         },
2821         rights => {
2822             '* -> deleted'  => 'DeleteTicket',
2823             '* -> rejected' => 'ModifyTicket',
2824             '* -> *'        => 'ModifyTicket',
2825         },
2826         actions => [
2827             'new -> open'      => { label  => 'Open It', update => 'Respond' }, # loc{label}
2828             'new -> resolved'  => { label  => 'Resolve', update => 'Comment' }, # loc{label}
2829             'new -> rejected'  => { label  => 'Reject',  update => 'Respond' }, # loc{label}
2830             'new -> deleted'   => { label  => 'Delete',                      }, # loc{label}
2831             'open -> stalled'  => { label  => 'Stall',   update => 'Comment' }, # loc{label}
2832             'open -> resolved' => { label  => 'Resolve', update => 'Comment' }, # loc{label}
2833             'open -> rejected' => { label  => 'Reject',  update => 'Respond' }, # loc{label}
2834             'stalled -> open'  => { label  => 'Open It',                     }, # loc{label}
2835             'resolved -> open' => { label  => 'Re-open', update => 'Comment' }, # loc{label}
2836             'rejected -> open' => { label  => 'Re-open', update => 'Comment' }, # loc{label}
2837             'deleted -> open'  => { label  => 'Undelete',                    }, # loc{label}
2838         ],
2839     },
2840 );
2841
2842
2843
2844
2845
2846 =head1 Administrative interface
2847
2848 =over 4
2849
2850 =item C<$ShowRTPortal>
2851
2852 RT can show administrators a feed of recent RT releases and other
2853 related announcements and information from Best Practical on the top
2854 level Admin page.  This feature helps you stay up to date on
2855 RT security announcements and version updates.
2856
2857 RT provides this feature using an "iframe" on C</Admin/index.html>
2858 which asks the administrator's browser to show an inline page from
2859 Best Practical's website.
2860
2861 If you'd rather not make this feature available to your
2862 administrators, set C<$ShowRTPortal> to 0.
2863
2864 =cut
2865
2866 Set($ShowRTPortal, 1);
2867
2868 =item C<%AdminSearchResultFormat>
2869
2870 In the admin interface, format strings similar to tickets result
2871 formats are used. Use C<%AdminSearchResultFormat> to define the format
2872 strings used in the admin interface on a per-RT-class basis.
2873
2874 =cut
2875
2876 Set(%AdminSearchResultFormat,
2877     Queues =>
2878         q{'<a href="__WebPath__/Admin/Queues/Modify.html?id=__id__">__id__</a>/TITLE:#'}
2879         .q{,'<a href="__WebPath__/Admin/Queues/Modify.html?id=__id__">__Name__</a>/TITLE:Name'}
2880         .q{,__Description__,__Address__,__Priority__,__DefaultDueIn__,__Lifecycle__,__SubjectTag__,__Disabled__},
2881
2882     Groups =>
2883         q{'<a href="__WebPath__/Admin/Groups/Modify.html?id=__id__">__id__</a>/TITLE:#'}
2884         .q{,'<a href="__WebPath__/Admin/Groups/Modify.html?id=__id__">__Name__</a>/TITLE:Name'}
2885         .q{,'__Description__',__Disabled__},
2886
2887     Users =>
2888         q{'<a href="__WebPath__/Admin/Users/Modify.html?id=__id__">__id__</a>/TITLE:#'}
2889         .q{,'<a href="__WebPath__/Admin/Users/Modify.html?id=__id__">__Name__</a>/TITLE:Name'}
2890         .q{,__RealName__, __EmailAddress__,__Disabled__},
2891
2892     CustomFields =>
2893         q{'<a href="__WebPath__/Admin/CustomFields/Modify.html?id=__id__">__id__</a>/TITLE:#'}
2894         .q{,'<a href="__WebPath__/Admin/CustomFields/Modify.html?id=__id__">__Name__</a>/TITLE:Name'}
2895         .q{,__AddedTo__, __FriendlyType__, __FriendlyPattern__,__Disabled__},
2896
2897     Scrips =>
2898         q{'<a href="__WebPath__/Admin/Scrips/Modify.html?id=__id____From__">__id__</a>/TITLE:#'}
2899         .q{,'<a href="__WebPath__/Admin/Scrips/Modify.html?id=__id____From__">__Description__</a>/TITLE:Description'}
2900         .q{,__Condition__, __Action__, __Template__, __Disabled__},
2901
2902     Templates =>
2903         q{'<a href="__WebPath__/__WebRequestPathDir__/Template.html?Queue=__QueueId__&Template=__id__">__id__</a>/TITLE:#'}
2904         .q{,'<a href="__WebPath__/__WebRequestPathDir__/Template.html?Queue=__QueueId__&Template=__id__">__Name__</a>/TITLE:Name'}
2905         .q{,'__Description__','__UsedBy__','__IsEmpty__'},
2906     Classes =>
2907         q{ '<a href="__WebPath__/Admin/Articles/Classes/Modify.html?id=__id__">__id__</a>/TITLE:#'}
2908         .q{,'<a href="__WebPath__/Admin/Articles/Classes/Modify.html?id=__id__">__Name__</a>/TITLE:Name'}
2909         .q{,__Description__,__Disabled__},
2910 );
2911
2912 =item C<%AdminSearchResultRows>
2913
2914 Use C<%AdminSearchResultRows> to define the search result rows in the admin
2915 interface on a per-RT-class basis.
2916
2917 =cut
2918
2919 Set(%AdminSearchResultRows,
2920     Queues       => 50,
2921     Groups       => 50,
2922     Users        => 50,
2923     CustomFields => 50,
2924     Scrips       => 50,
2925     Templates    => 50,
2926     Classes      => 50,
2927 );
2928
2929 =back
2930
2931
2932
2933
2934 =head1 Development options
2935
2936 =over 4
2937
2938 =item C<$DevelMode>
2939
2940 RT comes with a "Development mode" setting.  This setting, as a
2941 convenience for developers, turns on several of development options
2942 that you most likely don't want in production:
2943
2944 =over 4
2945
2946 =item *
2947
2948 Disables CSS and JS minification and concatenation.  Both CSS and JS
2949 will be instead be served as a number of individual smaller files,
2950 unchanged from how they are stored on disk.
2951
2952 =item *
2953
2954 Uses L<Module::Refresh> to reload changed Perl modules on each
2955 request.
2956
2957 =item *
2958
2959 Turns off Mason's C<static_source> directive; this causes Mason to
2960 reload template files which have been modified on disk.
2961
2962 =item *
2963
2964 Turns on Mason's HTML C<error_format>; this renders compilation errors
2965 to the browser, along with a full stack trace.  It is possible for
2966 stack traces to reveal sensitive information such as passwords or
2967 ticket content.
2968
2969 =item *
2970
2971 Turns off caching of callbacks; this enables additional callbacks to
2972 be added while the server is running.
2973
2974 =back
2975
2976 =cut
2977
2978 Set($DevelMode, 0);
2979
2980
2981 =item C<$RecordBaseClass>
2982
2983 What abstract base class should RT use for its records. You should
2984 probably never change this.
2985
2986 Valid values are C<DBIx::SearchBuilder::Record> or
2987 C<DBIx::SearchBuilder::Record::Cachable>
2988
2989 =cut
2990
2991 Set($RecordBaseClass, "DBIx::SearchBuilder::Record::Cachable");
2992
2993
2994 =item C<@MasonParameters>
2995
2996 C<@MasonParameters> is the list of parameters for the constructor of
2997 HTML::Mason's Apache or CGI Handler.  This is normally only useful for
2998 debugging, e.g. profiling individual components with:
2999
3000     use MasonX::Profiler; # available on CPAN
3001     Set(@MasonParameters, (preamble => 'my $p = MasonX::Profiler->new($m, $r);'));
3002
3003 =cut
3004
3005 Set(@MasonParameters, ());
3006
3007 =item C<$StatementLog>
3008
3009 RT has rudimentary SQL statement logging support; simply set
3010 C<$StatementLog> to be the level that you wish SQL statements to be
3011 logged at.
3012
3013 Enabling this option will also expose the SQL Queries page in the
3014 Admin -> Tools menu for SuperUsers.
3015
3016 =cut
3017
3018 Set($StatementLog, undef);
3019
3020 =back
3021
3022 =cut
3023
3024 1;