Admin: 3 revisions imported

2016-04-06T20:03:15Z

3 revisions imported

New page

= Using LDAP and custom fields to approximate separate queues =

We use Request Tracker in our school system across eight separate elementary and secondary schools. All tickets feed into a single "Incidents" queue, but each building has its own technician, and I want RT to notify the building tech when a staff member from that building submits a ticket. The process proceeds in two distinct steps:

# Query our LDAP server to set a ticket custom field that identifies the requestor's school
# Based on the value of that custom field, notify the tech (or techs) at that school.

== Step 1: Set the custom field ==

I created a new scrip called "Set Building CF from LDAP" with the following settings:

'''Condition:''' On Create

'''Action:''' User Defined

'''Template:''' Global template: Blank

'''Custom action preparation code:''' <code>return 1;</code>

'''Custom action cleanup code:'''

<nowiki>my $mail = ($self->TicketObj->RequestorAddresses)[0];
my $ldap = Net::LDAP->new( '10.1.10.230' );
$ldap->bind;

# Do the LDAP search. Note: Our eDirectory server uses "mail" for the
# user's email address.
my $msg = $ldap->search( base => 'ou=Staff,o=Example',
filter => "(mail=$mail)",
);
my $entry = $msg->entry(0);
# Each user is a member of an ou which corresponds to his or her school
my $ou = $entry->get_value('ou');

# The value of the ou isn't what I want to put in the custom field so
# map the ou value to the corresponding custom field value.
my %building_for = (
'DISTRICT SERVICES' => 'DO',
'HIGH SCHOOL' => 'BHS',
'MIDDLE SCHOOL' => 'BCMS',
'LINCOLN' => 'LES',
'_DEFAULT_' => 'DO',
);
my $building = $building_for{$ou} || $building_for{_DEFAULT_};

my $cf = RT::CustomField->new( $RT::SystemUser );
$cf->LoadByName( Name => 'Building' );
$self->TicketObj->AddCustomFieldValue( Field => $cf, Value => $building );

return 1;

</nowiki>

With this scrip in place, every incoming ticket has its "Building" custom field set to the requestor's school.

== Step 2: Notify the building tech ==

I created a second scrip to trigger whenever the "Building" custom field is changed. It has these settings:

'''Description:''' Notify techs of new tickets

'''Condition:''' User Defined

'''Action:''' Notify Other Recipients

'''Template:''' Building Tech Notify

The custom condition code looks like this:

unless (
( $self->TransactionObj->Type eq "CustomField"
&& $self->TransactionObj->Field == 10 )
|| $self->TransactionObj->Type eq "Create"
) {
return 0;
}

1;

More information about triggering scrips on custom field changes can be found at the [[CustomConditionSnippets#Checks_with_Custom_Fields]] page of the wiki.

In order to notify the proper tech that a new ticket has been created, I created an RT group for each building. The group names are of the form "SupportTeam-X" where X is the building code found in the "Building" custom field of each ticket. With this approach I can notify more than one tech at a building by making sure each tech is a member of his or her building group. The code to examine the group members is in the following "Building Tech Notify" template.

<nowiki>To: { my $bldg = $Ticket->FirstCustomFieldValue('Building');
my $group = RT::Group->new( $RT::SystemUser );
$group->LoadUserDefinedGroup("SupportTeam-$bldg");
$group->MemberEmailAddressesAsString; }
Subject: Notify: {$Ticket->Subject}

Greetings,

A new ticket has been created, and it looks like it's from {
my $users = $Ticket->Requestors->UserMembersObj;
my $output = '';
while( my $user = $users->Next ) {
$output .= ', ' if $output;
$output .= $user->RealName; # or any other user's property
}
$output;
} at {$Ticket->FirstCustomFieldValue('Building')}. Here's the original message:

--snip--
{$Ticket->Transactions->First->Content()}
--snip--

If you're ready to start working on this ticket, you can do so at the following URL or by responding to the requestor directly by replying to this message:

{ $RT::WebURL }Ticket/Display.html?id={ $Ticket->Id() }

-RT

</nowiki>

Besides notifying the building tech, this template also prints the name of the requestor in the body of the message.

This approach has worked well for us. We could have created separate RT queues for each building, but this approach achieves a similar degree of separation while enabling the building techs to collaborate on tickets more conveniently. Each tech has created a custom "RT at a glance" page which utilizes a saved search to display the newest tickets from their school.

== Acknowledgements ==

Thanks to Keith Schincke, Ruslan Zakirov, Gene LeDuc, Robert Long, David Narayan, and Kenneth Crocker for providing timely advice on the RT-users mailing list.

Submitted by [[TimWilson]]. Feel free to send me a message via the RT-users mailing list if you have any questions.

----

== Active Directory ==

Edit By David Kirk

When using this with Active Directory, I had to do the following to make it work:

while( my $entry = $msg->shift_entry) {

my $dn = $entry->dn;

my $ounum=0;

my $[[SecondOU]];

foreach my $dnparts(split (',',$dn)) {

my %attributes=split('=',$dnparts);
if (defined $attributes{"OU"}) {
$ounum++;}
if ($ounum==2){
$SecondOU=$attributes{"OU"};
$ounum++;}

}

I use the second OU up from the user to determine what queue it is assigned to.

ApproximateSeparateQueues - Revision history

Admin: 3 revisions imported