[rt-users] Problem with categories in custom fields

[Mathew Snyder]

Chet Burgess wrote:
> Greetings,
> 	I had a user report a problem with categories in custom fields recently
> that I have been unable to solve. I have looked through the wiki, the
> bugs listed in rt, and the mailing lists and I have been unable to find
> a solution to my problem.
> 
> 	We have several custom fields that have been created as a type of
> "Select one value", with a validation of "Mandatory". The problem is
> that when a user creates a ticket, or updates an existing ticket, the
> category that is associated with the name is not saved. As an example if
> you created a custom filed with 2 values, each with a different name and
> category, only the name is saved with the ticket. The category field
> will be left as "-".
> 
> 	This is causing a problem as some times we have the same name in
> different categories (we have the same components within different
> products and we use the custom fields to indicate which component and
> product the ticket is for).
> 
> 	I have been able to reproduce on both RT 3.6.1 which we run in
> production and on RT 3.6.4 which we run in test. I have noticed that
> when creating a new ticket in RT 3.6.4 with a custom field of this type
> the following error is being logged.
> 
> Jul 18 15:25:32 hostname RT: Use of uninitialized value in string eq at
> /usr/local/rt/lib/RT/Record.pm line 1686.
> (/usr/local/rt/lib/RT/Record.pm:1686)
> 
> 	When updating an existing ticket the name value gets updated, but the
> category does not get set and remains as just "-". The following message
> appears in the "Results" section at the top of the page after clicking
> "Save Changes" in both RT 3.6.1 and RT 3.6.4.
> 
> User asked for an unknown update type for custom field
> ChetTestSelectSingleValue for RT::Ticket object #6
> 
> As mentioned I have seen this problem in both RT 3.6.1 and RT 3.6.4. We
> are running on RHEL 3 Update 8 with apache 1.3.31, Perl 5.8.4, mod_perl
> 1.29, and mysql 4.0.18.
> 
> Has anyone seen this before and/or know if there is something else I
> need to do to enable this functionality?
> 
> 

Did you ever get any input on this?  I actually just ran into the same issue
verified using both IE and Firefox on Windows and Linux.  I have a couple other
issues with it as well also on both 3.6.1 and 3.6.4.  I'm running Fedora Core 5
and mysql 5.0.0.2 though.

First, when using Firefox, selecting a category filters the second drop down
(the one with the actual values) to just the values of that particular category
 (which I suspect to be the intended behaviour).  However, in IE, this is not
the case.  Selecting the category does not run the filter on the second drop
down.  All categories and values are listed regardless of the category selected
in the first drop down.

Second, once a value has been assigned to a category, it is not possible to
remove it by simply blanking out the category field.  When testing this feature,
I found that in order to remove the category from an item, I had to delete the
item and then recreate it.  After doing this, it would appear in the drop down
list as not being associated with any category while all others which have not
been changed still were.  Attempting to simply set the category as blank
resulted in it being repopulated with the category after hitting submit.

Are there plans on fixing this with the next release?

Mathew
Keep up with me and what I'm up to: http://theillien.blogspot.com