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: [EMAIL PROTECTED] >>> >>> >>> 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: [EMAIL PROTECTED] >> >> >> 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: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
