[rt-users] custom field help

[Kenneth Crocker]

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

On Thu, Sep 30, 2010 at 5:09 AM, Ian Atkinson
<ian.atkinson at leeds-art.ac.uk>wrote:

> 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!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20100930/d7fb15b9/attachment.htm>