; this option overrides C<$PlainTextMono>.

=cut

Set($PlainTextPre, 0);

=item C<$PlainTextMono>

Set C<$PlainTextMono> to 1 to use monospaced font and preserve
formatting; unlike C<$PlainTextPre>, the text will wrap to fit width
of the browser window.

=cut

Set($PlainTextMono, 0);

=item C<$SuppressInlineTextFiles>

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

=cut

Set($SuppressInlineTextFiles, undef);

=item C<@Active_MakeClicky>

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

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

* 'httpurl_overwrite': also detects URLs as 'httpurl' format, but
  replaces the URL with a link and *adds spaces* into the text if it
  is longer then 30 characters. This allows the browser to wrap long
  URLs and avoid horizontal scrolling.

See F for documentation on how to add
your own styles of link detection.

=cut

Set(@Active_MakeClicky, qw());

=back

=head1 Application logic

=over 4

=item C<$ParseNewMessageForTicketCcs>

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

=cut

Set($ParseNewMessageForTicketCcs, undef);

=item C<$UseTransactionBatch>

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

=cut

Set($UseTransactionBatch, 1);

=item C<$StrictLinkACL>

When this feature is enabled a user needs I rights on
both tickets to link them together; otherwise, I rights
on either of them is sufficient.

=cut

Set($StrictLinkACL, 1);

=item C<$RedistributeAutoGeneratedMessages>

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

=cut

Set($RedistributeAutoGeneratedMessages, "privileged");

=item C<$ApprovalRejectionNotes>

Should rejection notes from approvals be sent to the requestors?

=back

=cut

Set($ApprovalRejectionNotes, 1);

=head1 Extra security

=over 4

This is a list of extra security measures to enable that help keep your RT
safe.  If you don't know what these mean, you should almost certainly leave the
defaults alone.

=item C<$DisallowExecuteCode>

If set to a true value, the C right will be removed from
all users, B the superuser.  This is intended for when RT is
installed into a shared environment where even the superuser should not
be allowed to run arbitrary Perl code on the server via scrips.

=cut

Set($DisallowExecuteCode, 0);

=item C<$Framebusting>

If set to a false value, framekiller javascript will be disabled and the
X-Frame-Options: DENY header will be suppressed from all responses.
This disables RT's clickjacking protection.

=cut

Set($Framebusting, 1);

=back

=head1 Authorization and user configuration

=over 4

=item C<$WebExternalAuth>

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

=cut

Set($WebExternalAuth, undef);

=item C<$WebExternalAuthContinuous>

If C<$WebExternalAuthContinuous> is defined, RT will check for the
REMOTE_USER on each access.  If you would prefer this to only happen
once (at initial login) set this to a false value.  The default
setting will help ensure that if your external authentication system
deauthenticates a user, RT notices as soon as possible.

=cut

Set($WebExternalAuthContinuous, 1);

=item C<$WebFallbackToInternalAuth>

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

=cut

Set($WebFallbackToInternalAuth, undef);

=item C<$WebExternalGecos>

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

=cut

Set($WebExternalGecos, undef);

=item C<$WebExternalAuto>

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

=cut

Set($WebExternalAuto, undef);

=item C<$AutoCreate>

If C<$WebExternalAuto> is set to 1, C<$AutoCreate> will be passed to
User's Create method.  Use it to set defaults, such as creating
Unprivileged users with C<{ Privileged => 0 }> This must be a hashref.

=cut

Set($AutoCreate, undef);

=item C<$WebSessionClass>

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

=cut

# Set($WebSessionClass, "Apache::Session::File");

=item C<$AutoLogoff>

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

=cut

Set($AutoLogoff, 0);

=item C<$LogoutRefresh>

The number of seconds to wait after logout before sending the user to
the login page. By default, 1 second, though you may want to increase
this if you display additional information on the logout page.

=cut

Set($LogoutRefresh, 1);

=item C<$WebSecureCookies>

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

=cut

Set($WebSecureCookies, 0);

=item C<$MinimumPasswordLength>

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

=cut

Set($MinimumPasswordLength, 5);

=back

=head1 Internationalization

=over 4

=item C<@LexiconLanguages>

An array that contains languages supported by RT's
internationalization interface.  Defaults to all *.po lexicons;
setting it to C will make RT bilingual instead of
multilingual, but will save some memory.

=cut

Set(@LexiconLanguages, qw(*));

=item C<@EmailInputEncodings>

An array that contains default encodings used to guess which charset
an attachment uses, if it does not specify one explicitly.  All
options must be recognized by L.  The first element may
also be '*', which enables encoding detection using
L, if installed.

=cut

Set(@EmailInputEncodings, qw(utf-8 iso-8859-1 us-ascii));

=item C<$EmailOutputEncoding>

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

=cut

Set($EmailOutputEncoding, "utf-8");

=back

=head1 Date and time handling

=over 4

=item C<$DateTimeFormat>

You can choose date and time format.  See the "Output formatters"
section in perldoc F for more options.  This option
can be overridden by users in their preferences.

Some examples:

C
C "ISO", Seconds => 0 });>
C
C "RFC2822", Seconds => 0, DayOfWeek => 0 });>

=cut

Set($DateTimeFormat, "DefaultFormat");

# Next two options are for Time::ParseDate

=item C<$DateDayBeforeMonth>

Set this to 1 if your local date convention looks like "dd/mm/yy"
instead of "mm/dd/yy". Used only for parsing, not for displaying
dates.

=cut

Set($DateDayBeforeMonth, 1);

=item C<$AmbiguousDayInPast>, C<$AmbiguousDayInFuture>

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

Set C<$AmbiguousDayInPast> for the last date, or
C<$AmbiguousDayInFuture> for the next date; the default is usually
correct.  If both are set, C<$AmbiguousDayInPast> takes precedence.

=cut

Set($AmbiguousDayInPast, 0);
Set($AmbiguousDayInFuture, 0);

=item C<$DefaultTimeUnitsToHours>

Use this to set the default units for time entry to hours instead of
minutes.  Note that this only effects entry, not display.

=cut

Set($DefaultTimeUnitsToHours, 0);

=back

=head1 GnuPG integration

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

=over 4

=item C<%GnuPG>

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

If you want to allow people to encrypt attachments inside the DB then
set C to 1.

Set C to false if you don't want to reject
emails encrypted for key RT doesn't have and can not decrypt.

Set C to false if you don't want to reject letters
with incorrect GnuPG data.

=cut

Set(%GnuPG,
    Enable => 1,
    OutgoingMessagesFormat => "RFC", # Inline
    AllowEncryptDataInDB   => 0,

    RejectOnMissingPrivateKey => 1,
    RejectOnBadData           => 1,
);

=item C<%GnuPGOptions>

Options to pass to the GnuPG program.

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

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

=cut

Set(%GnuPGOptions,
    homedir => q{var/data/gpg},

# URL of a keyserver
#    keyserver => 'hkp://subkeys.pgp.net',

# enables the automatic retrieving of keys when encrypting
#    'auto-key-locate' => 'keyserver',

# enables the automatic retrieving of keys when verifying signatures
#    'auto-key-retrieve' => undef,
);

=back

=head1 Lifecycles

=head2 Lifecycle definitions

Each lifecycle is a list of possible statuses split into three logic
sets: B, B and B. Each status in a
lifecycle must be unique. (Statuses may not be repeated across sets.)
Each set may have any number of statuses.

For example:

    default => {
        initial  => ['new'],
        active   => ['open', 'stalled'],
        inactive => ['resolved', 'rejected', 'deleted'],
        ...
    },

Status names can be from 1 to 64 ASCII characters.  Statuses are
localized using RT's standard internationalization and localization
system.

=over 4

=item initial

You can define multiple B statuses for tickets in a given
lifecycle.

RT will automatically set its B date when you change a
ticket's status from an B state to an B or
B status.

=item active

B tickets are "currently in play" - they're things that are
being worked on and not yet complete.

=item inactive

B tickets are typically in their "final resting state".

While you're free to implement a workflow that ignores that
description, typically once a ticket enters an inactive state, it will
never again enter an active state.

RT will automatically set the B date when a ticket's status
is changed from an B or B status to an B
status.

B is still a special status and protected by the
B right, unless you re-defined rights (read below). If
you don't want to allow ticket deletion at any time simply don't
include it in your lifecycle.

=back

Statuses in each set are ordered and listed in the UI in the defined
order.

Changes between statuses are constrained by transition rules, as
described below.

=head2 Default values

In some cases a default value is used to display in UI or in API when
value is not provided. You can configure defaults using the following
syntax:

    default => {
        ...
        defaults => {
            on_create => 'new',
            on_resolve => 'resolved',
            ...
        },
    },

The following defaults are used.

=over 4

=item on_create

If you (or your code) doesn't specify a status when creating a ticket,
RT will use the this status. See also L.

=item on_merge

When tickets are merged, the status of the ticket that was merged
away is forced to this value.  It should be one of inactive statuses;
'resolved' or its equivalent is most probably the best candidate.

=item approved

When an approval is accepted, the status of depending tickets will
be changed to this value.

=item denied

When an approval is denied, the status of depending tickets will
be changed to this value.

=back

=head2 Transitions between statuses and UI actions

A B is a change of status from A to B. You should define
all possible transitions in each lifecycle using the following format:

    default => {
        ...
        transitions => {
            ''       => [qw(new open resolved)],
            new      => [qw(open resolved rejected deleted)],
            open     => [qw(stalled resolved rejected deleted)],
            stalled  => [qw(open)],
            resolved => [qw(open)],
            rejected => [qw(open)],
            deleted  => [qw(open)],
        },
        ...
    },

=head3 Statuses available during ticket creation

By default users can create tickets with any status, except
deleted. If you want to restrict statuses available during creation
then describe transition from '' (empty string), like in the example
above.

=head3 Protecting status changes with rights

A transition or group of transitions can be protected by a specific
right.  Additionally, you can name new right names, which will be added
to the system to control that transition.  For example, if you wished to
create a lesser right than ModifyTicket for rejecting tickets, you could
write:

    default => {
        ...
        rights => {
            '* -> deleted'  => 'DeleteTicket',
            '* -> rejected' => 'RejectTicket',
            '* -> *'        => 'ModifyTicket',
        },
        ...
    },

This would create a new C right in the system which you
could assign to whatever groups you choose.

On the left hand side you can have the following variants:

    ' -> '
    '* -> '
    ' -> *'
    '* -> *'

Valid transitions are listed in order of priority. If a user attempts
to change a ticket's status from B to B then the lifecycle
is checked for presence of an exact match, then for 'any to B',
'B to any' and finally 'any to any'.

If you don't define any rights, or there is no match for a transition,
RT will use the B or B as appropriate.

=head3 Labeling and defining actions

For each transition you can define an action that will be shown in the
UI; each action annotated with a label and an update type.

Each action may provide a default update type, which can be
B, B, or absent. For example, you may want your
staff to write a reply to the end user when they change status from
B to B, and thus set the update to B.  Neither
B nor B are mandatory, and user may leave the
message empty, regardless of the update type.

This configuration can be used to accomplish what
$ResolveDefaultUpdateType was used for in RT 3.8.

Use the following format to define labels and actions of transitions:

    default => {
        ...
        actions => [
            'new -> open'     => { label => 'Open it', update => 'Respond' },
            'new -> resolved' => { label => 'Resolve', update => 'Comment' },
            'new -> rejected' => { label => 'Reject',  update => 'Respond' },
            'new -> deleted'  => { label => 'Delete' },

            'open -> stalled'  => { label => 'Stall',   update => 'Comment' },
            'open -> resolved' => { label => 'Resolve', update => 'Comment' },
            'open -> rejected' => { label => 'Reject',  update => 'Respond' },

            'stalled -> open'  => { label => 'Open it' },
            'resolved -> open' => { label => 'Re-open', update => 'Comment' },
            'rejected -> open' => { label => 'Re-open', update => 'Comment' },
            'deleted -> open'  => { label => 'Undelete' },
        ],
        ...
    },

In addition, you may define multiple actions for the same transition.
Alternately, you may use '* -> x' to match more than one transition.
For example:

    default => {
        ...
        actions => [
            ...
            'new -> rejected' => { label => 'Reject', update => 'Respond' },
            'new -> rejected' => { label => 'Quick Reject' },
            ...
            '* -> deleted' => { label => 'Delete' },
            ...
        ],
        ...
    },

=head2 Moving tickets between queues with different lifecycles

Unless there is an explicit mapping between statuses in two different
lifecycles, you can not move tickets between queues with these
lifecycles.  Such a mapping is defined as follows:

    __maps__ => {
        'from lifecycle -> to lifecycle' => {
            'status in left lifecycle' => 'status in right lifecycle',
            ...
        },
        ...
    },

=cut

Set(%Lifecycles,
    default => {
        initial         => [ 'new' ],
        active          => [ 'open', 'stalled' ],
        inactive        => [ 'resolved', 'rejected', 'deleted' ],

        defaults => {
            on_create => 'new',
            on_merge  => 'resolved',
            approved  => 'open',
            denied    => 'rejected',
        },

        transitions => {
            ''       => [qw(new open resolved)],

            # from   => [ to list ],
            new      => [qw(open stalled resolved rejected deleted)],
            open     => [qw(new stalled resolved rejected deleted)],
            stalled  => [qw(new open rejected resolved deleted)],
            resolved => [qw(new open stalled rejected deleted)],
            rejected => [qw(new open stalled resolved deleted)],
            deleted  => [qw(new open stalled rejected resolved)],
        },
        rights => {
            '* -> deleted'  => 'DeleteTicket',
            '* -> *'        => 'ModifyTicket',
        },
        actions => [
            'new -> open'      => {
                label  => 'Open It', # loc
                update => 'Respond',
            },
            'new -> resolved'  => {
                label  => 'Resolve', # loc
                update => 'Comment',
            },
            'new -> rejected'  => {
                label  => 'Reject', # loc
                update => 'Respond',
            },
            'new -> deleted'   => {
                label  => 'Delete', # loc
            },

            'open -> stalled'  => {
                label  => 'Stall', # loc
                update => 'Comment',
            },
            'open -> resolved' => {
                label  => 'Resolve', # loc
                update => 'Comment',
            },
            'open -> rejected' => {
                label  => 'Reject', # loc
                update => 'Respond',
            },

            'stalled -> open'  => {
                label  => 'Open It', # loc
            },
            'resolved -> open' => {
                label  => 'Re-open', # loc
                update => 'Comment',
            },
            'rejected -> open' => {
                label  => 'Re-open', # loc
                update => 'Comment',
            },
            'deleted -> open'  => {
                label  => 'Undelete', # loc
            },
        ],
    },
# don't change lifecyle of the approvals, they are not capable to deal with
# custom statuses
    approvals => {
        initial         => [ 'new' ],
        active          => [ 'open', 'stalled' ],
        inactive        => [ 'resolved', 'rejected', 'deleted' ],

        defaults => {
            on_create => 'new',
            on_merge => 'resolved',
        },

        transitions => {
            ''       => [qw(new open resolved)],

            # from   => [ to list ],
            new      => [qw(open stalled resolved rejected deleted)],
            open     => [qw(new stalled resolved rejected deleted)],
            stalled  => [qw(new open rejected resolved deleted)],
            resolved => [qw(new open stalled rejected deleted)],
            rejected => [qw(new open stalled resolved deleted)],
            deleted  => [qw(new open stalled rejected resolved)],
        },
        rights => {
            '* -> deleted'  => 'DeleteTicket',
            '* -> rejected' => 'ModifyTicket',
            '* -> *'        => 'ModifyTicket',
        },
        actions => [
            'new -> open'      => {
                label  => 'Open It', # loc
                update => 'Respond',
            },
            'new -> resolved'  => {
                label  => 'Resolve', # loc
                update => 'Comment',
            },
            'new -> rejected'  => {
                label  => 'Reject', # loc
                update => 'Respond',
            },
            'new -> deleted'   => {
                label  => 'Delete', # loc
            },

            'open -> stalled'  => {
                label  => 'Stall', # loc
                update => 'Comment',
            },
            'open -> resolved' => {
                label  => 'Resolve', # loc
                update => 'Comment',
            },
            'open -> rejected' => {
                label  => 'Reject', # loc
                update => 'Respond',
            },

            'stalled -> open'  => {
                label  => 'Open It', # loc
            },
            'resolved -> open' => {
                label  => 'Re-open', # loc
                update => 'Comment',
            },
            'rejected -> open' => {
                label  => 'Re-open', # loc
                update => 'Comment',
            },
            'deleted -> open'  => {
                label  => 'Undelete', # loc
            },
        ],
    },
);

=head1 Administrative interface

=over 4

=item C<$ShowRTPortal>

RT can show administrators a feed of recent RT releases and other
related announcements and information from Best Practical on the top
level Configuration page.  This feature helps you stay up to date on
RT security announcements and version updates.

RT provides this feature using an "iframe" on C
which asks the administrator's browser to show an inline page from
Best Practical's website.

If you'd rather not make this feature available to your
administrators, set C<$ShowRTPortal> to a false value.

=cut

Set($ShowRTPortal, 1);

=item C<%AdminSearchResultFormat>

In the admin interface, format strings similar to tickets result
formats are used. Use C<%AdminSearchResultFormat> to define the format
strings used in the admin interface on a per-RT-class basis.

=cut

Set(%AdminSearchResultFormat,
    Queues =>
        q{'__id__/TITLE:#'}
        .q{,'__Name__/TITLE:Name'}
        .q{,__Description__,__Address__,__Priority__,__DefaultDueIn__,__Disabled__},

    Groups =>
        q{'__id__/TITLE:#'}
        .q{,'__Name__/TITLE:Name'}
        .q{,'__Description__'},

    Users =>
        q{'__id__/TITLE:#'}
        .q{,'__Name__/TITLE:Name'}
        .q{,__RealName__, __EmailAddress__},

    CustomFields =>
        q{'__id__/TITLE:#'}
        .q{,'__Name__/TITLE:Name'}
        .q{,__AppliedTo__, __FriendlyType__, __FriendlyPattern__},

    Scrips =>
        q{'__id__/TITLE:#'}
        .q{,'__Description__/TITLE:Description'}
        .q{,__Stage__, __Condition__, __Action__, __Template__},

    Templates =>
        q{'__id__/TITLE:#'}
        .q{,'__Name__/TITLE:Name'}
        .q{,'__Description__'},
    Classes =>
        q{ '__id__/TITLE:#'}
        .q{,'__Name__/TITLE:Name'}
        .q{,__Description__},
);

=back

=head1 Development options

=over 4

=item C<$DevelMode>

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

=over 4

=item *

Uses L to reload changed Perl modules on each
request.

=item *

Turns off Mason's C directive; this causes Mason to
reload template files which have been modified on disk.

=item *

Turns on Mason's HTML C; this renders compilation errors
to the browser, along with a full stack trace.  It is possible for
stack traces to reveal sensitive information such as passwords or
ticket content.

=item *

Turns off caching of callbacks; this enables additional callbacks to
be added while the server is running.

=back

=cut

Set($DevelMode, "0");

=item C<$RecordBaseClass>

What abstract base class should RT use for its records. You should
probably never change this.

Valid values are C or
C

=cut

Set($RecordBaseClass, "DBIx::SearchBuilder::Record::Cachable");

=item C<@MasonParameters>

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

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

=cut

Set(@MasonParameters, ());

=item C<$StatementLog>

RT has rudimentary SQL statement logging support; simply set
C<$StatementLog> to be the level that you wish SQL statements to be
logged at.

Enabling this option will also expose the SQL Queries page in the
Configuration -> Tools menu for SuperUsers.

=cut

Set($StatementLog, undef);

=back

=head1 Deprecated options

=over 4

=item C<$LinkTransactionsRun1Scrip>

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

=cut

Set($LinkTransactionsRun1Scrip, 0);

# The order in which the services defined in ExternalSettings
# should be used to authenticate users. User is authenticated
# if successfully confirmed by any service - no more services
# are checked.
Set($ExternalAuthPriority,  [   'My_LDAP',
                                'My_MySQL',
                                'My_SSO_Cookie'
                            ]
);

# The order in which the services defined in ExternalSettings
# should be used to get information about users. This includes
# RealName, Tel numbers etc, but also whether or not the user
# should be considered disabled. 
#
# Once user info is found, no more services are checked.
#
# You CANNOT use a SSO cookie for authentication.
Set($ExternalInfoPriority,  [   'My_MySQL',
                                'My_LDAP'
                            ]
);

# If this is set to true, then the relevant packages will
# be loaded to use SSL/TLS connections. At the moment,
# this just means "use Net::SSLeay;"
Set($ExternalServiceUsesSSLorTLS,    0);

# If this is set to 1, then users should be autocreated by RT
# as internal users if they fail to authenticate from an
# external service.
Set($AutoCreateNonExternalUsers,    1);

# These are the full settings for each external service as a HashOfHashes
# Note that you may have as many external services as you wish. They will
# be checked in the order specified in the Priority directives above.
# e.g. 
#   Set(ExternalAuthPriority,['My_LDAP','My_MySQL','My_Oracle','SecondaryLDAP','Other-DB']);
#
Set($ExternalSettings,      {   
                                # AN EXAMPLE LDAP SERVICE
                                'My_LDAP'       =>  {   ## GENERIC SECTION
                                                        # The type of service (db/ldap/cookie) 
                                                        'type'                      =>  'ldap',
                                                        # The server hosting the service
                                                        'server'                    =>  'ldap01.example.com',
                                                        ## SERVICE-SPECIFIC SECTION
                                                        # If you can bind to your LDAP server anonymously you should 
                                                        # remove the user and pass config lines, otherwise specify them here:
                                                        # 
                                                        # The username RT should use to connect to the LDAP server 
                                                        #'user'                      =>  'uid=Dunphy,ou=People,cn=mlbam,cn=com',
                                                        # The password RT should use to connect to the LDAP server
                                                        #'pass'                    =>  'secret',
                                                        #
                                                        # The LDAP search base
                                                        'base'                      =>  'ou=People,dc=example,dc=com',
                                                        #
                                                        # ALL FILTERS MUST BE VALID LDAP FILTERS ENCASED IN PARENTHESES!
                                                        # YOU **MUST** SPECIFY A filter AND A d_filter!!
                                                        #
                                                        # The filter to use to match RT-Users
                                                        'filter'                    =>  '(objectclass=*)',
                                                        # A catch-all example filter: '(objectClass=*)'
                                                        #
                                                        # The filter that will only match disabled users
                                                        'd_filter'                  =>  '(objectClass=FooBarBaz)',
                                                        # A catch-none example d_filter: '(objectClass=FooBarBaz)'
                                                        #
                                                        # Should we try to use TLS to encrypt connections?
                                                        'tls'                       =>  0,
                                                        # SSL Version to provide to Net::SSLeay *if* using SSL
                                                        #'ssl_version'               =>  2,
                                                        # What other args should I pass to Net::LDAP->new($host, at args)?
                                                        'net_ldap_args'             => [    version =>  3   ],
                                                        # Does authentication depend on group membership? What group name?
                                                        #'group'                     =>  'RTUsers',
                                                        # What is the attribute for the group object that determines membership?
                                                        #'group_attr'                =>  'cn',
                                                        ## RT ATTRIBUTE MATCHING SECTION
                                                        # The list of RT attributes that uniquely identify a user
							# This example shows what you *can* specify.. I recommend reducing this
                                                        # to just the Name and EmailAddress to save encountering problems later.
                                                        'attr_match_list'           => [    'Name',
                                                                                            'EmailAddress', 
                                                                                        ],
                                                        # The mapping of RT attributes on to LDAP attributes
                                                        'attr_map'                  =>  {   'Name' => 'uid',
                                                                                            'EmailAddress' => 'mail',
                                                                                        }
                                                    },
                                # An example SSO cookie service
                                'My_SSO_Cookie'  => {   # # The type of service (db/ldap/cookie)
                                                        'type'                      =>  'cookie',
                                                        # The name of the cookie to be used
                                                        'name'                      =>  'loginCookieValue',
                                                        # The users table
                                                        'u_table'                   =>  'users',
                                                        # The username field in the users table
                                                        'u_field'                   =>  'username',
                                                        # The field in the users table that uniquely identifies a user
                                                        # and also exists in the cookies table
                                                        'u_match_key'               =>  'userID',
                                                        # The cookies table
                                                        'c_table'                   =>  'login_cookie',
                                                        # The field that stores cookie values
                                                        'c_field'                   =>  'loginCookieValue',
                                                        # The field in the cookies table that uniquely identifies a user
                                                        # and also exists in the users table
                                                        'c_match_key'               =>  'loginCookieUserID',
                                                        # The DB service in this configuration to use to lookup the cookie information
                                                        'db_service_name'           =>  'My_MySQL'
                                                    }
                                }
);

1;

Set($LogToFile,      'debug');
Set($LogToFileNamed, 'rt.log');
Set($LogDir,         '/usr/local/rt4/var/log');

1;

---------

thank you very much for any advice you may have!

tim

From trs at bestpractical.com  Tue Jan 31 21:30:52 2012
From: trs at bestpractical.com (Thomas Sibley)
Date: Tue, 31 Jan 2012 21:30:52 -0500
Subject: [rt-users] [rt-devel] RT 4.0.5rc1 Released
In-Reply-To: <2B3D699B434F1F49B73F97861B5FD5446FB44D9E@Mail-DB-1.letnet.net>
References: <20120125154445.GB5133@jibsheet.com>
	<2B3D699B434F1F49B73F97861B5FD5446FB44D9E@Mail-DB-1.letnet.net>
Message-ID: <4F28A3DC.1070005@bestpractical.com>

On 01/31/2012 09:57 AM, Roedel, Mark wrote:
> Working well for us so far -- I really like the new look for dashboard emails.

I don't think the dashboard emails have changed since 4.0.4.  Are you
comparing to a different version?  If not, I'd be curious to see what
change you're talking about.  ;)

Thomas

From tooru at kk.iij4u.or.jp  Tue Jan 31 23:32:30 2012
From: tooru at kk.iij4u.or.jp (Toru)
Date: Wed, 01 Feb 2012 13:32:30 +0900
	=?iso-2022-jp?B?KBskQkVsNX4bKEIgKBskQkk4PWA7fhsoQikp?=
Subject: [rt-users] Full text search problem on sphinx v4.0.4
Message-ID: <20120201.133230.262170999.tooru@kk.iij4u.or.jp>

Greetings,

I am testing rt v4.0.4 with mysql(compiled with sphinx capability) and having 
some trouble in full text searching. 

Here are some sample search queries from rt.

- Case1: full text search ok with returning right results.

------------------------------------------------------------------------------
( Content LIKE 'aaaa' ) AND ( Status = 'new' OR Status = 'open' OR Status = 'stalled' )

( Content LIKE 'aaaa' OR  Content LIKE 'bbbb') AND ( Status = 'new' OR Status = 'open' OR Status = 'stalled' )
------------------------------------------------------------------------------

- Case2: full text search  "not" ok returning no results and  rt seems  not sending any search query through sphinx.(no result log in sphinx's query.log)

------------------------------------------------------------------------------
( Content LIKE 'aaaa' AND Content LIKE 'bbbb' ) AND ( Status = 'new' OR Status = 'open' OR Status = 'stalled' )
------------------------------------------------------------------------------

I checked both search queries without fulltext configuration and Case1 and 2 both seems returning ok result.

My v4.0.4 environment is as follow,

- rt   v4.0.4
- perl v5.14.2
- mysql v5.1.61
- sphinx 2.0.3

My configurations (sphinx.conf and RT_SiteConfig.pm) are almost default setting and I haven't done any customization of rt codes.

Any clues?

Toru