[rt-users] Problem with categories in custom fields

[Mathew Snyder]

No but I did submit it as a bug this morning.  I imagine I'll hear something
through there in the next week or so.

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


Kenneth Crocker wrote:
> Mathew,
> 
> 
>     Yes, we are experiencing the same problems as you are with Category.
> We use firefox, so we do get the drop-down filtering effect, but the
> category is never saved (we get the same error message) and we cannot
> remove them, now that they are there. We will probably run some SQL
> against the DataBase to make all categories blank again and keep them
> that way until the problem gets solved. Have you heard any estimates on
> when the problem will be resolved?
> 
> Kenn
> LBNL
> 
> On 9/20/2007 6:49 AM, Mathew Snyder wrote:
>> Anyone have any input on this?
>>
>> Keep up with me and what I'm up to: http://theillien.blogspot.com
>>
>>
>> Mathew Snyder wrote:
>>> 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
>>> _______________________________________________
>>> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>>>
>>> Community help: http://wiki.bestpractical.com
>>> Commercial support: sales at bestpractical.com
>>>
>>>
>>> Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
>>> Buy a copy at http://rtbook.bestpractical.com
>>>
>> _______________________________________________
>> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>>
>> Community help: http://wiki.bestpractical.com
>> Commercial support: sales at bestpractical.com
>>
>>
>> Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
>> Buy a copy at http://rtbook.bestpractical.com
>>
>