Our RT setup involves having a custom field named ‘area’ for each
queue. Each queue has it’s own custom field so different values are
available for each. Each queue has many areas listed, so combining them
makes the interface more cluttered, not to mention the hassle of fixing
the database to implement the changes.
Since we use the area quite a bit, we would like to add it to the
default search results.
If there was a single ‘area’ custom field, we could simply use
’CF.{area}’ in the config file. But since it’s different for each
queue, I had to add the hack listed below, which adds ‘Area’ as a
standard column definition.
Instead of doing this, I would suggest that the TicketList code to
handle custom fields be extended to search for a queue specific custom
field before searching for the global custom field.
–snip–
— share/html/Elements/TicketList.backup Mon Aug 2 13:00:43 2004
+++ share/html/Elements/TicketList Mon Aug 2 13:52:10 2004
@@ -131,6 +131,15 @@
}
}
$COLUMN_MAP = {
- Area => {
- title => ‘Area’,
- value => sub {
-
my $cf = RT::CustomField->new( $session{'CurrentUser'} ); -
$cf->LoadByNameAndQueue( Queue => $_[0]->QueueObj->id, Name => 'area'
);
-
my $values = $_[0]->CustomFieldValues('".$cf->id."'); -
return ( join( ', ', map { $_->Content } @{ $values->ItemsArrayRef }
))
- }
- },
QueueName => {
attribute => ‘Queue’,
title => ‘Queue’,
–snip–
Jeremy Baumgartner
CAE UNIX Systems Staff
“Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.”
- Brian W. Kernighan
signature.asc (189 Bytes)