Grouping Custom Fields

RT Users
1

I am new to RT and have been tasked with a project I am finding rather
difficult.

We are running RT 3.4.4 and need to ensure certain fields are
completed before a ticket can be closed. Searching the list archives
it appears that making certain fields mandatory was added in a more
recent version, but I managed to find a scrip I can use with our
current version that allows RT to re-open a ticket if certain fields
have a particular value (null value in this case). This is working
well.

The problem I am encountering however is that there is a requirement
to have these particular fields separate from the other custom fields
in RT. What we need is to have custom fields a, b and c in the Basics
view and fields d, e and f (although more than likely non-sequential)
on another page. We also don’t need or want to see “d, e and f” during
the ticket creation process, as these fields are only relevant to
ticket closure. (They are in fact relating to having updated network
diagrams and documentation).

I have what I consider to be a nasty hack working to do this at the
moment; I’ve added a “Checklist” item to the tab bar, pointing to a
copy of the EditCustomFields element and have a perl hash containing
the names of the fields I want on this form. As we loop around the “my
$CustomField = $CustomFields->Next()” portion of the EditCustomFields,
it simply performs a perl “next” if the field is not in the hash. For
the original EditCustomFields element, the opposite is true; it
processes the next field if the current field IS in the hash.

I will likely attempt upgrading to the latest version of RT in the
future, however at this time I am currently not comfortable enough
with the software or environment to attempt to do so.

Is there a cleaner and simpler way to achieve separation of particular
custom fields in RT 3.4.4?

2

Ian,

I don't have an answer for you, but YOU have one for me. You mentioned

a scrip that allows “RT to re-open a ticket” if certain fields/values
meet a condition. I have need of just such a scrip. Being a ‘PERL’
novice, I try to gather as many scrips that are models of various
conditions/actions as I can for reference as I build my own. The one you
mentioned is EXTREMELY similar to what I need. Would you mind terribly
posting it here or passing it back to me in “REPLY”? I could certainly
use the help. Thanks.

Kenn
LBNLOn 11/20/2007 6:55 PM, Ian Petts wrote:

I am new to RT and have been tasked with a project I am finding rather
difficult.

We are running RT 3.4.4 and need to ensure certain fields are
completed before a ticket can be closed. Searching the list archives
it appears that making certain fields mandatory was added in a more
recent version, but I managed to find a scrip I can use with our
current version that allows RT to re-open a ticket if certain fields
have a particular value (null value in this case). This is working
well.

The problem I am encountering however is that there is a requirement
to have these particular fields separate from the other custom fields
in RT. What we need is to have custom fields a, b and c in the Basics
view and fields d, e and f (although more than likely non-sequential)
on another page. We also don’t need or want to see “d, e and f” during
the ticket creation process, as these fields are only relevant to
ticket closure. (They are in fact relating to having updated network
diagrams and documentation).

I have what I consider to be a nasty hack working to do this at the
moment; I’ve added a “Checklist” item to the tab bar, pointing to a
copy of the EditCustomFields element and have a perl hash containing
the names of the fields I want on this form. As we loop around the “my
$CustomField = $CustomFields->Next()” portion of the EditCustomFields,
it simply performs a perl “next” if the field is not in the hash. For
the original EditCustomFields element, the opposite is true; it
processes the next field if the current field IS in the hash.

I will likely attempt upgrading to the latest version of RT in the
future, however at this time I am currently not comfortable enough
with the software or environment to attempt to do so.

Is there a cleaner and simpler way to achieve separation of particular
custom fields in RT 3.4.4?

The rt-users Archives

SAVE THOUSANDS OF DOLLARS ON RT SUPPORT:

If you sign up for a new RT support contract before December 31, we’ll take
up to 20 percent off the price. This sale won’t last long, so get in touch today.
Email us at sales@bestpractical.com or call us at +1 617 812 0745.

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

3

Hi Kenn,

I don’t have an answer for you, but YOU have one for me. You mentioned
a scrip that allows “RT to re-open a ticket” if certain fields/values
meet a condition. I have need of just such a scrip.

The scrip(s) I based mine off were found here:

The scrip I ended up with is:

===== 8< =====

Enable for Testing:

#exit 1 unless ($self->TransactionObj->CreatorObj->Name eq “ian”);

use constant FALSE => 0;
use constant TRUE => 1;

my @mandatory_fields = (‘Procedures Updated’, ‘Network Diagrams Updated’,
‘Monitoring Enabled’);

my $comment = “Please ensure all compulsory fields are completed.”;
my $ok = TRUE;

foreach my $field (@mandatory_fields) {
$ok = FALSE unless (defined $self->TicketObj->FirstCustomFieldValue($field));
}

unless ($ok) {
my ($id, $msg) = $self->TicketObj->SetStatus(“open”);
$self->TicketObj->Comment(Content => $comment);
}

return 1;
===== >8 =====

Being a ‘PERL’ novice, I try to gather as many scrips that are models of various
conditions/actions as I can for reference as I build my own.

I can sympathize. My perl is fairly basic as well, as the more
experienced programmers will tell you after looking at the above :slight_smile:

This code seems to work for me, however I plan on making a few mods
today to clean things up a little. Firstly, the ticket gets re-opened,
but it is not assigned to anyone. I need to work out how to assign it
back to the person who closed it. Secondly, I’ll be changing the
mandatory_fields list to a hash, as since I wrote this I learned that
it’s much faster and more efficient to look for keys of a hash than to
loop around a list like I’m doing above - see
http://faq.perl.org/perlfaq4.html#How_can_I_tell_wheth

I hope this helps!

Regards,
Ian.

4

Ian,

Thanks. I'll use it.

Kenn
LBNLOn 11/21/2007 2:02 PM, Ian Petts wrote:

Hi Kenn,

I don’t have an answer for you, but YOU have one for me. You mentioned
a scrip that allows “RT to re-open a ticket” if certain fields/values
meet a condition. I have need of just such a scrip.

The scrip(s) I based mine off were found here:
Carbon60: Managed Cloud Services

The scrip I ended up with is:

===== 8< =====

Enable for Testing:

#exit 1 unless ($self->TransactionObj->CreatorObj->Name eq “ian”);

use constant FALSE => 0;
use constant TRUE => 1;

my @mandatory_fields = (‘Procedures Updated’, ‘Network Diagrams Updated’,
‘Monitoring Enabled’);

my $comment = “Please ensure all compulsory fields are completed.”;
my $ok = TRUE;

foreach my $field (@mandatory_fields) {
$ok = FALSE unless (defined $self->TicketObj->FirstCustomFieldValue($field));
}

unless ($ok) {
my ($id, $msg) = $self->TicketObj->SetStatus(“open”);
$self->TicketObj->Comment(Content => $comment);
}

return 1;
===== >8 =====

Being a ‘PERL’ novice, I try to gather as many scrips that are models of various
conditions/actions as I can for reference as I build my own.

I can sympathize. My perl is fairly basic as well, as the more
experienced programmers will tell you after looking at the above :slight_smile:

This code seems to work for me, however I plan on making a few mods
today to clean things up a little. Firstly, the ticket gets re-opened,
but it is not assigned to anyone. I need to work out how to assign it
back to the person who closed it. Secondly, I’ll be changing the
mandatory_fields list to a hash, as since I wrote this I learned that
it’s much faster and more efficient to look for keys of a hash than to
loop around a list like I’m doing above - see
perlfaq4 - Data Manipulation - Perldoc Browser

I hope this helps!

Regards,
Ian.