Custom field help

RT Users
1

Hi list,

I have set up a custom field on our RT (used for an IT helpdesk) which applies to tickets and is of the type ‘select one value’. We use it to track the categories of helpdesk queries, so there are values for ‘printing issues’, ‘telephones’ and so on.

The problem I’m having is that when tickets are updated, for example using the basics or jumbo views, the current value for the custom category is not always pre-selected in the box. This is problematic as if you don’t notice it’s defaulted back to ‘no value’ you end up clearing off the value when you commit the other changes.

I have tried to find a pattern to the behaviour and it seems to be down to the actual values selected…

As an example I have a ticket with the field set to ‘printing issues’. I click jumbo and ‘no value’ is selected for the custom field. If I change the value to ‘email issues’ and go back to jumbo, ‘email issues’ is correctly set in the box. If I change it back again it goes back to ‘no value’.

I can’t see a difference between the option called ‘email issues’ and one called ‘printing issues’? There are no special characters in the names and the problem persists with the descriptions blanked off as well.

It’s not down to a character limit as the one called ‘hardware request/repair’ works which is longer than ‘printing issues’. It’s the same for any user regardless of privileges or who owns the ticket.

Any ideas? It seems like a bug to me?

This is on 3.8.7 and we had the problem on the previous version as well. I have put below the 16 values and which 4 of them work but I can’t see a pattern and there is no way in RT to treat one of the values any differently to the others anyway; it’s just a list.

Thanks,

Ian.

“Cartridges”, NO
"Development", NO
"Email Issues", YES
"Fault", NO
"Hardware Request/Repair", YES
"Software Requests", YES
"Network File Access", NO
"Password problems", NO
"Printing issues", NO
"Purchases", NO
"Server issues", NO
"Service request", NO
"Telephones", NO
"User Setup", NO
"Workshop specific", NO
"S/R Workshops", YES

Ian Atkinson
Senior Infrastructure Support Engineer
Leeds College of Art and Design

2

Ian,

When I first go to a ticket and select “Jumbo”, all CF’s look fine. When I
go back to “Display”, they are also fine. I do find, though, that when I
make a change to a CF and then select a different view, the change does
always show.
A Question; have you tried updating the CF in a ticket, then get out to look
at another ticket, then get back into the one you changed? I think if you do
this, you’ll find that the change DID commit. However, I think that due to
cache, when you take different looks at the ticket after a change without
getting that cache re-loaded, you’re going to see this. I am also on 3.8.7
and have seen this before. But when I navigate to some other screen (new
ticket, a query, home page, etc.) and then come back, the data is correct.
Just a thought.

Kenn
LBNLOn Thu, Sep 30, 2010 at 5:09 AM, Ian Atkinson ian.atkinson@leeds-art.ac.ukwrote:

Hi list,

I have set up a custom field on our RT (used for an IT helpdesk) which
applies to tickets and is of the type ‘select one value’. We use it to track
the categories of helpdesk queries, so there are values for ‘printing
issues’, ‘telephones’ and so on.

The problem I’m having is that when tickets are updated, for example using
the basics or jumbo views, the current value for the custom category is not
always pre-selected in the box. This is problematic as if you don’t notice
it’s defaulted back to ‘no value’ you end up clearing off the value when you
commit the other changes.

I have tried to find a pattern to the behaviour and it seems to be down to
the actual values selected…

As an example I have a ticket with the field set to ‘printing issues’. I
click jumbo and ‘no value’ is selected for the custom field. If I change the
value to ‘email issues’ and go back to jumbo, ‘email issues’ is correctly
set in the box. If I change it back again it goes back to ‘no value’.

I can’t see a difference between the option called ‘email issues’ and one
called ‘printing issues’? There are no special characters in the names and
the problem persists with the descriptions blanked off as well.

It’s not down to a character limit as the one called ‘hardware
request/repair’ works which is longer than ‘printing issues’. It’s the same
for any user regardless of privileges or who owns the ticket.

Any ideas? It seems like a bug to me?

This is on 3.8.7 and we had the problem on the previous version as well. I
have put below the 16 values and which 4 of them work but I can’t see a
pattern and there is no way in RT to treat one of the values any differently
to the others anyway; it’s just a list.

Thanks,

Ian.

“Cartridges”, NO
“Development”, NO
“Email Issues”, YES
“Fault”, NO
“Hardware Request/Repair”, YES
“Software Requests”, YES
“Network File Access”, NO
“Password problems”, NO
“Printing issues”, NO
“Purchases”, NO
“Server issues”, NO
“Service request”, NO
“Telephones”, NO
“User Setup”, NO
“Workshop specific”, NO
“S/R Workshops”, YES

Ian Atkinson
Senior Infrastructure Support Engineer
Leeds College of Art and Design

RT Training in Washington DC, USA on Oct 25 & 26 2010
Last one this year – Learn how to get the most out of RT!

3

Ian,

When I first go to a ticket and select “Jumbo”, all CF’s look fine. When I go back to “Display”, they are also fine. I do find, though, that when I make a change to a CF and then select a different view, the change does always show.
A Question; have you tried updating the CF in a ticket, then get out to look at another ticket, then get back into the one you changed? I think if you do this, you’ll find that the change DID commit. However, I think that due to cache, when you take different looks at the ticket after a change without getting that cache re-loaded, you’re going to see this. I am also on 3.8.7 and have seen this before. But when I navigate to some other screen (new ticket, a query, home page, etc.) and then come back, the data is correct. Just a thought.

Kenn
LBNL

Hi Ken,

Thanks for your response - I don’t think it’s a caching issue to be honest as the display is always the same for the ‘broken’ values regardless of who’s machine in the office the helpdesk is viewed from, how long ago the CF was set or if the Apache service has been restarted on the server which should rule out all caches as far as I can tell?

Thanks,

Ian.

4

Hi list,

I have set up a custom field on our RT (used for an IT helpdesk)
which applies to tickets and is of the type ‘select one value’. We
use it to track the categories of helpdesk queries, so there are
values for ‘printing issues’, ‘telephones’ and so on.

The problem I’m having is that when tickets are updated, for example
using the basics or jumbo views, the current value for the custom
category is not always pre-selected in the box. This is problematic
as if you don’t notice it’s defaulted back to ‘no value’ you end up
clearing off the value when you commit the other changes.

I’ve seen this happen when your Custom Field value has trailing
whitespace. Parts of RT strip that and other parts don’t (there is
already a fix to always strip in trunk). I suggest you check your
values carefully.

-kevin

5

I’ve seen this happen when your Custom Field value has trailing
whitespace. Parts of RT strip that and other parts don’t (there is
already a fix to always strip in trunk). I suggest you check your
values carefully.

-kevin

Kevin you’re a star, that was exactly the problem! It’s sorted now thank you! :slight_smile:

Ian