Ian,<br><br>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.<br>
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.<br>
<br>Kenn<br>LBNL<br><br><div class="gmail_quote">On Thu, Sep 30, 2010 at 5:09 AM, Ian Atkinson <span dir="ltr"><<a href="mailto:ian.atkinson@leeds-art.ac.uk">ian.atkinson@leeds-art.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi list,<br>
<br>
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.<br>

<br>
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.<br>

<br>
I have tried to find a pattern to the behaviour and it seems to be down to the actual values selected...<br>
<br>
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'.<br>

<br>
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.<br>

<br>
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.<br>

<br>
Any ideas? It seems like a bug to me?<br>
<br>
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.<br>

<br>
Thanks,<br>
<br>
Ian.<br>
<br>
"Cartridges", NO<br>
"Development", NO<br>
"Email Issues", YES<br>
"Fault", NO<br>
"Hardware Request/Repair", YES<br>
"Software Requests", YES<br>
"Network File Access", NO<br>
"Password problems", NO<br>
"Printing issues", NO<br>
"Purchases", NO<br>
"Server issues", NO<br>
"Service request", NO<br>
"Telephones", NO<br>
"User Setup", NO<br>
"Workshop specific", NO<br>
"S/R Workshops", YES<br>
<br>
--------------------------------------<br>
Ian Atkinson<br>
Senior Infrastructure Support Engineer<br>
Leeds College of Art and Design<br>
<br>
<br>
<br>
<br>
<br>
RT Training in Washington DC, USA on Oct 25 & 26 2010<br>
Last one this year -- Learn how to get the most out of RT!<br>
</blockquote></div><br>